[Asterisk-Users] Nat Traversal help!

[Benjamin on Asterisk Mailing Lists]

On Wed, 29 Sep 2004 07:18:57 +0100, E Samuels <support at biz4web.com> wrote:

> I have a number of X-Lite users in countries where the incumbent Telco will
> do anything to block VOIP traffic.

Welcome to the club ;-)

Having said that, it's not always deliberate actions by service
providers which is the cause. In respect of NAT traversal, SIP is
fundamentally broken and requires duct tape and other such kludges to
work. In some cases even those utensils won't help.

The proper solutions come down to:

1) Don't use NAT
2) If you have to use NAT, don't use SIP
3) If you have to use both NAT and SIP, use tunneling

If you can't do any of the above there is no proper solution, you will
have to fiddle until you find a workaround that does the trick for
you. This is often rather time consuming and it may continue to be
time consuming because it cannot always be assured that the duct tape
won't come off.

Also, be aware that many of those SIP/NAT traversal workarounds have
bad side effects, most often security related. UPnP for example is a
perfect way to make your firewall useless.

Assuming that you can't avoid NAT, let's go through the list one by one ...

#2 Don't use SIP

This doesn't have to mean you can't use a SIP client. You could use a
SIP client at the remote end, then let the SIP client talk to a local
Asterisk server at the remote end which talks to your site via IAX. In
other words, use a SIP/IAX gateway.

This doesn't have to mean that you need a dedicated Linux box at the
remote end. If the remote end is a Windoze notebook with X-Lite on it
for example, you could install AstWind on that and configure X-Lite to
talk to the Asterisk running inside of coLinux on the same notebook,
which in turn would then talk IAX to you.

If the remote end is a Mac running MacOSX, ie a Powerbook, then you
can even run Asterisk on that natively and again configure X-Lite to
talk to the local Asterisk to then pass the call via IAX to you.

Anyway, I have put up a Wiki page how to run X-Lite alongside Asterisk
for this particular scenario:

http://www.voip-info.org/tiki-index.php?page=Localhost%20gateway


#3 Use tunneling

On non-Windoze systems you can configure a typically already installed
IPsec on the remote machine to tunnel in to your network or your
Asterisk server. On Linux you can use OpenSwan for that, on BSD and
MacOSX you use KAME. Some more recent Windoze versions have limited
IPsec support but I am not sure which ones -- it may be the server
versions only. However, there are commercial IPsec clients for Windoze
desktops. Type IPsec into Versiontracker and there should be at least
two entries. If you have PPTP support on your network, you can of
course use PPTP.

If you don't have a VPN server yet, I recommend Wolverine.

http://www.vortech.net

This is a shrinkwrapped embedded Linux based VPN firewall package that
runs on hardware as old as a Pentium 75MHz and it can boot off a 32MB
Compact Flash card using a CF/IDE adapter.

It's made configuration compatible with Cisco Pixes, so if you know
how to configure a Cisco Pix, then you already know how to configure
Wolverine. Wolverine uses the OpenSwan IPsec stack and it has PPTP
support as well. It can be installed in as little as 3 minutes and
configuration is very straightforward. The guy who is behind this,
Joshua Jackson, is very committed and helpful. You will find it
difficult to get support like that from Cisco no matter how many $$$$$
you paid for gear and maintenance. A single Wolverine license is 30
USD.

#4 Fiddle with SIP

You can of course try to make your X-Lite clients work through NAT.
The key to that is turning on SIP debugging on both your Asterisk
server and the X-Lite client, then watch what happens and try to make
sense of the SIP messages.

On the Asterisk console you enable SIP debugging by entering the
command "sip debug", and you switch it off again by entering "SIP no
debug". On X-lite the same feature is called Diagnostics Window and it
can be enabled through the menu and keyboard shortcuts depending on
the version of X-Lite (it appears to be changing all the time).

As a starting point, take a working X-Lite client and record the SIP
messages of a successful session. Then you can go about analysing the
transcript of a failing session.

The idea is to use the various parameters you have at your disposal to
try and replicated the very same messages you find in the transcript
of the successful session.

For example, if the transcript of the successful session has a
reply-to field with the public IP address of the NAT router and the
transcript of the failing session has a local 192.168.x.x address
there, try to convince X-Lite not to send the internal IP address. The
challenge with this is often X-Lite's clumsy configuration menu. You
never know if one setting alone will actually do what it says it does.
Sometimes the same or a similar parameter is hidden somewhere else in
the menu and it only accepts the setting if both these parameters are
changed. Go figure. Sometimes, X-Lite seems to want to be restarted
before it accepts a change. This can be a bit of a patience
challenging exercise.

Most likely you will need to adjust the settings only on the X-Lite
side, but if you do need to change the settings on Asterisk, watch out
for parameters such as externip, fromdomain, realm etc.

And one more thing ... it sometimes helps to fix the media port (RTP)
on which the audio traffic is sent between client and server. By
default this port is determined at random which can complicate things
even more than they already are.

Good Luck!

rgds
benjk

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.