[Home]

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:59Date Closed:2011-06-07 14:09:59
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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