VoIP Firewall: Difference between revisions

From AAISP Support Site
mNo edit summary
No edit summary
 
(24 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[File:Snom710.png|link=:Category:VoIP|Go to the VoIP Category]]
[[File:Snom710.png|link=:Category:VoIP|Go to the VoIP Category]]


=== If you are not using public IP addresses (ie NAT): ===
This is what we suggest firewall-wise for VoIP customers:


If your phone on private IP addresses (eg 192.168.x.x, 10.x.x.x) then you won't need to set up the firewall as you're not using pubic IP addresses.
Avoid using NAT where possible. However, some NAT gateways provide an adequate SIP ALG (e.g. Technicolor TG582), and some devices provide NAT that works with the new call server (e.g. FireBrick 2500/2700 and many simple NAT routers). If NAT works, then well done, but if not we cannot guarantee to be able to make it work.

Avoid using NAT where possible. If using NAT, the options are to tell the phone what its public IP address is (either by explicit configuration, or by specifying a STUN server to use - e.g. ''stun.aa.net.uk''), or to use a SIP Application Layer Gateway to rewrite SIP packets on the fly. Some NAT gateways provide an adequate SIP ALG (e.g. Technicolor TG582), and some devices provide NAT that works with the new call server (e.g. FireBrick FB2900 and many simple NAT routers). If NAT works, then well done, but if not we cannot guarantee to be able to make it work.

=== If you are using public IP addresses: ===

Allowing appropriate SIP and RTP packets through a firewall is the key to reliable VoIP communication. It may be possible to achieve reliability using SIP Keep-Alive packets (every 120 seconds or so) and relying on phones using UDP hole punching for the audio channel, but firewall rules are more certain to work.

This is what we suggest firewall-wise for VoIP customers who have SIP devices (phones/PABXs etc) on public IP addresses.


{| class="wikitable"
{| class="wikitable"
!colspan="3"|Firewall Requirements on Voiceless Platform
!colspan="4"|Firewall Requirements on the AAISP VoIP Platform
|-
|-
!
|
!Target Ports
!Target Ports
!Source IPs
!Source IPs ([[IPv6]])
!Source IPs (legacy)
|-
|-
!SIP (IPv4)
!SIP
|UDP 5060
|UDP 5060
|2001:8b0:0:30::5060:0/112
2001:8b0:5060::/48
|81.187.30.110 - 81.187.30.119
|81.187.30.110 - 81.187.30.119
''90.155.3.0/24, 90.155.103.0/24 (NEW)''
90.155.3.0/24
90.155.103.0/24
|-
!SIP ([[IPv6]])
|UDP 5060
|2001:8b0:0:30::5060:0/112
''2001:8b0:5060::/48 (NEW)''
|-
|-
!RTP (IPv4)
!RTP
|UDP 1024-65535
|UDP 1024-65535
|2001:8b0:0:30::5060:0/112
2001:8b0:5060::/48
|81.187.30.110 - 81.187.30.119
|81.187.30.110 - 81.187.30.119
''90.155.3.0/24, 90.155.103.0/24 (NEW)
90.155.3.0/24
90.155.103.0/24
|-''
|-''
!RTP ([[IPv6]])
|UDP 1024-65535
|2001:8b0:0:30::5060:0/112
''2001:8b0:5060::/48 (NEW)''
|}
|}


Customers should add all IPs above to their firewall rules even if you don't see traffic from or to them. This is a fairly large number of addresses but it means we can expand our platform over time as well as accommodate hosting our equipment in diverse datacentres.
The IPs marked as ''NEW'' were added in August 2014 for room for a planned expansion. Customers should add these additional IPs to their firewall rules as we expect to be using them in the future.


'''SIP''' is the call routing information that creates and manages calls. In practice if you allow port 5060 from the outside world you'll see attacks and possibly receive spam phone calls. We do not recommend leaving 5060 open unless you really know what you are doing. Phones rarely use ports as low as 5060 for media.
'''SIP''' is the call routing information that creates and manages calls. If incoming SIP packets are blocked, incoming calls will fail. In practice if you allow port 5060 from the outside world you'll see attacks and possibly receive spam phone calls. We do not recommend leaving 5060 open unless you really know what you are doing. Phones rarely use ports as low as 5060 for media.


