Drops between the Security Gateway and the Management Server

[Hllrdm]

We have a large number of drops between security cluster members (regardless of gateway activity) and the management server on various UDP ports.

The following services have been added to the allow rule: icmp-request, ssh,FIBMGR.
We observe drops on Clean up rules.

We tried entering the #fw ctl command set int fwha_forw_packet_to_not_active 1, but no result.

We observe that the Security Gateways access on different ports.
Is this expected Check Point behavior or not? Is there any information available on this problem?

[the_rock]

If you have a rule to allow the traffic, no, its not normal There is good command you can run fw up_execute src=x.x.x.x dst=y.y.y.y ipp=0

This would show you whether traffic is indeed permitted. Is it new behavior or it happened before?

[Hllrdm]

hello!

We have icmp-request, ssh,FIBMGR.

We have an allow rule for icmp-request, ssh,FIBMGR. That is, Check Point correctly handles drops because UDP ports are not allowed by a rule. It is not clear to us why the Security Gateways are sending udp packets to the management server.

The problem may have been there before, we just discovered it recently.

[Hllrdm]

Regarding the command, we get the message that no command was found:
Unknown command "src=10.x.x.x."

[the_rock]

So say you want to see that command between IPs 1.1.1.1 and 2.2.2.2, you do this:

fw up_execute src=1.1.1.1 dst=2.2.2.2 ipp=0

IPP is for IP protocol, that can be any

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_CLI_ReferenceGuide/Topics-CLIG/FWG...

Is it possible that traffic is being sent to mgmt server due to implied rule? Can you see it in the logs?

Andy

[Hllrdm]

Hello!

We have icmp-request, ssh,FIBMGR.

We have an allow rule for icmp-request, ssh,FIBMGR. That is, Check Point correctly handles drops because UDP ports are not allowed by a rule. It is not clear to us why the Security Gateways are sending udp packets to the management server.

The problem may have been there before, we just discovered it recently.

Regarding the mistake in the team. The error repeats in expert mode.

[the_rock]

Message me directly, lets do remote later in the afternoon if you are free? Im in EST, what time zone are you in?

[Hllrdm]

GMT+3
Our company policy does not allow remote connection sessions, so we cannot show you the problem.

[the_rock]

Ok, I totally understand. So here is where I would start myself. Look at the logs and see if there are any logs for implied rules regarding this. If not, and regular logs still show you the same, do tcpdump and/or fw monitor

tcpdump -nni any host x.x.x.x

fw monitor -e "accept host(x.x.x.x) and port(x);"

fw monitor -F 'x.x.x.x,0,y.y.y.y,0,0' -F 'y.y.y.y,0,x.x.x.x,0,0'

Captures will ALWAYS tell you where/why the problem happens, 100%.

[Hllrdm]

We have already collected dumps, but unfortunately we have not found any useful information.

1. [expert@:0]# tcpdump -i any src 10.х.х.х. (fw) and dst 10.x.x.x (mgmt)
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes

command output is empty

2. [expert@:0]# fw ctl zdebug + drop | grep 10.x.x.x. (fw)
;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=17 10.x.x.x:18234 -> 10.x.x.x:21771 dropped by fw_handle_first_packet Reason: Rulebase drop - rule 30;

[the_rock]

Something makes no sense there. If you run tcpdump between fw and mgmt server, you have to see some traffic. Can you send exact command you ran?

[RS_Daniel]

Hello @Hllrdm ,

Port 18234/UDP is used by vpn blade for tunnel_test protocol. It seems to me that someone is sending tunnel_test packets to your firewall and the reply packets are being dropped, it should not happen between gateway and management AFAIK, but i think maybe a NAT rule is changing  dest ip address and we are not seeing entire picture. You can check tunnel test packets on your firewall to find who is generating this traffic and if there is some nat involved:

fw monitor -e "port(18234),accept;"

I would disable acceleration before doing the capture, this will give you more information to continue the tshoot. HTH.

Regards