[Freeswitch-users] NAT traversal questions - (long)...
David Ponzone
david.ponzone at ipeva.fr
Sun Aug 29 02:46:24 PDT 2010
Brian,
I am not sure.
Dave said its device cannot register anymore.
In your doc, it says the INVITE won't work because of the port
mismatch with the REGISTER.
BTW, what kind of crappy firewall does that...
A firewall is supposed to keep the same source port during the
lifetime of the translation, which can be a very long time if you send
regular keepalives.
To change it between a REGISTER and an INVITE, a firewall would need
to have some kind of SIP ALG, and that's dodgy.
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 à 11:29, broken dash a écrit :
> I came across this sipx troubleshooting faq talking about how
> pfsense's port radomization jacks things up and they go on to describe
> how you solved your problem. It seems almost certain that it's the
> cause, but surely the linux port randomization would be equally as
> problematic as the bsd version...
>
> http://sipx-wiki.calivia.com/index.php/SipXbridge_Overview_and_Configuration
>
> I wonder if u installed the freeswitch package on your pfsense
> firewall and configured it be a B2BUA if that would react in the same
> way...
>
>
>
> Cheers,
> Brian
>
>
> On Sun, Aug 29, 2010 at 3:15 AM, David Ponzone <davtod.ponzone at ipeva.fr
> > wrote:
>> Dave,
>> quite quickly, it's obvious your FreeSWITCH is no longer able to
>> detect that
>> your HT-287 is behind NAT.
>> One possiblity is that the rport is missing from the REGISTER.
>> Perhaps your pfsense is messing with it ?
>> So to start, I would recommend you take a trace when the packet
>> enters
>> pfsense and when it goes out to your proxy, and compare them to see
>> any
>> differences.
>> 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 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 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/20100829/231dbbd7/attachment-0001.html
More information about the FreeSWITCH-users
mailing list