Hi All: We have seen many PBX NAT?ed behind a Firewall that does not do the Sip ALG correctly. Most cases putting the Private IP in the Contact header and the ACME responds back to the Private IP. Example call inbound to the PBX, the PBX sends a 200 OK (as call is answered) with a Private IP in the contact header. ACME sends the ACK back to the Private IP blackholing it. I have seen SBC?s that do adjust to the Layer 3 IP:port if they notice Private IPs in the SIP signaling. Is there a setting on ACME to do that? Thx, UK
On 06/08/2011 11:36 PM, Ujjval Karihaloo wrote:
I have seen SBC?s that do adjust to the Layer 3 IP:port if they notice Private IPs in the SIP signaling. Is there a setting on ACME to do that?
Yes, although I do not know what it is offhand. But we have worked with providers who set theirs to do that for customers of ours. It is the standard far-end NAT traversal technique. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On 6/8/11 11:36 PM, Ujjval Karihaloo wrote:
Hi All:
We have seen many PBX NAT?ed behind a Firewall that does not do the Sip ALG correctly. Most cases putting the Private IP in the Contact header and the ACME responds back to the Private IP.
Example call inbound to the PBX, the PBX sends a 200 OK (as call is answered) with a Private IP in the contact header. ACME sends the ACK back to the Private IP blackholing it.
I have seen SBC?s that do adjust to the Layer 3 IP:port if they notice Private IPs in the SIP signaling. Is there a setting on ACME to do that?
Read up on nat-traversal always in the sip interface section of the config. I will note, however, that that looks for the Contact-URI and topmost VIA to match and to be different than the source address in layer 3 (IP), rather than looking for RFC 1918 addresses. Of course, given that there are umpteen hundred knobs to twist on an Acme, there's probably some way of getting it to do this only for RFC 1918 addresses, but I'm not sure there's value in doing that and certainly couldn't tell you how to do it. My understanding is that "nat-traversal always" is the "normal" way of doing what you appear to need. As an operational note, we've had more problems with various customer firewalls doing pretty bad jobs with SIP, such as the one that worked fine until somebody transferred a call at which point the firewall just dropped all sorts of vital packets on the floor, than we've ever had just letting our Acmes do NAT traversal. Our standard recommendation is to turn all SIP aware proxies, fix-up, etc. off. --Jon Radel
Jon is correct in that you may want to test "nat-traversal always" when the SIP-Via and transport addresses do not match. In fact, this is recommended (by Broadsoft) if you are using Broadworks as the SIP Registrar platform fronted by an SD. That being said, Jon also has a valid point that SIP ALG for IP PBX's has a known track record of compatibility issues. In some cases basic inbound/outbound call flow may work but calls forwarded or transferred to the PSTN may likely experience one way audio. There are some compensation measures that can be addressed on Cisco Pix/ASA firewalls that deal with this, but in most cases it's an unfortunate fact of life that the ITSP cannot force a customer to use a specific firewall and therefore has to go through rigorous testing and support for SIP Trunking validation on their network. This is where a true B2BUA may provide much better results and eliminate most the headache that is associated with testing/supporting SIP Trunking from an IP PBX into a Softswitch. On the surface most would think an IP PBX may be treated like any other SIP-HNT device or perhaps a SIP ALG would provide full interoperability, but this is usually not the case. On Jun 8, 2011, at 9:12 PM, Jon Radel wrote:
On 6/8/11 11:36 PM, Ujjval Karihaloo wrote:
Hi All:
We have seen many PBX NAT?ed behind a Firewall that does not do the Sip ALG correctly. Most cases putting the Private IP in the Contact header and the ACME responds back to the Private IP.
Example call inbound to the PBX, the PBX sends a 200 OK (as call is answered) with a Private IP in the contact header. ACME sends the ACK back to the Private IP blackholing it.
I have seen SBC?s that do adjust to the Layer 3 IP:port if they notice Private IPs in the SIP signaling. Is there a setting on ACME to do that?
Read up on nat-traversal always in the sip interface section of the config. I will note, however, that that looks for the Contact-URI and topmost VIA to match and to be different than the source address in layer 3 (IP), rather than looking for RFC 1918 addresses. Of course, given that there are umpteen hundred knobs to twist on an Acme, there's probably some way of getting it to do this only for RFC 1918 addresses, but I'm not sure there's value in doing that and certainly couldn't tell you how to do it. My understanding is that "nat-traversal always" is the "normal" way of doing what you appear to need.
As an operational note, we've had more problems with various customer firewalls doing pretty bad jobs with SIP, such as the one that worked fine until somebody transferred a call at which point the firewall just dropped all sorts of vital packets on the floor, than we've ever had just letting our Acmes do NAT traversal. Our standard recommendation is to turn all SIP aware proxies, fix-up, etc. off.
--Jon Radel _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Depending on your business model simply telling the customer how their firewall should be configured may work, but its not something that i suspect will take you too far since you are leaving the ability to break your service in the hands of your customer, which ultimately means they will break it, then be cross at you for something they did. Not an enviable situation at all. We have had a great deal of success simply abandoning port 5060 and using port numbers over 10000 on the endpoint and SBC, since most ALG's simply do protocol detection based on port, this will dodge much of your ALG/fixup headaches straight away. There are of course still some CPE routers with a more clever ALG that will catch this, but it dramatically reduces your exposure. Also to any CPE hardware manufacturers out there reading this....STOP IT! You know who you are..... :) -anorexicpoodle On Thu, 2011-06-09 at 00:12 -0400, Jon Radel wrote:
On 6/8/11 11:36 PM, Ujjval Karihaloo wrote:
Hi All:
We have seen many PBX NAT?ed behind a Firewall that does not do the Sip ALG correctly. Most cases putting the Private IP in the Contact header and the ACME responds back to the Private IP.
Example call inbound to the PBX, the PBX sends a 200 OK (as call is answered) with a Private IP in the contact header. ACME sends the ACK back to the Private IP blackholing it.
I have seen SBC?s that do adjust to the Layer 3 IP:port if they notice Private IPs in the SIP signaling. Is there a setting on ACME to do that?
Read up on nat-traversal always in the sip interface section of the config. I will note, however, that that looks for the Contact-URI and topmost VIA to match and to be different than the source address in layer 3 (IP), rather than looking for RFC 1918 addresses. Of course, given that there are umpteen hundred knobs to twist on an Acme, there's probably some way of getting it to do this only for RFC 1918 addresses, but I'm not sure there's value in doing that and certainly couldn't tell you how to do it. My understanding is that "nat-traversal always" is the "normal" way of doing what you appear to need.
As an operational note, we've had more problems with various customer firewalls doing pretty bad jobs with SIP, such as the one that worked fine until somebody transferred a call at which point the firewall just dropped all sorts of vital packets on the floor, than we've ever had just letting our Acmes do NAT traversal. Our standard recommendation is to turn all SIP aware proxies, fix-up, etc. off.
--Jon Radel
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
anorexicpoodle wrote:
Depending on your business model simply telling the customer how their firewall should be configured may work, but its not something that i suspect will take you too far since you are leaving the ability to break your service in the hands of your customer, which ultimately means they will break it, then be cross at you for something they did. Not an enviable situation at all.
We had our marketing and documentation company work up a one-page explanation on this, and it's been very effective at explaining why this is their problem and not ours. It not only saves the typing, but seems to have some weight by looking "official" rather than some tech support guy saying "it's not my problem." -- Carlos Alvarez TelEvolve 602-889-3003
Agreed, we do the same for situations where the firewall is so poorly behaved there is nothing to be done, however by fiddling with the ports, we reduced those cases by an order of magnitude, giving many more customers the "It just works" experience. On Thu, 2011-06-09 at 09:42 -0700, Carlos Alvarez wrote:
anorexicpoodle wrote:
Depending on your business model simply telling the customer how their firewall should be configured may work, but its not something that i suspect will take you too far since you are leaving the ability to break your service in the hands of your customer, which ultimately means they will break it, then be cross at you for something they did. Not an enviable situation at all.
We had our marketing and documentation company work up a one-page explanation on this, and it's been very effective at explaining why this is their problem and not ours. It not only saves the typing, but seems to have some weight by looking "official" rather than some tech support guy saying "it's not my problem."
Are you indicating that simply using the higher port numbers without ALG invokes a more successful and consistent behavior for IP PBX trunking or is this specific to Hosted IP? On Jun 9, 2011, at 9:35 AM, anorexicpoodle wrote:
We have had a great deal of success simply abandoning port 5060 and using port numbers over 10000 on the endpoint and SBC, since most ALG's simply do protocol detection based on port, this will dodge much of your ALG/fixup headaches straight away. There are of course still some CPE routers with a more clever ALG that will catch this, but it dramatically reduces your exposure.
No what I am indicating is that by not using port 5060, or another well known port, most ALG's in CPE routers will simply ignore your SIP traffic and allow it to pass un-molested so the SD can get on with its job and do NAT traversal in a consistent and reliable fashion. Most poorly behaved ALGs in CPE routers only use source/destination port to detect if the traffic should be passed through the ALG. Its simple, dodge the match rule and the ALG doesn't get applied, no need to have the customer change the config on their firewall or router, and your product auto-magically "just works". On Thu, 2011-06-09 at 21:51 -0700, Mark Holloway wrote:
Are you indicating that simply using the higher port numbers without ALG invokes a more successful and consistent behavior for IP PBX trunking or is this specific to Hosted IP?
On Jun 9, 2011, at 9:35 AM, anorexicpoodle wrote:
We have had a great deal of success simply abandoning port 5060 and using port numbers over 10000 on the endpoint and SBC, since most ALG's simply do protocol detection based on port, this will dodge much of your ALG/fixup headaches straight away. There are of course still some CPE routers with a more clever ALG that will catch this, but it dramatically reduces your exposure.
participants (6)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
carlos＠televolve.com -
jradel＠vantage.com -
mh＠markholloway.com -
ujjval＠simplesignal.com