topic Re: SIP through ASA 5505 in Network Security

SIP through ASA 5505

elliott.barrere — Mon, 11 Mar 2019 17:59:10 GMT

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-

Re: SIP through ASA 5505

Federico Coto Fajardo — Mon, 14 Jun 2010 17:43:48 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Mon, 14 Jun 2010 17:57:23 GMT

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

Re: SIP through ASA 5505

Federico Coto Fajardo — Mon, 14 Jun 2010 18:04:06 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Mon, 14 Jun 2010 19:01:21 GMT

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?

Re: SIP through ASA 5505

Federico Coto Fajardo — Mon, 14 Jun 2010 19:10:38 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Mon, 14 Jun 2010 19:39:56 GMT

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!

Re: SIP through ASA 5505

Federico Coto Fajardo — Mon, 14 Jun 2010 20:24:29 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Mon, 14 Jun 2010 21:44:43 GMT

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.

Re: SIP through ASA 5505

Federico Coto Fajardo — Tue, 15 Jun 2010 03:28:34 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Tue, 15 Jun 2010 04:16:11 GMT

coto.fusionet wrote:

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.

Re: SIP through ASA 5505

Federico Coto Fajardo — Tue, 15 Jun 2010 15:14:28 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Tue, 15 Jun 2010 22:50:24 GMT

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?

Re: SIP through ASA 5505

elliott.barrere — Thu, 17 Jun 2010 22:57:31 GMT

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

Re: SIP through ASA 5505

Panos Kampanakis — Fri, 18 Jun 2010 20:30:01 GMT

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.

Re: SIP through ASA 5505

elliott.barrere — Fri, 18 Jun 2010 20:46:50 GMT

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".

Re: SIP through ASA 5505

Panos Kampanakis — Fri, 18 Jun 2010 21:26:03 GMT

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?

Re: SIP through ASA 5505

elliott.barrere — Fri, 18 Jun 2010 21:53:51 GMT

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

Re: SIP through ASA 5505

Panos Kampanakis — Fri, 18 Jun 2010 22:19:15 GMT

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"

Re: SIP through ASA 5505

elliott.barrere — Sat, 19 Jun 2010 00:19:49 GMT

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!