login | register
Wed 19 of Nov, 2008 [10:48 UTC]

voip-info.org

History

Asterisk SIP NAT solutions

Created by: oej,Last modification on Mon 18 of Aug, 2008 [19:35 UTC] by voipdog

Asterisk, SIP and NAT


Asterisk can both act as a SIP client and a SIP server. Asterisk as a SIP client is configured with type=peer (or type=friend) in one or more client sections of sip.conf and, optionally, one or more register=> lines in the [general] section of sip.conf. Asterisk as a SIP server connects clients (SIP Phones) configured by specifying their own username, secret, etc. (and either type=peer or type=friend) in client sections of sip.conf.

Asterisk SIP channels in a NATed network can be generalized like this:



  1. Asterisk as a SIP client behind nat, connecting to outside SIP Proxies
  2. Asterisk as a SIP client behind nat, connecting to inside SIP proxies
  3. Asterisk as a SIP server behind nat, clients on the outside connecting to Asterisk
  4. Asterisk as a SIP server behind nat, clients on the outside behind a second NAT connecting to Asterisk
  5. Asterisk as a SIP server behind nat, clients on the inside connecting to Asterisk
  6. Asterisk as a SIP client outside nat, connecting to outside SIP proxies
  7. Asterisk as a SIP client outside nat, connecting to inside SIP proxies
  8. Asterisk as a SIP server outside nat, clients on the outside connecting to Asterisk
  9. Asterisk as a SIP server outside nat, clients on the inside connecting to Asterisk



Every setup works somewhere, but it depends on the client, the NAT, the server and many other factors. In most cases, 1 and 3 is broken. SIP is a peer-to-peer protocol and a NAT can be generalized and simplified as a solution that allows clients on the inside to connect to servers on the outside and _not_ allow clients on the outside to connect to any server on the inside.

  • #1 works with a NAT-supporting proxy as SIP Express router as the outside proxy. (Get an account at IPtel.org and try!). Fails with Free World Dialup.
  • #2 Works- no NAT in between
  • #3 Works with port forwarding and some header mangling magic tips
  • #4 Works with port forwarding, STUN on the remote and some fine tuning of RTP port allocation HowTo
  • #5 Works - no NAT in between
  • #6 is no problem. No NAT in the middle
  • #7 is a problem if no port forwarding is done, similar to 3 above.
  • #8 is no problem. No NAT in the middle
  • #9 is solved with nat=yes and qualify=xxx in sip.conf for the client in most cases. Some clients (X-lite) assist themselves by using STUN and sending UDP keep-alive packets. Qualify sends keep-alive packets from Asterisk to the client on the inside.

Then we have even worse cases...

9. Asterisk inside a NAT, client inside ANOTHER NAT <---Isn't this the same as previous option 4???

In this case, we need a middle man to even find each other, an outbound SIP proxy that handles the SIP transaction and is reachable by all parties. To get media streams from point to point we need another middle man, a media server. Asterisk could be that media server, that could add media codec conversion. RTPProxy or AG Projects MediaProxy works together with SIP Express router as a media server in this situation.

I would like to add that this option contains the largest amount of cow poop around it. I've been searching for some time to fix this problem, and I'm sure it's very fixable. Also, this does seem to be a very common thing to do, so, does anyone have a GOOD solution?

I'm sure we can find case #10-xx as well.

For sample config files to setup Asterisk behind a NAT router to make and receive Free World Dialup calls see: Asterisk FWD NAT Config Example
For sample config of Asterisk connecting with remote SIP over a dual NAT see : Step by step dual Asterisk NATing


Olles comments 2003-11-04:

I'm afraid if I configure externalIP= in sip.conf, 1 works, like with FWD, but 2 is broken.
I don't know what happens with 4 if I at the same time use externalip= and have clients
configured as 3.
As I see it, externalip= is an ugly hack that causes problems. There are better solutions
in the bug tracking system, being discussed and refined.

STUN support, and the netmask/ip-network configuration helps asterisk to find out itself
if there's a NAT in the middle and if something should be done.



Other solutions



IP Tunneling Solution

If you have an asterisk server, you are obvoiusly running linux (or something that can handle IPIP and GRE tunnels). In most cases when people have just 1 phone, I use an IAXy, and it is no setup required behind nat. In cases where multiple phones are required, IE setting up an client office w/ a virtual PBX, the only real hardphones out are SIP.

Farfon.... been waiting a while...

What I have done to fix this SIP NAT issue is install a small linux router at the client site, which has a public IP, and is the gateway for a private network. Using netfilter and NAT, you can do anything you want, and all you need to do is setup an IPIP tunnel back to your asterisk server to allow SIP phones to have a direct IP connection.

