Summary: | ASTERISK-04493: Asterisk behind a Cisco PIX 515E firewall using fixup protocol | ||
Reporter: | Paul Belanger (pabelanger) | Labels: | |
Date Opened: | 2005-06-28 12:50:59 | Date Closed: | 2011-06-07 14:09:59 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) sip-debug.txt | |
Description: | When using fixup protocol on the Cisco PIX, asterisk will always fail to registar an UA (Mitel 5055); 403 Forbidden is always returned. SIP Debug is attached Mitel 5055 (67.71.252.110) Cisco PIX 515E: - External (67.71.252.108) - Internal (172.16.128.1) Asterisk CVS HEAD (172.16.128.2) Let me know if addition information is required. ****** ADDITIONAL INFORMATION ****** Solution: Issue no fixup protocol sip udp 5060. | ||
Comments: | By: Paul Belanger (pabelanger) 2005-06-28 12:54:24 sip.conf for Mitel 5055. [mitel5055] type=friend username=mitel5055 secret=mitel host=dynamic canreinvite=no I also tried playing with nat=yes/no, and still was unable to find a solution. By: Mark Spencer (markster) 2005-07-10 06:01:09 What makes you think this is an asterisk bug since disabling the fixup on the PIX is what solves the problem? By: Paul Belanger (pabelanger) 2005-07-10 10:16:01 This is the reason: <snip> If either SIP fixup method is enabled, SIP packets are inspected and then NAT is provided for the appropriate IP addresses. </snip> http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727a8.html#wp1124805 Using this command, the PIX will be responsible for re-writing the packets to allow SIP via NAT. When enabled, SIP UAs do not have to worry about SIP and NAT. It will be up to the PIX to handle this; and currently it works fine for my other UAs. Adding Asterisk to the picture, behind the PIX's, Asterisk will not authenicate a UA while 'fixup protocol' is enabled. I don't believe disabling the command is a good solution, because you take away an important feature from the PIX. By: Tilghman Lesher (tilghman) 2005-07-10 11:44:52 Unless you can identify a specific problem that you believe Asterisk to have, this has very little likelihood of being addressed, especially since the problem is so easily fixed by turning off that feature on the PIX. By: Michael Jerris (mikej) 2005-07-10 12:23:00 Absent of noting a specific protocol violaion, this appears to be a bug in pix fixup. I am suspending this pending additional information. If you are able to show specifics of how what asterisk is sending, or how it is handling somthing being incorrect, please re-open this bug. By: Jared Smith (jsmith) 2007-07-11 06:04:46 Reopening at the request of Stephen Davies on the asterisk-dev mailing list. By: Steve Davies . (stevedavies) 2007-07-11 07:06:03 Hi, This is a bug in the PIX NAT "fixup" for SIP. Apparently the PIX looks through the SIP packet and, amongst other things replaces any occurences of its own external address with the address of the NATTed-to SIP device (aka the Asterisk box). Here's an example REGISTER packet as sent by the original sending system: REGISTER sip:XXX.13.142.72 SIP/2.0 Via: SIP/2.0/UDP YYY.40.106.9:5060;branch=z9hG4bK5d035114;rport From: <sip:cteltest@XXX.13.142.72>;tag=as2ede4718 To: <sip:cteltest@XXX.13.142.72> Call-ID: 64727ea8396c6e026b35348b74eaa9a5@YYY.40.106.9 CSeq: 103 REGISTER User-Agent: Asterisk PBX Max-Forwards: 70 Authorization: Digest username="cteltest", realm="asterisk", algorithm=MD5, uri="sip:XXX.13.142.72", nonce="4cfc78b5", response="26e35cded2994cf578435090754c3b9c", opaque="" Expires: 120 Contact: <sip:s@YYY.40.106.9> Event: registration Content-Length: 0 By the time it has passed through the Pix and got to the server, it looks like this: REGISTER sip:ZZZ.57.10.34 SIP/2.0 Via: SIP/2.0/UDP YYY.40.106.9:5060;branch=z9hG4bK5d035114;rport From: <sip:cteltest@ZZZ.57.10.34>;tag=as2ede4718 To: <sip:cteltest@ZZZ.57.10.34> Call-ID: 64727ea8396c6e026b35348b74eaa9a5@YYY.40.106.9 CSeq: 103 REGISTER User-Agent: Asterisk PBX Max-Forwards: 70 Authorization: Digest username="cteltest", realm="asterisk", algorithm=MD5, uri="sip:ZZZ.57.10.34", nonce="4cfc78b5", response="26e35cded2994cf57843509 0754c3b9c", opaque="" Expires: 120 Contact: <sip:s@YYY.40.106.9> Event: registration Content-Length: 0 The problem is that the PIX also mangled the contents of the uri part of the Authorization header. But you can't do that because the hash in the response is now invalidated. That's why Asterisk rejects the registration with Bad auth. As a workaround you can changing the registering/calling system to use a DNS name to reach the PIX rather than a hard-coded IP address. Then the PIX doesn't mangle it and the authorization will succeed. So - Asterisk 1, Cisco 0: this is their bug not ours. Regards, Steve |