SIP signalling traffic being dropped erroneously

[Mo_Imran]

Hi,

We recently noticed SIP signalling traffic (5060/udp) being dropped following a working configuration and appears to be happening to just one of two SIP gateways IP addresses , which have the same configuration. 

Background/Setup information:

The SIP gateways are on a private network however (static) NAT'ed for access to the external SIP endpoints. bi-directional access on ports: a) 5060/udp using sip_any service and the sip_media ports. 

The config has worked OK for quite a while and up until a few days ago when we migrated to R80.10. (T_154)

The issue:

Packets are not being dropped by IPS or hitting any of our rulebase but we can see that they are being subtly dropped by “fw_conn_post_inspect”

Has anyone else seen this issue? Any idea/suggestions on a workaround or how to bypass this?

[Bob_Bumpus1]

I haven't run into this on R80.10, but on other versions I've encountered similar weirdness with SIP.  I ended up using a generic UDP port service and not one with SIP inspections.  It's not an ideal solution, but you might want to try it and see if it helps.

[Mo_Imran]

Thanks Bob. This is on my list to try but we are currently struggling with our SIP providers to allow the endpoint failing to work in isolation as introducing it breaks phones for all our users. That is the first thing i am planning to try and see if it fixes it.

[scordy]

Thanks for the recommendation there Bob (B). We have had no issue with SIP traffic up until the recent application of Take342 for R77.30. Issue now noted seems similar to what is being reported here. I haven't delved deeper with zdebug to determine exactly which component of the SIP interaction is now being impeded, but a quick fix seems to be to drop in a UDP service, sans higher-layer SIP inspections. 'Coincidental' timing with the R80.10 issue?

[PhoneBoy]

Perhaps this SK might be relevant?

Log shows that a connection was rejected by the explicit Application Layer "Accept" rule for this co... 

[Hugo_vd_Kooij]

It seems like a different issue. That is about non-SIP traffic being rejected by the SIP handler.

The original question is about SIP traffic being dropped.

Do you use static NAT on the object or with manual rules? If you use manual rules make sure to change it to static NAT on the objects.

[Mo_Imran]

Thanks Hugo. Its static NAT on the object.

[Alessandro_Marr]

Mo Imran, do you have a same issue using another take <> 154 ?

could you try  disable IPS blade for a test? 

[Mo_Imran]

Hi Alessandro, we have excluded the all objects pertaining to SIP already, and has been the case since this configuration went into production although we are/weren't seeing any IPS drops. We are running Take_154.

Regards,

[Mo_Imran]

So, a quick summary of what the issue was in this instance. The erroneous drops were due to a the NAT not being applied correctly to the SIP payload by the firewall which in turn tripped the internal inspection (by the SIP handlers) and dropped the signalling traffic, when using the built in (sip or sip_any) service ports. This obviously didn't help when using a generic 5060/udp as well. This meant we had to ditch the firewall doing NAT (outbound) for the SIP proxy and moved it with an interface on the DMZ.

I understand this is a known issue but on R77.30 so i think it will be accepted as a bug and patch for R80.10

So in summary if you are seeing the drop message in zdebug as below and are using static NAT for your SIP proxy's with gateways R80.10 then you are probably hitting this bug too.

Drop error message:

[cpu_35];[fw4_0];fw_log_drop_ex: Packet proto=17 <internal IP>:5060 -> <SIP_endpoint_external_IP>:5060 dropped by fw_conn_post_inspect Reason: Handler 'sip_manager_any' drop;

[Alessandro_Marr]

executing a fw ctl zdebug drop | grep <ip address of sip equipment> you can see whatever drop?

did you try to create a exception rule on Threat Prevention?

did you try to create a exception rule on inspection settings?

Executing a fw monitor you can see that traffic is normal?

[Mo_Imran]

Yes; Yes and Yes. Zdebug is what identified the aspect triggering the drops as it wasnt being logged however the root cause needed some diag (quite a few packet captures/fwmonitors) as it wasn't straightforward or wasn't obvious at first.

[Hugo_vd_Kooij]

Not sure if Static NAT is a wise thing with SIP traffic.

It may fail in some cases if you use SIP handlers and not straight UDP ports in your policy.