'''RTP''' is the actual media (e.g., the audio). On the older call servers it will be as direct as possible the media can be sent from anywhere on the internet. Using the new call servers it is only from the same call server as the SIP control messages. On most phones you can configure which ports to use for RTP, so you can restrict this range further. For example, on a Snom Phone the default range for RTP is 49152 to 65534.
'''RTP''' is the actual media (e.g., the audio). On our platform the RTP will come from the same call server IP address as the SIP control messages. On most phones you can configure which ports to listen on for RTP, so you can restrict this range further. Note that RTP actually uses 2 consecutive port numbers, you should specify an even number and RTP will also use that port number +1. For example, on a Snom Phone the default range for inbound RTP is 49152 to 65534, so the firewall needs to allow the destination port number range 49152 to 65535. As another example, Grandstream phones and ATAs tend to default to listen on 5004 as the RTP port, so you need to allow destination ports 5004-5005 through the firewall.

On routers which need one rule per IP address range you can halve the number of firewall rules needed as long as the source IP address ranges for SIP and RTP are the same and that the RTP port range you specify includes 5060.


In CIDR notation, the IPv4 range 81.187.30.110 - 81.187.30.119 needs two blocks:
In CIDR notation, the IPv4 range 81.187.30.110 - 81.187.30.119 needs two blocks:
181.187.30.110/31
81.187.30.110/31
181.187.30.112/29
81.187.30.112/29


=Example FireBrick Config=
=Example FireBrick Config=
Allow inbound calls to your VoIP Phone, if you register it with FireBrick:
Allow inbound calls to your VoIP Phone, if you register it with FireBrick:
<syntaxhighlight>
<syntaxhighlight lang="xml">
<rule name="Allow Firebrick" source-interface="self" comment="Allow all from the FireBrick to LAN"/>
<rule name="Allow Firebrick" source-interface="self" comment="Allow all from the FireBrick to LAN"/>
</syntaxhighlight>
</syntaxhighlight>

Allow inbound calls to your VoIP Phone, if you register it with Voiceless:
Allow inbound calls to your VoIP/Snom Phone, if you register it with Voiceless:
<syntaxhighlight>
<syntaxhighlight lang="xml">
<rule name="SIP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="5060" action="accept"/>
<rule name="SIP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="5060" action="accept"/>
<rule name="RTP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="1024-65535" protocol="17" action="accept"/>
<rule name="RTP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="1024-65535" protocol="17" action="accept"/>
</syntaxhighlight>
Allow inbound calls to your Snom Phone, if you register it with Voiceless:
<syntaxhighlight>
<rule name="SIP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="5060" action="accept"/>
<rule name="RTP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="49152-65534" protocol="17" action="accept"/>
</syntaxhighlight>
</syntaxhighlight>


=Example consumer router config=
The following example is for an AAISP-supplied ZyXEL router. It assumes you have locked down the destination RTP port range on clients to ports 5000-5098. Because the Custom Destination Port range covers port 5060 we get away with half the rules - 6, rather than 12!
{| class="wikitable"
!colspan="7"|Firewall Rules on the AAISP VoIP Platform
|-
!Filter name
!Source IP Address
!IP Type
!Protocol
!Custom Destination Port
!Policy
!Direction
|-
|VoIP6A
|2001:8b0:0:30::5060:0/112
|IPv6
|UDP
|5000-5099
|ACCEPT
|WAN to LAN
|-
|VoIP6B
|2001:8b0:5060::/48
|IPv6
|UDP
|5000-5099
|ACCEPT
|WAN to LAN
|-
|VoIP4A
|81.187.30.110/31
|IPv4
|UDP
|5000-5099
|ACCEPT
|WAN to LAN
|-
|VoIP4B
|81.187.30.112/29
|IPv4
|UDP
|5000-5099
|ACCEPT
|WAN to LAN
|-
|VoIP4C
|90.155.3.0/24
|IPv4
|UDP
|5000-5099
|ACCEPT
|WAN to LAN
|-
|VoIP4D
|90.155.103.0/24
|IPv4
|UDP
|5000-5099
|ACCEPT
|WAN to LAN
|-
|}


