SIP through ASA 5505

[elliott.barrere]

Hi all,

I'm trying to allow SIP calls through a 5505 running version 8.2(2).  I've passed port 5060 through the firewall but now I'm seeing the RTP traffic blocked.  I read this page and added this to my config:

class-map inspection_default

match default-inspection-traffic

policy-map global_policy

class inspection_default

inspect sip

service-policy global_policy global

but it's not working.  No idea what else to do!  Any pointers or advice??

Thanks for any help in advance!

Cheers,

-elliott-

[Federico Coto Fajardo]

Elliot,

Are you using PAT?

The RTP is being blocked on the outside interface?

As a test, what happen if you permit IP on the outside ACL just to make sure that RTP works fine....

Federico.

[elliott.barrere]

Hi Federico, thanks for your reply.

Yes, PAT is being used on the client side (the phone is currently behind a BSD firewall in my control, but it will be shipped elsewhere so we need to assume PAT will be used).  There is a static NAT entry on the server side (the server is behind the ASA).

I see the packets getting dropped at the ASA:

Jun 14 2010 10:21:11: %ASA-4-106023: Deny udp src outside:XXX.XXX.XXX.XXX/53191 dst inside:pbx-outside/14228 by access-group "outside_access_in" [0x0, 0x0]

and by adding this ACE I can make it work:

access-list outside_access_in permit ip 255.255.255.255 pbx-outside 255.255.255.255

[Federico Coto Fajardo]

Elliot,

If by permitting the traffic in the ACL it works, clearly the inspection is not working.

Please check if you need to add additional inspection to SIP:

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/inspect_voicevideo.html#wp1204403

Federico.

[elliott.barrere]

Hi Federico,

I have all the defaults set; do I have to be more specific about what traffic to match?  I want the ASA to inspect all SIP traffic by default.  I have this in my config:

# sh run class-map
!
class-map inspection_default
 match default-inspection-traffic
!
# sh run policy-map
!
policy-map global_policy
 class inspection_default
!
# sh run service-policy
service-policy global_policy global

The default-inspection-traffic line should match all SIP traffic on port 5060 right?

[Federico Coto Fajardo]

Yes,

SIP inspection should inspect the signaling over 5060.

Do you have any of the following scenarios?

The following limitations and restrictions apply when using PAT with SIP:

•If a remote endpoint tries to register with a SIP proxy on a network protected by the adaptive security appliance, the registration fails under very specific conditions, as follows:

–PAT is configured for the remote endpoint.

–The SIP registrar server is on the outside network.

–The port is missing in the contact field in the REGISTER message sent by the endpoint to the proxy server.

•If a SIP device transmits a packet in which the SDP portion has an IP address in the owner/creator field (o=) that is different than the IP address in the connection field (c=), the IP address in the o= field may not be properly translated. This is due to a limitation in the SIP protocol, which does not provide a port value in the o= field.

Federico.

[elliott.barrere]

Yes, I saw that in one of the articles I read but I was not sure what to make of it.  Assuming the "remote endpoint" means the SIP phone, then I don't believe I fall into that category:

* Yes, PAT is enabled on the firewall device that the phone is behind

* Yes, the SIP registrar server is on the external network, in relation to the SIP device

* No, I have verified that the port value is NOT missing in the REGISTER message received by the SIP registrar (Asterisk)

Additionally, it is not registration that fails, it is the audio path.  The device can register to the server and make and receive calls, but audio is only one-way (it is not received by the other party).  I am sure this is due to the RTP stream being blocked by the firewall since a simple ACE can fix the problem.  Is there anything else we can try to make the SIP inspection work as it should?

Thanks!

[Federico Coto Fajardo]

Elliot,

It will really help if you can do two things:

1. Post a capture of the connection between the SIP endpoints (capture command)

2. Post a simple diagram just to ilustrate the scenario.

Federico.

[elliott.barrere]

Okay, here is a capture from the device (XXX is client IP, YYY is server):

