[Freeswitch-users] NAT traversal questions - (long)...

David Ponzone david.ponzone at ipeva.fr
Mon Aug 30 07:38:30 PDT 2010


Because for RTP, FS does RTP auto-adjust.
Whatever was offered in the SDP, it waits for an inbound stream on the  
port it announced to the client, and lears the real ip/port from that  
stream.
That's the same mechanism most commercial SBCs use.

David Ponzone  Direction Technique
email: david.ponzone at ipeva.fr
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client IPeva
tel:      0811 46 26 26
www.ipeva.fr  -   www.ipeva-studio.com

Ce message et toutes les pièces jointes sont confidentiels et établis  
à l'intention exclusive de ses destinataires. Toute utilisation ou  
diffusion non autorisée est interdite. Tout message électronique est  
susceptible d'altération. IPeva décline toute responsabilité au  
titre de ce message s'il a été altéré, déformé ou falsifié. Si  
vous n'êtes pas destinataire de ce message, merci de le détruire  
immédiatement et d'avertir l'expéditeur.




Le 30/08/2010 à 15:43, Dave Redmore a écrit :

> Thanks for the thoughtful response.  I think that it has been by  
> some happy accident that I have not run into more NAT issues.  I  
> usually expect to have problems and then rarely do.  For example, I  
> have a FreePBX server sitting behind the pfSense as well (on a  
> different subnet) which is my main office phone system, it is  
> connected to my ITSP (Teliax) with absolutely no problems - no port  
> forward or static port NATing needed - as soon as I cut over to the  
> pfSense, I was up and running.
>
> I think you are right re: with the rport issue.  At the end of the  
> day, I think the combination of Freeswitch not detecting NAT and the  
> HT-287 not supporting rport was what caused the problem.
>
> Will be doing some more investigating on all this - in particular I  
> am now curious to look into how/why my RTP streams work.  I have  
> about a dozen customers running various combination's of FreePBX/ 
> ATAs/Etc and have never had audio issues - again, probably a happy  
> accident, but now I am motivated to understand the dance that is  
> happening between everything.
>
> Thanks again,
>
> Dave
>
> ----- Original Message -----
> From: "David Ponzone" <david.ponzone at ipeva.fr>
> To: "FreeSWITCH Users Help" <freeswitch-users at lists.freeswitch.org>
> Sent: Sunday, August 29, 2010 5:06:36 PM GMT -06:00 US/Canada Central
> Subject: Re: [Freeswitch-users] NAT traversal questions - (long)...
>
> Dave,
>
> I misread your mail the first time and did not see you sent traces.
>
> I think there are some interesting things in those.
>
> For the packet coming from your HT-287 without the static port NAT:
> Via: SIP/2.0/UDP 10.8.11.149:5062;branch=z9hG4bKda48f838c8689e41
> -> rport is missing
>
> For the packet coming from the one behind a DD-WRT:
> rport is missing too, but the source port in the Via matches the  
> source port of the packet, so it works, the same way it works with  
> your pfSense if you add the static port NAT.
> But why FS manages to guess it's behind NAT eludes me, but the NAT  
> detecting algo in FS is clearly complex.
>
> For the packet coming from the HT-503:
> I think you made a mistake. You said at the beginning of your mail  
> that it is behind DD-WRT, but before the trace, you say "one more  
> packet coming from Comcast/SMC".
> Anyway, this one is interesting.
> rport is there, so HT-503 is rport-capable (but HT-287 is not).
> I would check if a configuration or a firmware upgrade could enable  
> rport on the HT-287.
>
> Also, you wonder if modern routers have some automatic static NAT.
> Actually, no, but what they do quite often is to not change the  
> source port of the packet if this port is available on the external  
> interface.
> For instance, if your device sends a packet from port 5060, and this  
> port is free on the external side of the router, it will preserve  
> 5060.
> Then if a second device sends a packet from port 5060, as it is  
> already used, it will use a random port.
> You end up having a pseudo static NAT behaviour for the first device  
> on your network.
> I saw that on business routers from Draytek, Funkwerk and others.
> So perhaps your ipcop was doing that ?
> Wild guess: if you add a second phone with the same source port 5060  
> behind a DD-WRT router, I am pretty sure you will have issues with  
> its registration.
>
> About your question "is FreeSWITCH not tagging the device as behind  
> nat because it is on the same subnet as pfSense ?".
> That's quite possible.
> I think there are places in FS conf where you define what is local.  
> I think it's the special keyword localnet.auto.
>
> But I really think the end of all isues is rport.
> If rport is not available on your device, you can still force rport  
> on FS side:
> <param name="NDLB-force-rport" value="true"/>
>
> David Ponzone  Direction Technique
> email: david.ponzone at ipeva.fr
> tel:      01 74 03 18 97
> gsm:   06 66 98 76 34
>
> Service Client IPeva
> tel:      0811 46 26 26
> www.ipeva.fr  -   www.ipeva-studio.com
>
> Ce message et toutes les pièces jointes sont confidentiels et  
> établis à l'intention exclusive de ses destinataires. Toute  
> utilisation ou diffusion non autorisée est interdite. Tout message  
> électronique est susceptible d'altération. IPeva décline toute  
> responsabilité au titre de ce message s'il a été altéré,  
> déformé ou falsifié. Si vous n'êtes pas destinataire de ce  
> message, merci de le détruire immédiatement et d'avertir  
> l'expéditeur.
>
>
>
>
> Le 29/08/2010 à 09:01, Dave Redmore a écrit :
>
> Hello All,
>
> I ran into an issue today that has burned up most of my day  
> troubleshooting.  I have resolved the problem, but would really like  
> to understand what caused it, or some of the internal Freeswitch  
> plumbing that is at play so that I can learn something from all of  
> this time I have invested.
>
> I have a Freeswitch server running that acts as a proxy to an  
> account with an ITSP for doing T38 faxing.  The Freeswitch server  
> has a public IP address - there are four "users" who register simple  
> FXS ATAs to my server and it then proxies to the ITSP using the  
> "proxy_media" functionality.  It has been working very well for the  
> last 6 months or so.  I have never had to deal with any NAT  
> traversal issues - I just point the ATA to the IP to register and  
> everything is great.
>
> Here is what the four users "looked" like -
>
> User1 :  Grandstream HT-287 -> DD-WRT Router (NAT) -> Internet ->  
> Freeswitch Proxy
> User2 :  Grandstream HT-503 -> DD-WRT Router (NAT) -> Internet ->  
> Freeswitch Proxy
> User3 :  Grandstream HT-502 -> Comcast/SMC Router (NAT) -> Internet - 
> > Freeswitch Proxy
> User4 :  Grandstream HT-287 -> IPCOP 1.4.11 (NAT) -> Comcast Gateway  
> -> Freeswitch Proxy
>
> (User4 is my office, so the IPCOP firewall and the Freeswitch Proxy  
> sit on the same Comcast Gateway)
>
> As I said, this all worked perfectly without any need to "fiddle"  
> with anything on any firewalls - worked right out of the box.
>
> So, today I changed out my IPCOP firewall for a pfsense firewall -  
> and my HT-287 would no longer register.
>
> After much head-scratching, packet captures, etc. I found that I  
> needed to set up a Static Port NAT for the port the HT-287 was using  
> (5062) in order to get this to work.
>
> So, I see WHAT is happening, but I really want to know WHY it is  
> happening.
>
> Here are the gory details:
>
> The sofia status of the profile looks like this - when the I have  
> the Static Port NAT in place (details changed for security):
>
> _______________________________________________________________
> Call-ID:        0e551b3c694a793c at 192.168.1.137
> User:           8885554525 at 173.11.22.111
> Contact:        "user" <sip:8885554525 at 192.168.1.137;fs_nat=yes;fs_path=sip%3A8885554525%40173.22.22.55%3A5060 
> >
> Agent:          Grandstream HT287 1.1.0.45 DevId 000b821203c5
> Status:         Registered(UDP-NAT)(unknown) EXP(2010-08-29 01:17:03)
> Host:           173-11-22-111-illinois.hfc.comcastbusiness.net
> IP:             173.22.22.55
> Port:           5060
> Auth-User:      8885554525
> Auth-Realm:     173.11.22.111
> MWI-Account:    8885554525 at 173.11.22.111
>
> Call-ID:        1716488819-5062-1 at 192.168.7.150
> User:           8885554544 at 173.11.22.111
> Contact:        "user" <sip:8885554544 at 192.168.7.150:5062;user=phone;fs_nat=yes 
> ;   fs_path=sip%3A8885554544%4098.255.0.11%3A5062%3Buser%3Dphone>
> Agent:          Grandstream HT-502  V1.1B 1.0.1.63
> Status:         Registered(UDP-NAT)(unknown) EXP(2010-08-29 01:48:35)
> Host:           173-11-22-111-illinois.hfc.comcastbusiness.net
> IP:             98.255.0.11
> Port:           5062
> Auth-User:      8885554544
> Auth-Realm:     173.11.22.111
> MWI-Account:    8885554544 at 173.11.22.111
>
> Call-ID:        090ee80e1a0ec9ed at 10.8.11.149
> User:           8885554549 at 173.11.22.111
> Contact:        "user" <sip:8885554549 at 10.8.11.149:5062>
> Agent:          Grandstream HT287 1.1.0.45 DevId 000b82127390
> Status:         Registered(UDP)(unknown) EXP(2010-08-29 02:00:42)
> Host:           173-11-22-111-illinois.hfc.comcastbusiness.net
> IP:             173.11.22.99
> Port:           5062
> Auth-User:      8885554549
> Auth-Realm:     173.11.22.111
> MWI-Account:    8885554549 at 173.11.22.111
>
> Call-ID:        1035241259-5060-1 at 10.1.10.150
> User:           8885554547 at 173.11.22.111
> Contact:        "user" <sip:8885554547 at 10.1.10.150:5060;user=phone;fs_nat=yes;fs 
>    _path=sip%3A8885554547%4098.222.55.100%3A5060%3Buser%3Dphone>
> Agent:          Grandstream HT-503  V1.1B 1.0.1.63
> Status:         Registered(UDP-NAT)(unknown) EXP(2010-08-29 00:15:09)
> Host:           173-11-22-111-illinois.hfc.comcastbusiness.net
> IP:             98.222.55.100
> Port:           5060
> Auth-User:      8885554547
> Auth-Realm:     173.11.22.111
> MWI-Account:    8885554547 at 173.11.22.111
> ___________________________________________________________
>
> The "User4" account is in red.  The "Contact" field is substantially  
> different and the "Status" indicates "Registered (UDP)", rather than  
> "Registered (UDP-NAT)" as the others.
>
> When I do a packet capture on the external NIC interface (eth0) - I  
> see the following when the HT-287 tries to register and the Static  
> Port NAT is NOT in place:
>
> ___________________________________________________________________
> Internet Protocol, Src: 173.11.22.99 (173.11.22.99), Dst:  
> 173.11.22.111 (173.11.22.111)
> User Datagram Protocol, Src Port: 11521 (11521), Dst Port: 5090 (5090)
> Session Initiation Protocol
>     Request-Line: REGISTER sip:173.11.22.111:5090 SIP/2.0
>         Method: REGISTER
>         Request-URI: sip:173.11.22.111:5090
>             Request-URI Host Part: 173.11.22.111
>             Request-URI Host Port: 5090
>     Message Header
>         Via: SIP/2.0/UDP  
> 10.8.11.149:5062;branch=z9hG4bKda48f838c8689e41
>             Transport: UDP
>             Sent-by Address: 10.8.11.149
>             Sent-by port: 5062
>             Branch: z9hG4bKda48f838c8689e41
>         From: <sip:8885554549 at 173.11.22.111:5090>;tag=c8a0d452edc5ac4b
>             SIP from address: sip:8885554549 at 173.11.22.111:5090
>             SIP tag: c8a0d452edc5ac4b
>         To: <sip:8885554549 at 173.11.22.111:5090>
>         Contact: <sip:88855564549 at 10.8.11.149:5062>
>             Contact Binding: <sip:8885554549 at 10.8.11.149:5062>
>         Supported: replaces, timer
>         Call-ID: aa77d777bae71be6 at 10.8.11.149
>         CSeq: 100 REGISTER
>             Sequence Number: 100
>             Method: REGISTER
>         Expires: 3600
>         User-Agent: Grandstream HT287 1.1.0.45 DevId 000b82127390
>         Max-Forwards: 70
>         Allow:  
> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
>         Content-Length: 0
> _______________________________________________________________
>
> When Freeswitch replies back with a "401 Unauthorized" - asking for  
> further Auth - it replies back to port 5062 - so the packet never  
> comes back (pfsense is looking for a packet back on port 11521 in  
> this case).
>
> If I put the Static Port NAT in place - all is well, because the  
> "Source" port shows as "5062" - the rest of the packet looks pretty  
> much the same.
>
> Now, here is a packet coming from one of the other Users - this one  
> comes through a DD-WRT router - here we see that the Source Port is  
> 5060 :
>
> _________________________________________________________________
> Internet Protocol, Src: 173.22.22.55 (173.22.22.55), Dst:  
> 173.11.22.111 (173.11.22.111)
> User Datagram Protocol, Src Port: sip (5060), Dst Port: 5090 (5090)
> Session Initiation Protocol
>     Request-Line: REGISTER sip:173.11.22.111:5090 SIP/2.0
>         Method: REGISTER
>         Request-URI: sip:173.11.22.111:5090
>         [Resent Packet: False]
>     Message Header
>         Via: SIP/2.0/UDP 192.168.1.137;branch=z9hG4bK665bc67a1c64292b
>             Transport: UDP
>             Sent-by Address: 192.168.1.137
>             Branch: z9hG4bK665bc67a1c64292b
>         From: "fax" <sip: 
> 8885554525 at 173.11.22.111:5090>;tag=8dc68b35111c4261
>         To: <sip:8156564525 at 173.15.28.101:5090>
>         Contact: <sip:8885554525 at 192.168.1.137>
>             Contact Binding: <sip:8885554525 at 192.168.1.137>
>         Call-ID: 0e551b3c694a793c at 192.168.1.137
>         CSeq: 503 REGISTER
>             Sequence Number: 503
>             Method: REGISTER
>         Expires: 3600
>         User-Agent: Grandstream HT287 1.1.0.45 DevId 000b821203c5
>         Max-Forwards: 70
>         Allow:  
> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
>         Content-Length: 0
> ______________________________________________________________________
>
> Here is one more packet coming from a Comcast/SMC Router - again,  
> the source port is correct:
>
> ______________________________________________________________________
>  Internet Protocol, Src: 98.244.55.100 (98.244.55.100), Dst:  
> 173.11.22.111 (173.11.22.111)
> User Datagram Protocol, Src Port: sip (5060), Dst Port: 5090 (5090)
> Session Initiation Protocol
>     Request-Line: REGISTER sip:173.11.22.111:5090 SIP/2.0
>     Message Header
>         Via: SIP/2.0/UDP 10.1.10.150:5060;branch=z9hG4bK58981045;rport
>             Transport: UDP
>             Sent-by Address: 10.1.10.150
>             Sent-by port: 5060
>             Branch: z9hG4bK58981045
>             RPort: rport
>         From: <sip: 
> 8885554547 at 173.11.22.111:5090;user=phone>;tag=138706651
>         To: <sip:8885554547 at 173.11.22.111:5090;user=phone>
>         Call-ID: 1035241259-5060-1 at 10.1.10.150
>         CSeq: 79875 REGISTER
>             Sequence Number: 79875
>             Method: REGISTER
>         Contact: <sip:8885554547 at 10.1.10.150:5060;user=phone>;reg- 
> id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>"
>             Contact Binding: <sip:8885554547 at 10.1.10.150:5060;user=phone 
> >;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84 
> >"
>         Max-Forwards: 70
>         User-Agent: Grandstream HT-503  V1.1B 1.0.1.63
>         Supported: path
>         Expires: 300
>         Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY,  
> INFO, REFER, UPDATE
>         Content-Length: 0
> ___________________________________________________________
>
> So, here are my questions:
>
> - Why is the Sofia Status so much different for the registration  
> coming through the pfSense firewall.  It looks like it doesn't get  
> tagged as being NAT'd and the "Contact" info is much less.
>
> - Do most modern routers automatically Static Port NAT any SIP  
> traffic?  Both DD-WRT and SMC routers appear to be doing this - and  
> not just on a simple Port bases (UDP 5060 only), because one of  
> these examples is on 5062.  Are these "SIP aware" firewalls that are  
> doing this automatically, as  the IPCOP did before?
>
> - Is the extra "Contact" data in the last packet example different  
> because it is a different UA (HT-503 rather than an HT-287)
>
> - Is Freeswitch not flagging the registration from my office (User4)  
> as being NAT'd because it is coming in on the same subnet as the  
> interface Freeswitch received the packet on (Freeswitch is at  
> 173.11.22.111 and pfsense is at 173.11.22.99)?
>
> Sorry for this terribly long posting - I'm just very curious to  
> understand what is going on here, now that I have collected all this  
> information.
>
> Thanks,
>
> Dave
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
> _______________________________________________ FreeSWITCH-users  
> mailing listFreeSWITCH-users at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users 
>  UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100830/3edeab1f/attachment-0001.html 


More information about the FreeSWITCH-users mailing list