ASA5505 issues with SIP trunk.

Unanswered Question
Mar 31st, 2010

Hi All,

I have problem with our ASA which is driving me crazy. ITSP is sending calls using SIP to our Public address. The ASA is configured to port forward the traffic to internal voice gateway/CCM , however the ASA seem to discard the packets even thought I have permitted them in the inbound ACL’s.

SIP configuration from my ASA as below.

===========================================================

object-group network ITSP

network-object 135.216.160.11 255.255.255.255

network-object 135.216.160.7 255.255.255.255

network-object 135.216.160.12 255.255.255.255

network-object 135.216.160.13 255.255.255.255

network-object 135.216.160.14 255.255.255.255

access-list Inbound_traffic extended permit udp object-group ITSP host 203.161.121.130 eq sip log

static (inside,outside) udp 203.161.121.125 sip 192.168.12.251 sip netmask 255.255.255.255

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect ils

  inspect rsh

  inspect rtsp

  inspect sip 

  inspect skinny 

  inspect tftp

  inspect http

  inspect pptp

class class_http

  inspect http

class SMTP

  priority

class http-mss

  set connection advanced-options mss-map

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

==============================================================

When I make call to the number directed to my public IP address from the ITSP I get the following message.

------------------------------------------------------------------------------------------------

Mar 31 04:59:15 ASA5505 %ASA-6-607001: Pre-allocate SIP Via UDP secondary channel for outside:135.216.160.7/5060 to inside:192.168.12.251 from INVITE message
Mar 31 04:59:15 ASA5505 %ASA-6-607001: Pre-allocate SIP SIGNALLING UDP secondary channel for outside:135.216.160.7/5060 to inside:192.168.12.251 from 404 message
Mar 31 04:59:15 ASA5505 %ASA-6-607001: Pre-allocate SIP Via UDP secondary channel for outside:135.216.160.7/5060 to inside:192.168.12.251 from ACK message
Mar 31 04:59:50 ASA5505 %ASA-6-607001: Pre-allocate SIP Via UDP secondary channel for inside:135.216.160.7/5060 to outside:192.168.12.251 from INVITE message
Mar 31 04:59:54 ASA5505 %ASA-6-607001: Pre-allocate SIP SIGNALLING UDP secondary channel for outside:135.216.160.7/5060 to inside:192.168.12.251 from 200 message


Mar 31 05:03:19 ASA5505 %ASA-7-710005: UDP request discarded from 135.216.160.7/5060 to outside:203.161.121.125/5060
Mar 31 05:03:45 ASA5505 %ASA-7-710005: UDP request discarded from 135.216.160.7/5060 to outside:203.161.121.125/5060
Mar 31 05:03:46 ASA5505 %ASA-7-710005: UDP request discarded from 135.216.160.7/5060 to outside:203.161.121.125/5060

------------------------------------------------------------------------------------------------

Any help will be much appreciated

Thanks

Mohammed

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Federico Coto F... Wed, 03/31/2010 - 11:10

Hi,

You have a STATIC NAT statement redirecting SIP to IP 203.161.121.130

You also have an ACL allowing the traffic.

But the logs show the SIP (UDP 5060) attempting a connection to IP 203.161.121.125

These are the connections that are being denied, because there's no STATIC NAT for .125

Federico.

mnour401917_2 Wed, 03/31/2010 - 18:20

Hi Federico,

Thanks for the response. I have checked again and the NAT statement i included was the the wrong one. i have i have included the right statement now. tested again and still get same result.

when i do a packet tracer check against the applied policy, i see the Implicit rule denying the packet. Any idea?

Thanks

Mohammed

Federico Coto F... Wed, 03/31/2010 - 18:37

So, now you have an entry in the ACL inbound_traffic permiting UDP port 5060 to 203.161.121.125 correct?
Is this entry above any other deny rule that might be blocking this traffic?

The reason I ask is because you mentioned that the Packet Tracer shows the implicit deny any any rule in the ACL denying the packet correct?
According to the Packet Tracer is the ACL inbound_traffic the one blocking the connection?
If so could you attach the output of the ''show run access-list inbound_traffic''?

Federico.

Actions

This Discussion