Server
  • iptunnel add iptun0 mode ipip remote $CLIENTROUTERIP (tunnel)
  • ifconfig iptun0 200.0.0.1 pointopoint 200.0.1.1 (tunnel endpoint)
  • route add -net 200.0.1.0/24 dev iptun0 (tunnel network)
  • route add -net 10.0.0.0/24 dev iptun0 (client network)
  • route add -net 10.0.0.0/24 gw 200.0.1.1 (client gateway)

Client
  • iptunnel add iptun0 mode ipip remote $ASTERISKIP (tunnel)
  • ifconfig iptun0 200.0.1.1 pointopoint 200.0.0.1 (tunnel endpoint)


From anywhere inside the client 10.0.0.0/24 network, you can access 200.0.0.1 (asterisk) and vice versa. This totally eliminates your SIP NAT issues.

Yes this is insecure compared to IPSEC or the like, however, if you are wanting to run SIP over the net without IPSEC, this is the exact same thing, and a lot easier to setup then IPSEC.

You may want to use this script for multiple ipip tunnels



\!/bin/sh

\#ON CLIENT
\#iptunnel add iptun0 mode ipip remote 69.56.173.241
\#ifconfig iptun0 200.0.1.1 pointopoint 200.0.0.1


\#EACH TUNNEL ON NEWLINE
\#FORMAT IS CLIENTIP:CLIENT NETWORK
TUNNELS="0.0.0.0:10.0.0.0/24"

start()
{
c=0
for tun in $TUNNELS
do
d1=`echo $tun | cut -d ":" -f 1`
d2=`echo $tun | cut -d ":" -f 2`
iptunnel add iptun$c mode ipip remote $d1
ifconfig iptun$c 200.$c.0.1 pointopoint 200.$c.1.1
route add -net 200.$c.1.0/24 dev iptun$c
route add -net $d2 dev iptun$c
route add -net $d2 gw 200.$c.1.1
c += 1
done
}

stop()
{
c=0
for tun in $TUNNELS
do
iptunnel del iptun$c
c += 1
done
}

case "$1" in
start)
start ;;
stop)
stop ;;
restart)
stop
start ;;
esac



Andrew Hodel




Comments

Comments Filter
222

333Error 408 occurring

by pmrtvcom, Saturday 14 of June, 2008 [16:33:15 UTC]
If I try to register a SIP client from one particular location I use, I get error 408 appearing on the Asterisk console.

It works fine from all other locations, even when the NAT situation is similar.

The router at the problem location is a Belkin F5D9630-4. The client I use is a Nokia N95 - it only fails in this one circumstance.

The connection here is on the same ISP as my Asterisk, though some distance away.
222

333VPN for VoIP Blocking

by jenniferhan, Wednesday 12 of December, 2007 [03:24:19 UTC]
Somebody use VPN to solve the VoIP Blocking issue. But it seems not a good way to solve the voip blocking issue. Because VPN will take more bandwidth and will take effection on the Voice Quality

Currently I am using the VGCP, a new solution to solve the VoIP Blocking issue. Following is theirs website:
http://www.speed-voip.com/index-36.html

If any of you have interested, you may try to use it to solve your VoIP Blocking problems. Thanks.

Andy
andywong-01@hotmail.com

222

333registration problem

by dhiraj, Tuesday 05 of June, 2007 [09:39:59 UTC]
my asterisk is runing behind nat having a public ip.A SIP phone tries to register from outside , which is also behind the
other nat .Te sip phoce does not get registred .the sip phone sends request outside through proxy server.The sip phone
network is using 255.255.0.0 as an netmask and asterisk is using 255.255.255.0.where is the problem, that i am
not able to make out.
222

333Asterisk both inside and outside NAT

by bradtem, Saturday 28 of October, 2006 [19:32:41 UTC]
I would think my situation would be fairly common. Asterisk is running on a box that has both an external IP address AND an internal IP address where it can talk directly to phones which are thus not behind NAT for the Asterisk box, but are for the world.

In this case, the phones can and should have direct media paths between each other, and can re-invite. Likewise two external devices (non-nat) should be able to reinvite and do direct media paths. Connecting an external device and an internal device would actually work through the NAT if you do your rewriting of headers correctly, which means Asterisk would need to know the external IP of the NAT (which is not its own IP.) But this is just an efficiency issue over which box gates that traffic. For two external devices, it's t he same as any external asterisk talking to two remote devices which may or may not be behind NAT.

What's the best setup here? If I turn off canreinvite on the internal devices, they don't get to send their audio peer to peer like they should.
222

333PIX firewall and Asterisk rtp traffic translation

by sherifff, Monday 21 of August, 2006 [12:27:07 UTC]
It seems that Pix firewall doesn't translate correctly RTP to asterisk natted server.

Please take a look to:
http://wiki.wumarkus.com/index.php?title=Cisco_Pix_with_Asterisk

