SIP dropped by fw_post_vm_chain_handler Reason: Handler 'sip_manager' drop

[RemoteUser]

Hi,
I'm struggling with this error: dropped by fw_post_vm_chain_handler. Reason: Handler 'sip_manager' drop; on the gateway.

The rule that allows traffic exists. Also, in the inspection information in the log, I see: illegal IP address, possible spoofing.

I've opened a case with support, but their response is slow...

Thank you

[Tal_Paz-Fridman]

This might help:

https://community.checkpoint.com/t5/Security-Gateways/Too-many-pending-data-connections-for-one-cont...

And https://support.checkpoint.com/results/sk/sk33760 

[RemoteUser]

Hello, thank you for your reply only I don't understand in what way you can think that this log I reported to you can be related to the sk you shared? in the logs I see from smartconsole it says illegal ip address, how can it be related to number of pending data connections?
Thank you very much for your answer, just to understand better.

[Tal_Paz-Fridman]

I saw it was recommended to a customer that had a similar issue. 

To be sure ask about this option as well.

[the_rock]

Hey mate,

I would also follow below.

Andy

https://support.checkpoint.com/results/sk/sk95369

[RemoteUser]

Hi Andy, I took a look, carefully here, to see if the error was reported in the log message:
Because it is a very strange log error (we have sip running over udp).

(14-2) SIP

Log Message	Possible Cause	Suggested solution	IPS protection
NOTIFY message out of state	This message can appear for numerous messages, not only for NOTIFY. It usually indicates a problem in the SIP state machine.	Contact Check Point Support after you collect the relevant SIP debug.
Violated unidirectional connection	Trying to use bi-directional SIP connections.	In the rulebase, add the 'sip_dynamic_ports' service (located in the 'Other' group) to the corresponding SIP rule.
Connection contains real IP of NATed address	A real IP address appeared instead of the NATed IP address.	Contact Check Point Support after you collect the relevant SIP debug.
Malformed SIP datagram, invalid SIP headers	Security Gateway expected a certain field in the SIP packet, but the field is missing.	Contact Check Point Support after you collect the relevant SIP debug.
Enforcing major security - reinvents rejected	The destination tries to reinvent a call.	Disable the "Block the destination from re-inviting calls" setting in the relevant IPS profile. Note: This setting prevents the destination from opening additional data connections with IP addresses that are not the same as the first data connection while a call is still active.	Follow these steps: Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.). Connect to Security Management Server with GuiDBedit Tool. In the left upper pane, go to 'Table' - 'Managed Objects' - 'asm'. In the right upper pane, select the relevant IPS profile (Class Name = advanced_security). Press CTRL+F (or go to 'Search' menu - 'Find') - paste sip_enforce_security_reinvite - click on 'Find Next'. In the lower pane, right-click on the sip_enforce_security_reinvite - 'Edit...' - choose "false" - click on 'OK'. Save the changes: go to 'File' menu - click on 'Save All'. Close the GuiDBedit Tool. Connect to Security Management Server with SmartDashboard. Install the policy onto the relevant Security Gateway / Cluster object.
Reinvents exceeds the limit	The number of maximum allowed invitations per call has been exceeded.	Increase the value of "Maximum invitations per call (from both directions)" in the IPS "SIP Protections" protection.	'IPS' tab - Protections - By Protocol - Application Intelligence - VoIP - SIP - SIP Protections - select the relevant IPS Profile

[the_rock]

You see the log in smart console being accepted?

Andy

[RemoteUser]

Traffic is dropped, BUT we see that traffic accepted to an IP of the same subnet in the rule created... is blocked from the source (illegal IP address), but the rule exists...

[the_rock]

Try change service to use protocol none, or -

[RemoteUser]

the rule accpet this at the moment :

sip
icmp-proto
udp-5060-5080

[the_rock]

Try sip like what I attached

Andy

[RemoteUser]

I tried to put only udp-5060 in the rule but the issue is because the trunk is not working because there are drops—drops from logs that identify certain IP addresses as illegal. 

[PhoneBoy]

Possible this SK might help: https://support.checkpoint.com/results/sk/sk120372 

[RemoteUser]

Remove the SIP service object(s) from the involved Application Layer "Accept" rule and install the policy.
We have not sip service object in application layer...

[the_rock]

Technically, you would not even need it in that layer, since most people would apply blacklist approach, meaning any any allow at the end.

Andy