[Freeswitch-users] NAT traversal, SIP replies don't go to originating port

[Leon de Rooij]

Hi all,

I've set up Freeswitch, but my ATA can't register properly when it's  
behind NAT.
Apparently, SIP replies aren't sent back to the port on the external  
IP of the NAT gw, where the initial request originated from.

The situation is as follows:

UA (172.31.0.55) ---- (172.31.0.1) NAT GW (1.1.210.76) -----  
(1.1.232.18) FS

The UA registers to a profile with these settings:

   <settings>
     <param name="debug" value="0"/>
     <param name="sip-trace" value="no"/>
     <param name="rfc2833-pt" value="101"/>
     <param name="dialplan" value="XML"/>
     <param name="context" value="cust"/>
     <param name="dtmf-duration" value="100"/>
     <param name="use-rtp-timer" value="true"/>
     <param name="rtp-timer-name" value="soft"/>
     <param name="manage-presence" value="false"/>
     <param name="aggressive-nat-detection" value="true"/>
     <param name="apply-nat-acl" value="rfc1918"/>
     <param name="nonce-ttl" value="60"/>
     <param name="auth-calls" value="false"/>
     <param name="rtp-timeout-sec" value="1800"/>
     <param name="rtp-ip" value="1.1.232.18"/>
     <param name="sip-ip" value="1.1.232.18"/>
     <param name="sip-port" value="5060"/>
     <param name="rtp-timeout-sec" value="300"/>
     <param name="rtp-hold-timeout-sec" value="1800"/>
     <param name="inbound-late-negotiation" value="true"/>
     <param name="accept-blind-reg" value="false"/>
     <param name="disable-transcoding" value="true"/>
     <param name="manage-presence" value="true"/>
     <param name="auth-calls" value="true"/>
     <param name="auth-all-packets" value="false"/>
     <param name="disable-transfer" value="true"/>
     <param name="disable-register" value="false"/>
     <param name="tls" value="false"/>
     <param name="odbc-dsn" value="freeswitch:freeswitch:freeswitch"/>
   </settings>

First I tried without STUN, and got the following trace:

U 2008/07/22 21:03:48.983041 1.1.210.76:57501 -> 1.1.232.18:5060
REGISTER sip:test.nl:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.31.0.55:5060;branch=z9hG4bK57489228aa596f71.
Max-Forwards: 70.
To: <sip:ldr-line1 at test.nl>.
From: <sip:ldr-line1 at test.nl>;tag=xETN4EDMxED.
Call-ID: 928BD3011481111 at 172.31.0.55.
CSeq: 2 REGISTER.
Contact: <sip:ldr-line1 at 172.31.0.55:5060>.
Content-Length: 0.
Expires: 3600.
.

U 2008/07/22 21:03:48.983421 1.1.232.18:5060 -> 1.1.210.76:5060
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP  
172.31.0.55:5060;branch=z9hG4bK57489228aa596f71;received=1.1.210.76.
From: <sip:ldr-line1 at test.nl>;tag=xETN4EDMxED.
To: <sip:ldr-line1 at test.nl>;tag=02F7cjtcp4cvS.
Call-ID: 928BD3011481111 at 172.31.0.55.
CSeq: 2 REGISTER.
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-9117M.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,  
NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH.
Supported: 100rel, timer, precondition, path, replaces.
WWW-Authenticate: Digest realm="test.nl", nonce="d7ddacbe-5820-11dd- 
a225-93e83ac49152", algorithm=MD5, qop="auth".
Content-Length: 0.
.

So, the reply sent from FS to the NAT gw, is sent to port 5060, while  
it originated from port 57501. Result is, that the '401 Unauthorized'  
never arrives at the ATA.

Then I tried enabling STUN in the ATA, and got another result:

U 2008/07/22 21:09:54.015734 1.1.210.76:61341 -> 1.1.232.18:5060
REGISTER sip:test.nl:5060 SIP/2.0.
Via: SIP/2.0/UDP 1.1.210.76:59173;branch=z9hG4bK482f2934fda524ff.
Max-Forwards: 70.
To: <sip:ldr-line1 at test.nl>.
From: <sip:ldr-line1 at test.nl>;tag=xIzM4EDMxID.
Call-ID: 799E6DDE35D1111 at 1.1.210.76.
CSeq: 1 REGISTER.
Contact: <sip:ldr-line1 at 1.1.210.76:59173>.
Content-Length: 0.
Expires: 3600.
.

U 2008/07/22 21:09:54.015995 1.1.232.18:5060 -> 1.1.210.76:59173
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP 1.1.210.76:59173;branch=z9hG4bK482f2934fda524ff.
From: <sip:ldr-line1 at test.nl>;tag=xIzM4EDMxID.
To: <sip:ldr-line1 at test.nl>;tag=2m2rg8UKgpS1g.
Call-ID: 799E6DDE35D1111 at 1.1.210.76.
CSeq: 1 REGISTER.
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-9117M.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,  
NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH.
Supported: 100rel, timer, precondition, path, replaces.
WWW-Authenticate: Digest realm="test.nl", nonce="bfbe5042-5821-11dd- 
a225-93e83ac49152", algorithm=MD5, qop="auth".
Content-Length: 0.
.

Now the reply is sent back to port 59173. That's the same as in the  
Contact as it's sent by the ATA. Does this mean STUN doesn't function  
properly ? I am using stun.fwdnet.net:3478 (ATA is a Zyxel P2002).

Can I force FS to reply always to the port where the original message  
originated from ? Or should I fix this differently ?

Thanks in advance,

Leon de Rooij