--
Dario Ventura
222

333Solution Asterisk NAT/FIREWALL with ISA 2004

by synthet1c, Wednesday 19 of July, 2006 [03:41:56 UTC]
Took me a while to figure it out but here are the rules for ISA 2004 to get * to work behind your NAT:
This is for if the * server is not on the ISA server but behind the network on the NAT

Create 2 new Protocols:

1)
name: SIP
Parameters:

Primay connections:
- 5060-5082 - TCP - Inbound
- 5060-5082 - UDP - Recieve Send

Secondary connections:
- 5060-5082 - TCP - Outbound
- 5060-5082 - UDP - Send Recieve

2)
name: RTP
Parameters:

Primay connections:
- 8000-10000 - UDP - Recieve Send

Secondary connections:
- 8000-10000 - UDP - Send Recieve

Create 2 new Server Publishing rules:

1)
name: Asterisk SIP
Action: Allow
Traffic: Protocol: SIP
From: Anywhere
To: (Your Internal * server IP address) ( * request appears to come from original client)
Networks: External

2)
name: Asterisk RTP
Action: Allow
Traffic: Protocol: RTP
From: Anywhere
To: (Your Internal * server IP address) ( * request appears to come from original client)
Networks: External

Here are my sip.conf and rtp.conf as well

SIP.CONF
general
context=default
canreinvite=no
srvlookup=yes
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
externip=(YOUR EXTERNAL IP ADDRESS)
nat=yes
localnet=192.168.1.0/255.255.255.0 ;my subnet yours might be different!

RTP.CONF
general
rtpstart=8000
rtpend=10000


222

333Solution to Asterisk behind NAT/Firewall

by techieg, Thursday 06 of July, 2006 [03:42:08 UTC]
On your router NAT/firewall, forward SIP ports 5060 - 5082 and RTP ports 8000 - 20000 to your * server IP address. Then edit the "rtpstart" value in rtp.conf - from rtpstart=10000 to rtpstart=8000 since 8000 is the default RTP port on x-lite phones. Also enter the same externip=xxx.xxx.xxx.xxx and localnet=xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx info from your sip.conf general settings into sip_nat.conf. Then in sip.conf under the remote extension account authentication settings add nat=yes, canreinvite=no . This should get it working flawlessly, it did it for me after much research and troubleshooting. This should mark the end of NAT/firewall issues with asterisk.


NOTE: Your WAN or externip address from your ISP is usually not permanent so in the case where it changes you will have to edit the "externip=" value in sip.conf general settings and sip_nat.conf to the new value or you can register with dynamic DNS (dyndns) to automaticaly update the value.
222

333Another solution!

by undrhil, Monday 12 of June, 2006 [06:15:35 UTC]
Hi. I have successfully setup Hamachi on my Asterisk server and have had no problems in getting SIP softphones to talk with each other. Granted, Hamachi has to be installed on each computer which needs a softphone (which is problematic for Macs right now) but there are other software VPN solutions (openVPN, I think has Mac OS X support now?) which could be used instead of Hamachi. Once you get the PBX on an open VPN tunnel, there's no NAT to be afraid of. At that point, you just have to worry about any software firewalls you might have running. :)
222

333Asterisk behind nat works with clients outside of LAN

by joee, Thursday 30 of March, 2006 [04:48:31 UTC]
To get asterisk working with SIP clients outside of the lan, when asterisk is behind a firewall, you can follow the instructions at tips but make sure you have port 5060 forwarded from the wan interface on the router/firewall to the asterisk server. I also have "nat = yes" in each peer definition.

--
Joseph Ellis
http://www.lithodyne.net
222

333Solution with NAT clients using Free World Dialup

by mervstar, Friday 10 of March, 2006 [04:31:14 UTC]
Hi, a colleague and myself, have found a way to solve most problems involving NAT using asterisk. It utilised the Free World Dialup outbound proxy servers. Our asterisk system is as follows:
- Asterisk box operating behind a nat firewall with the asterisk box as the DMZ (DeMiliterised Zone) address in the NAT firewall.
- Grandstream, X-Lite, and Eyebeam softphones operating behind their own seperate NAT firewalls globally

Our problem was that the remote phones/softphones would be able to place calls however the audio stream would be either one-way or no audio at all.

This was solved by utilising the Free World Dialup OutBound proxy servers to route calls. Essentially, all you need to do is configure the Outbound proxy on your client phones/softphones to 'fwdnat2.pulver.com:5060'.

The only drawbacks to this is that there may be a slight delay in the audio stream, and that your connectivity is now dependant on the availablility of the Free World Diakup servers. Since Free World Dialup has quite an established infrastructure and that it's been around for a while, their servers should have a near 100% availablaility rate thereby making it a pretty solid solution.