No incoming call with SR520

Unanswered Question
Jul 13th, 2009
User Badges:

Hello,


I have a combination of a UC520 with in front a SR520.


The problem i can't resolve has to do with the ZPF configuration.

With the default configuration (generated by CCA 2.0), i can't call from external phones.

The SR520 drops the SIP packets. To be more specific: the debugging info tells me =>


FW-6-DROP_PKT: Dropping udp session 85.119.188.3:5060 192.168.75.2:50137 on zone-pair sdm-zp-out-in class class-default due to  DROP action found in policy-map with ip ident 0


85.119.188.3 is the ip address of the external ISP proxy server, 192.168.75.2 is the ip address of the UC520



the configuration of ZPF is:


class-map type inspect match-any SDM-Voice-permit
match protocol h323
match protocol skinny
match protocol sip

class-map type inspect match-any sdm-cls-icmp-access
match protocol icmp
match protocol tcp
match protocol udp
class-map type inspect match-any sdm-cls-insp-traffic
match protocol cuseeme
match protocol dns
match protocol ftp
match protocol h323
match protocol https
match protocol icmp
match protocol imap
match protocol pop3
match protocol netshow
match protocol shell
match protocol realmedia
match protocol rtsp
match protocol smtp extended
match protocol sql-net
match protocol streamworks
match protocol tftp
match protocol vdolive
match protocol tcp
match protocol udp
class-map type inspect match-all sdm-nat-h323-1
match access-group 103
match protocol h323
class-map type inspect match-all SDM-inspect-staticnat-in
match access-group name staticnat
class-map type inspect match-all sdm-invalid-src
match access-group 100
class-map type inspect match-all dhcp_out_self
match access-group name dhcp-resp-permit
class-map type inspect match-all dhcp_self_out
match access-group name dhcp-req-permit
class-map type inspect match-all sdm-nat-sip-2
match access-group 102
match protocol sip
class-map type inspect match-all sdm-protocol-http
match protocol http
class-map type inspect match-all sdm-nat-sip-1
match access-group 101
match protocol sip
!
!
policy-map type inspect sdm-permit-icmpreply
class type inspect dhcp_self_out
  pass
class type inspect sdm-cls-icmp-access
  inspect
class class-default
  pass
policy-map type inspect sdm-inspect
class type inspect sdm-cls-insp-traffic
  inspect
class type inspect SDM-Voice-permit
  pass
class type inspect sdm-invalid-src
  drop log
class type inspect sdm-protocol-http
  inspect z1-z2-pmap
class class-default
  pass
policy-map type inspect sdm-inspect-voip-in
class type inspect SDM-inspect-staticnat-in
  pass
class type inspect SDM-Voice-permit
  pass
class type inspect sdm-nat-sip-1
  pass
class type inspect sdm-nat-sip-2
  pass
class type inspect sdm-nat-h323-1
  pass
class class-default
  drop

policy-map type inspect sdm-permit
class type inspect dhcp_out_self
  pass
class class-default
  drop
!
zone security out-zone
zone security in-zone
zone-pair security sdm-zp-self-out source self destination out-zone
service-policy type inspect sdm-permit-icmpreply
zone-pair security sdm-zp-out-in source out-zone destination in-zone
service-policy type inspect sdm-inspect-voip-in
zone-pair security sdm-zp-out-self source out-zone destination self
service-policy type inspect sdm-permit
zone-pair security sdm-zp-in-out source in-zone destination out-zone
service-policy type inspect sdm-inspect
!




When i look to show policy-map type inspect zone-pair sdm-zp-out-in  it looks like the firewall doesn't recognize the traffic as being SIP:


policy exists on zp sdm-zp-out-in
Zone-pair: sdm-zp-out-in


  Service-policy inspect : sdm-inspect-voip-in


    Class-map: SDM-inspect-staticnat-in (match-all)
      Match: access-group name staticnat
      Pass
        0 packets, 0 bytes


    Class-map: SDM-Voice-permit (match-any)
      Match: protocol h323
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: protocol skinny
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: protocol sip
        0 packets, 0 bytes
        30 second rate 0 bps
      Pass
        0 packets, 0 bytes


    Class-map: sdm-nat-sip-1 (match-all)
      Match: access-group 101
      Match: protocol sip
      Pass
        0 packets, 0 bytes


    Class-map: sdm-nat-sip-2 (match-all)
      Match: access-group 102
      Match: protocol sip
      Pass
        0 packets, 0 bytes


    Class-map: sdm-nat-h323-1 (match-all)
      Match: access-group 103
      Match: protocol h323
      Pass
        0 packets, 0 bytes


    Class-map: class-default (match-any)
      Match: any
      Drop
        7 packets
, 6965 bytes


when i change the behavior of class class-default from drop to pass, it works.... but i don't think this is very secure...


My UC520 registers itself to the SIP proxy of the provider with a source port 59078. Could that be the reason?

So the invites of the external call are directed to that port...

I tried connection-reuse under sip-ua, but it is not available in 12.4(20)T2

But again, when i change the drop to pass, it works...


Can somebody help me with this?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Marcos Hernandez Thu, 07/16/2009 - 06:06
User Badges:
  • Blue, 1500 points or more

This should work. Your configuration looks OK and you should not change this to "drop", since the SIP registration should open the pinhole through the SR520.


Sorry for the inconvenience, but could you please open a TAC case on this?


Thanks,


Marcos

sknockae Thu, 07/16/2009 - 14:37
User Badges:

Well, after a while i managed to use the "connection-reuse" command for sip-ua.

Don't know what i did wrong...

Now it works like it should without changing the FW.

So for me (and the customer) the problem is solved.


But i was still wondering why it must have 5060 as a source port. (the reason why i used connection reuse)

Without the SR520, i don't need to configure the connection-reuse and it works in both directions.

So it's not a requirement of the ISP.


Thanks

Marcos Hernandez Thu, 07/16/2009 - 20:08
User Badges:
  • Blue, 1500 points or more

I am going to look into this and get back to you. Thanks,


Marcos

Maulik Shah Thu, 07/16/2009 - 21:53
User Badges:
  • Silver, 250 points or more

Do you have a static NAT entry on port 5060 on the SR520? If not then that maybe why the connection-reuse is required.

mbram1313 Fri, 07/17/2009 - 21:46
User Badges:

Hello Everyone,

I am having the same issue with the "connections section" within the SIP packet. My private address on the FA 0/0 port on the UC520, 10.201.14.34, is being sent inside to my SIP carrier. They are stripping Layer 3 header info when forwarding the request for audio. The RTP servers are seeing only the private address inside the packet, which when forwarded back to me, it is being dropped. I think that the (conf-serv-sip)#bind all source-interface interface, command will work, but I am stuck on how to bind my public address to an interface without bringing the registration with the SIP registrar server down.


TAC wasn't able to give me an answer so I have been trying multiple configs to bring the audio up. Another possibility that I wanted to explore was using the piggyback command under NAT on the SR520. I cannot get this to come up either though. I would greatly appreciate any help as well.


Thanks for letting me in on the thread.

Regards...Matt

Actions

This Discussion

Related Content