topic SIP signalling traffic being dropped erroneously in General Topics

SIP signalling traffic being dropped erroneously

Mo_Imran — Thu, 03 Jan 2019 17:08:19 GMT

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?

Re: SIP signalling traffic being dropped erroneously

Bob_Bumpus1 — Thu, 03 Jan 2019 18:25:28 GMT

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.

Re: SIP signalling traffic being dropped erroneously

PhoneBoy — Thu, 03 Jan 2019 22:32:22 GMT

Perhaps this SK might be relevant?

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

Re: SIP signalling traffic being dropped erroneously

Hugo_vd_Kooij — Fri, 04 Jan 2019 08:52:43 GMT

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.

Re: SIP signalling traffic being dropped erroneously

Alessandro_Marr — Sat, 05 Jan 2019 18:08:18 GMT

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

could you try disable IPS blade for a test?

Re: SIP signalling traffic being dropped erroneously

Mo_Imran — Tue, 08 Jan 2019 10:53:58 GMT

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.

Re: SIP signalling traffic being dropped erroneously

Mo_Imran — Tue, 08 Jan 2019 11:02:06 GMT

Thanks Hugo. Its static NAT on the object.

Re: SIP signalling traffic being dropped erroneously

Mo_Imran — Tue, 08 Jan 2019 11:03:51 GMT

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,

Re: SIP signalling traffic being dropped erroneously

Mo_Imran — Tue, 22 Jan 2019 16:12:52 GMT

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;

Re: SIP signalling traffic being dropped erroneously

Alessandro_Marr — Tue, 22 Jan 2019 16:34:26 GMT

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?

Re: SIP signalling traffic being dropped erroneously

Mo_Imran — Tue, 22 Jan 2019 17:06:43 GMT

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.

Re: SIP signalling traffic being dropped erroneously

scordy — Wed, 20 Feb 2019 02:38:23 GMT

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?

Re: SIP signalling traffic being dropped erroneously

Hugo_vd_Kooij — Wed, 20 Feb 2019 16:02:46 GMT

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.