=Other things to Firewall=
=Other things to Firewall=
Line 66: Line 132:


=NAT=
=NAT=
Avoid using NAT where possible. However, some NAT gateways provide an adequate SIP ALG (e.g. Technicolor TG582), and some devices provide NAT that works with the new call server (e.g. FireBrick 2500/2700 and many simple NAT routers). If NAT works, then well done, but if not we cannot guarantee to be able to make it work. See: [[VoIP NAT]]
Avoid using NAT where possible. However, some NAT gateways provide an adequate SIP ALG (e.g. Technicolor TG582), and some devices provide NAT that works with the new call server (e.g. FireBrick 2500/2700 and many simple NAT routers). Using a STUN server (e.g. ''stun.aa.net.uk'') is another possible solution. If NAT works, then well done, but if not we cannot guarantee to be able to make it work.

If you have 2 phones behind a NAT router, they cannot have the same SIP port number, nor the same RTP port range (if they both used port number for SIP of 5060 then when an incoming call came in to external port 5060, NAT wouldn't know which phone to send it to).

As an example with 2 phones, the first phone uses inbound SIP port 5060 and incoming RTP ports 5062-5068, and the second phone uses inbound SIP port 5040 and incoming RTP ports 5042-5048. Using iptables, the required rules would be like:

/sbin/iptables -t nat -A PREROUTING -i eth0 -m udp -p udp -s 81.187.30.112/29 --dport 5060:5069 -j DNAT --to-destination 192.168.1.12
/sbin/iptables -t nat -A PREROUTING -i eth0 -m udp -p udp -s 81.187.30.112/29 --dport 5040:5049 -j DNAT --to-destination 192.168.1.13


See: [[VoIP NAT]]


=Further VoIP Security=
=Further VoIP Security=

Latest revision as of 10:08, 12 April 2024

Go to the VoIP Category

If you are not using public IP addresses (ie NAT):

If your phone on private IP addresses (eg 192.168.x.x, 10.x.x.x) then you won't need to set up the firewall as you're not using pubic IP addresses.

Avoid using NAT where possible. If using NAT, the options are to tell the phone what its public IP address is (either by explicit configuration, or by specifying a STUN server to use - e.g. stun.aa.net.uk), or to use a SIP Application Layer Gateway to rewrite SIP packets on the fly. Some NAT gateways provide an adequate SIP ALG (e.g. Technicolor TG582), and some devices provide NAT that works with the new call server (e.g. FireBrick FB2900 and many simple NAT routers). If NAT works, then well done, but if not we cannot guarantee to be able to make it work.

If you are using public IP addresses:

Allowing appropriate SIP and RTP packets through a firewall is the key to reliable VoIP communication. It may be possible to achieve reliability using SIP Keep-Alive packets (every 120 seconds or so) and relying on phones using UDP hole punching for the audio channel, but firewall rules are more certain to work.

This is what we suggest firewall-wise for VoIP customers who have SIP devices (phones/PABXs etc) on public IP addresses.

Firewall Requirements on the AAISP VoIP Platform
Target Ports Source IPs (IPv6) Source IPs (legacy)
SIP UDP 5060 2001:8b0:0:30::5060:0/112

2001:8b0:5060::/48

81.187.30.110 - 81.187.30.119

90.155.3.0/24 90.155.103.0/24

RTP UDP 1024-65535 2001:8b0:0:30::5060:0/112

2001:8b0:5060::/48

81.187.30.110 - 81.187.30.119

90.155.3.0/24 90.155.103.0/24

Customers should add all IPs above to their firewall rules even if you don't see traffic from or to them. This is a fairly large number of addresses but it means we can expand our platform over time as well as accommodate hosting our equipment in diverse datacentres.

SIP is the call routing information that creates and manages calls. If incoming SIP packets are blocked, incoming calls will fail. In practice if you allow port 5060 from the outside world you'll see attacks and possibly receive spam phone calls. We do not recommend leaving 5060 open unless you really know what you are doing. Phones rarely use ports as low as 5060 for media.

RTP is the actual media (e.g., the audio). On our platform the RTP will come from the same call server IP address as the SIP control messages. On most phones you can configure which ports to listen on for RTP, so you can restrict this range further. Note that RTP actually uses 2 consecutive port numbers, you should specify an even number and RTP will also use that port number +1. For example, on a Snom Phone the default range for inbound RTP is 49152 to 65534, so the firewall needs to allow the destination port number range 49152 to 65535. As another example, Grandstream phones and ATAs tend to default to listen on 5004 as the RTP port, so you need to allow destination ports 5004-5005 through the firewall.

On routers which need one rule per IP address range you can halve the number of firewall rules needed as long as the source IP address ranges for SIP and RTP are the same and that the RTP port range you specify includes 5060.

In CIDR notation, the IPv4 range 81.187.30.110 - 81.187.30.119 needs two blocks:

81.187.30.110/31
81.187.30.112/29

Example FireBrick Config

Allow inbound calls to your VoIP Phone, if you register it with FireBrick:

<rule name="Allow Firebrick" source-interface="self" comment="Allow all from the FireBrick to LAN"/>

Allow inbound calls to your VoIP/Snom Phone, if you register it with Voiceless:

<rule name="SIP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="5060" action="accept"/>
<rule name="RTP" source-ip="81.187.30.110-119 90.155.3.0/24 90.155.103.0/24 2001:8b0:0:30::5060:0/112 2001:8b0:5060::/48" target-ip="1.2.3.4" target-port="1024-65535" protocol="17" action="accept"/>

Example consumer router config

The following example is for an AAISP-supplied ZyXEL router. It assumes you have locked down the destination RTP port range on clients to ports 5000-5098. Because the Custom Destination Port range covers port 5060 we get away with half the rules - 6, rather than 12!

Firewall Rules on the AAISP VoIP Platform
Filter name Source IP Address IP Type Protocol Custom Destination Port Policy Direction
VoIP6A 2001:8b0:0:30::5060:0/112 IPv6 UDP 5000-5099 ACCEPT WAN to LAN
VoIP6B 2001:8b0:5060::/48 IPv6 UDP 5000-5099 ACCEPT WAN to LAN
VoIP4A 81.187.30.110/31 IPv4 UDP 5000-5099 ACCEPT WAN to LAN
VoIP4B 81.187.30.112/29 IPv4 UDP 5000-5099 ACCEPT WAN to LAN
VoIP4C 90.155.3.0/24 IPv4 UDP 5000-5099 ACCEPT WAN to LAN
VoIP4D 90.155.103.0/24 IPv4 UDP 5000-5099 ACCEPT WAN to LAN

Other things to Firewall

  • Don't allow access to your phone or servers web configuration pages from the Internet.
  • If you run your own server and allow phones to use it from your WAN/Internet, then lock this down as much as possible - perhaps only allow access to your PBX from the Internet via a VPN.


NAT

Avoid using NAT where possible. However, some NAT gateways provide an adequate SIP ALG (e.g. Technicolor TG582), and some devices provide NAT that works with the new call server (e.g. FireBrick 2500/2700 and many simple NAT routers). Using a STUN server (e.g. stun.aa.net.uk) is another possible solution. If NAT works, then well done, but if not we cannot guarantee to be able to make it work.

If you have 2 phones behind a NAT router, they cannot have the same SIP port number, nor the same RTP port range (if they both used port number for SIP of 5060 then when an incoming call came in to external port 5060, NAT wouldn't know which phone to send it to).

As an example with 2 phones, the first phone uses inbound SIP port 5060 and incoming RTP ports 5062-5068, and the second phone uses inbound SIP port 5040 and incoming RTP ports 5042-5048. Using iptables, the required rules would be like:

/sbin/iptables -t nat -A PREROUTING -i eth0 -m udp -p udp -s 81.187.30.112/29 --dport 5060:5069 -j DNAT --to-destination 192.168.1.12
/sbin/iptables -t nat -A PREROUTING -i eth0 -m udp -p udp -s 81.187.30.112/29 --dport 5040:5049 -j DNAT --to-destination 192.168.1.13

See: VoIP NAT

Further VoIP Security

  • Please see our VoIP Security page for further information on securing your phones, accounts and VoIP systems.