1: 13:16:57.128396 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 1203
2: 13:16:57.129799 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 541
3: 13:16:57.270020 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 401
4: 13:16:57.292297 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 1388
5: 13:16:57.294235 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 460
6: 13:16:58.420144 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 476
7: 13:16:58.425240 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 460
8: 13:16:59.289184 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 730
9: 13:16:59.290130 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 427
10: 13:16:59.290298 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 524
11: 13:16:59.437126 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 893
12: 13:16:59.438408 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 427
13: 13:16:59.448981 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 546
14: 13:16:59.449271 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 552
15: 13:16:59.567643 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 613
16: 13:17:02.333204 802.1Q vlan#2 P0 YYY.YYY.YYY.YYY.5060 > XXX.XXX.XXX.XXX.60534: udp 744
17: 13:17:02.439079 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.60534 > YYY.YYY.YYY.YYY.5060: udp 382
18: 13:17:02.472204 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.57779 > YYY.YYY.YYY.YYY.12741: udp 68
19: 13:17:02.472341 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 28
20: 13:17:02.623548 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
21: 13:17:02.623655 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
22: 13:17:02.625883 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
23: 13:17:02.635907 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
24: 13:17:02.651058 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
25: 13:17:02.676753 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
26: 13:17:02.693415 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
27: 13:17:02.720925 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
28: 13:17:02.745902 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
29: 13:17:02.760901 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
30: 13:17:02.778875 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
31: 13:17:02.793400 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
32: 13:17:02.815860 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
33: 13:17:02.835909 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
34: 13:17:02.855821 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
35: 13:17:02.873551 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
36: 13:17:02.898391 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
37: 13:17:02.913542 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
38: 13:17:02.943356 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172
39: 13:17:02.955867 802.1Q vlan#2 P0 XXX.XXX.XXX.XXX.53658 > YYY.YYY.YYY.YYY.12740: udp 172

The last packets continue on indefinitely until the call is hung up.

The scenario is very simple:  the phone goes out through PAT to the internet, to the public IP of the server, which is NAT'd by the ASA to the server inside.  I've attached a PNG I made quickly with Gliffy as well.

[Federico Coto Fajardo]

If you add this statement to the ASA:
access-list outside_access_in permit ip 255.255.255.255 pbx-outside 255.255.255.255
Then it works.
Without the ACL you get this error:
%ASA-4-106023: Deny udp src outside:XXX.XXX.XXX.XXX/53191 dst inside:pbx-outside/14228 by access-group "outside_access_in" [0x0, 0x0]

Is the SIP call from the client behind the BSD firewall to a device behind the ASA?
This other party can hear you?

Federico.

[elliott.barrere]

coto.fusionet wrote:
If you add this statement to the ASA: 
access-list outside_access_in permit ip  255.255.255.255 pbx-outside 255.255.255.255
Then it works. 
Without the ACL you get this error: 
%ASA-4-106023: Deny udp src outside:XXX.XXX.XXX.XXX/53191 dst inside:pbx-outside/14228 by access-group "outside_access_in" [0x0, 0x0]
Is the SIP call from the client behind the BSD firewall to a device behind the ASA?

No, I have tried several other devices (IAX trunk to another Asterisk box, out through the PSTN, etc), none of which are behind the ASA.

This other party can hear you?

Just the opposite, actually; the audio goes only from the outside party to the SIP device.

[Federico Coto Fajardo]

I am also sure the problem is the RTP stream being blocked by the ASA due to the fact that an ACE fixes the problem.

But my question is, since the audio path is failing, the RTP stream should not flow through the ASA, since the SIP endpoint is behind the BDS Firewall and the called-party is somewhere else, or I'm missing something?

Federico.

[elliott.barrere]

The server behind the ASA is a SIP gateway; it places calls to devices on other media like IAX and TDM so the firewall has no impact on them.

I can place a call to a conference room located on the server itself and the audio path is still broken.  It is definitely the RTP path between the SIP device and the server.

Any ideas?  Anyone?

[elliott.barrere]

Sorry for the bump, but I'm really at a loss here.  Anyone have any ideas?

[Panos Kampanakis]

I am not sure what break it.

8.2. does not have serious SIP bugs, so I am not sure.

If SIP signaling and RTP pass through the firewall I would try to enable "debug sip" and see the signaling and the pinholes the ASA is opening and see if there is something that is not working properly.

I hope it helps a little.

PK