SIP through ASA 5505

Unanswered Question
Jun 14th, 2010
User Badges:

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-

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Federico Coto F... Mon, 06/14/2010 - 10:43
User Badges:
  • Green, 3000 points or more

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 Mon, 06/14/2010 - 10:57
User Badges:

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

elliott.barrere Mon, 06/14/2010 - 12:01
User Badges:

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 F... Mon, 06/14/2010 - 12:10
User Badges:
  • Green, 3000 points or more

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 Mon, 06/14/2010 - 12:39
User Badges:

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 F... Mon, 06/14/2010 - 13:24
User Badges:
  • Green, 3000 points or more

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 Mon, 06/14/2010 - 14:44
User Badges:

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.

Attachment: 
Federico Coto F... Mon, 06/14/2010 - 20:28
User Badges:
  • Green, 3000 points or more

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 Mon, 06/14/2010 - 21:16
User Badges:

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 F... Tue, 06/15/2010 - 08:14
User Badges:
  • Green, 3000 points or more

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 Tue, 06/15/2010 - 15:50
User Badges:

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 Thu, 06/17/2010 - 15:57
User Badges:

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

Panos Kampanakis Fri, 06/18/2010 - 13:30
User Badges:
  • Cisco Employee,

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

elliott.barrere Fri, 06/18/2010 - 13:46
User Badges:

Hi PK,


Thanks for the advice, unfortunately I have tried "debug sip" and I see nothing on the console!  Is there anything that could be preventing me from seeing the logs?  I have set "logging console debug".

Panos Kampanakis Fri, 06/18/2010 - 14:26
User Badges:
  • Cisco Employee,

Him, if sip inspection is not kicking in then the pinholes will not be opened.

You have sip inspection enabled haven't you?

Does "show service-policy" show counters for sip?


PK

elliott.barrere Fri, 06/18/2010 - 14:53
User Badges:

I have tried to enable it by configuring it in my class-map.  I now see counters for SIP in "show service-policy" but they are empty, even after I make a call.  Still seeing the RTP ports blocked too (I have tried "debug sip" and "debug rtp" and I see nothing on the console when making calls)


# sh service-policy

Interface inside:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: sip , packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0

Interface outside:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: sip , packet 0, drop 0, reset-drop 0
               tcp-proxy: bytes in buffer 0, bytes dropped 0

Panos Kampanakis Fri, 06/18/2010 - 15:19
User Badges:
  • Cisco Employee,

Yeah, the inspection is not kicking in.

Can you "clear local " for the ip that has the issue? And try to pass sip again t see counters increment?

Make sure you have tcp port 5060 in your sip packets and they are hitting the ASA.

Also give us the "sh run policy-map" and "sh run class-map"


PK

elliott.barrere Fri, 06/18/2010 - 17:19
User Badges:

Okay, now we're getting somewhere!


I first tried running "clear local " and that didn't work (didn't seem to be doing anything) but a "clear local" with no args cleared out the whole state table and now the SIP counters are updating and I see channel information with "show sip".  I will have to wait until I'm in the office on Monday to see if the audio path is actually coming up now, but I have hope at this point


Thanks for your help so far!

Panos Kampanakis Sun, 06/20/2010 - 09:29
User Badges:
  • Cisco Employee,

I believe sip inspection will open the pinholes for the voice streams now.


Good luck,

PK

Actions

This Discussion