NAT traversal questions - (long)...
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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111 Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111 Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111 Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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
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@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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111
Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111
Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111
Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg- id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111
Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111
Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111
Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111
Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111
Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111
Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg- id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Ipcop has a similar setting to pfsense. You probably missed it. MOST FIREWALLS do not use static port NAT. The default rules for pfsense (and packages) for port 5060 should be removed. On your outbound rule for your LAN static port nat needs to be enabled. Once you do that recreate the nat rules AND remove the siproxd package by default. This is really a pfsense firewall question, it is clear static port was not enabled so the source port was re-written because that is what MOST firewalls do by default. On 8/29/10, Dave Redmore <dave.redmore@spigotsystems.com> wrote:
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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111
Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111
Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111
Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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
-- Sent from my mobile device ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgraziano@voice.myitdepartment.net Fax: 434.984.8431 Email: tgraziano@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpdesk@voice.myitdepartment.net Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
Yeah, the sipxroxd is in the installed packages on his build. Remove the intsalled package and make sure the default rule for outgoing traffic is set for manual/static nat, not automatic. http://blog.myitdepartment.net/?p=37 On Sun, Aug 29, 2010 at 7:40 AM, Tony Graziano <tgraziano@myitdepartment.net> wrote:
Ipcop has a similar setting to pfsense. You probably missed it.
MOST FIREWALLS do not use static port NAT. The default rules for pfsense (and packages) for port 5060 should be removed.
On your outbound rule for your LAN static port nat needs to be enabled. Once you do that recreate the nat rules AND remove the siproxd package by default.
This is really a pfsense firewall question, it is clear static port was not enabled so the source port was re-written because that is what MOST firewalls do by default.
On 8/29/10, Dave Redmore <dave.redmore@spigotsystems.com> wrote:
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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111
Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111
Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111
Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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
-- Sent from my mobile device
====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgraziano@voice.myitdepartment.net Fax: 434.984.8431
Email: tgraziano@myitdepartment.net
LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpdesk@voice.myitdepartment.net Fax: 434.984.8427
Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/
Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
-- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgraziano@voice.myitdepartment.net Fax: 434.984.8431 Email: tgraziano@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpdesk@voice.myitdepartment.net Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
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@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@192.168.1.137 User: 8885554525@173.11.22.111 Contact: "user" <sip:8885554525@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@173.11.22.111
Call-ID: 1716488819-5062-1@192.168.7.150 User: 8885554544@173.11.22.111 Contact: "user" <sip:8885554544@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@173.11.22.111
Call-ID: 090ee80e1a0ec9ed@10.8.11.149 User: 8885554549@173.11.22.111 Contact: "user" <sip:8885554549@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@173.11.22.111
Call-ID: 1035241259-5060-1@10.1.10.150 User: 8885554547@173.11.22.111 Contact: "user" <sip:8885554547@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@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@173.11.22.111:5090>;tag=c8a0d452edc5ac4b SIP from address: sip:8885554549@173.11.22.111:5090 SIP tag: c8a0d452edc5ac4b To: <sip:8885554549@173.11.22.111:5090> Contact: <sip:88855564549@10.8.11.149:5062> Contact Binding: <sip:8885554549@10.8.11.149:5062> Supported: replaces, timer Call-ID: aa77d777bae71be6@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@173.11.22.111:5090>;tag=8dc68b35111c4261 To: <sip:8156564525@173.15.28.101:5090> Contact: <sip:8885554525@192.168.1.137> Contact Binding: <sip:8885554525@192.168.1.137> Call-ID: 0e551b3c694a793c@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@173.11.22.111:5090;user=phone>;tag=138706651 To: <sip:8885554547@173.11.22.111:5090;user=phone> Call-ID: 1035241259-5060-1@10.1.10.150 CSeq: 79875 REGISTER Sequence Number: 79875 Method: REGISTER Contact: <sip:8885554547@10.1.10.150:5060;user=phone>;reg- id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B821F9A84>" Contact Binding: <sip:8885554547@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
broken dash
-
Dave Redmore
-
David Ponzone
-
Tony Graziano