[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