Pinging nonexistent object

[Serhii_Yaholnyt]

In Smartdashboard I have created an object with IP address 10.110.10.110 which does not exist in my network. After that I have created a rule for it, where traffic from any source over any service to this object is accepted. After that i have installed policy. Then I have tried to ping 10.110.10.110 from Windows desktop, for which my Checkpoint is default Gateway. Windows desktop is not at network 10.110.10.110 and is connected to internal interface. And my ping was successfull. I have run tcpdump on every checkpoint interface. Echo request and echo reply packets I could see only on the internal interface (to which windows desktop is connected). I have one rule in my firewall policy that accepts all traffic. I use Gaia R77.30. What can cause such behavior? Is it possible to fix it? Or i have missed something?

[Whatcha_McCallu]

I don't have the explanation why, but the ICMP protocol is not included in the built-in Any service object.

Any is really Most. There are a few more services. You should read 

sk39623

To resolve you can create a rule to allow the ICMP protocol. Or change the Implied Rules behavior for ICMP.

The other possibility is NAT. Maybe you should hide NAT your desktop's network behind the gateway? Either Hide NAT option in the object or edit the gateway object go to Nat and select to Hide all internal networks.

[Serhii_Yaholnyt]

I think this advise would be useful if I could not ping existing object. But there is no host with IP 10.110.10.110 in my network. It is just object created in smartdashboard and checkpoint replies to my icmp request for IP 10.110.10.110.

[Whatcha_McCallu]

Sorry about that. I miss read your statement.

What do you see with fw monitor?

fw monitor -e "host(10.110.10.110),accept;"

[PhoneBoy]

Did you validate that the traffic only traversed the internal interface and not the external interface?

Entirely possible something upstream from the firewall is responding.

[Serhii_Yaholnyt]

Yes, i have run ssh to gateway and tcpdump on all interfaces simultaniously and ICMP requests and replies were only on internal interface which is connected to my windows desktop. Also i forget to say that it is HA cluster.

[Alejandro_Mont1]

You have created a host node object with this IP and not a network object with a 32 bit mask, correct? If you delete the object and push policy are the pings successful? Do you have NAT configured for the object?

[Serhii_Yaholnyt]

Yes, i have created a host node object. And if i delete object from Dashboard and install policy, ping does not respond.I have tried this with hide NAT on in general properties of my gateway and without it, the result is the same.

[Vladimir]

While I was not able to replicate it in my environment (R80.10 Single gateway), what you are describing looks like Automatic ARP function:

[Serhii_Yaholnyt]

It really looks like strange work of automatic ARP configuration. But I do not understand why does my gateway decide to send echo reply to this echo request. This ARP configuration's purpose is to make gateway able to recieve and resend packets for NATed object but why gateway make reply on behalf of this object when it is unreachable?

[HristoGrigorov]

ARP (proxy arp to be exact) is just that, associating IP address with MAC address. Nothing more. When NAT is in use, your gateway "binds" to this IP like it is local one. And I think replying to ICMP packets is implied rule configurable in Global properties ?

[Timothy_Hall]

The firewall performing a proxy ARP for a NAT address should not make the firewall start answering echo requests for that NAT address.  They key is determining where the "mystery" ICMP reply is coming from, there are two possibilities:

1) Another system on the network - this doesn't sound likely since a tcpdump run on the firewall itself showed the echo reply.  This would seem to indicate that the firewall sent/forwarded it in some capacity, but could also indicate that another system sent it and the local switch just flooded it to all switch ports.  Please run your tcpdump again, this time with -ep to show MAC addresses and avoid the possible "observer effect" caused by promiscuous mode, respectively.  Check the source MAC on the echo reply, if it belongs to the firewall's interface the firewall itself generated it or forwarded the reply from another interface.  Also possible you have more than one IP subnet in use on the 10.110.10 VLAN which can cause some strange effects but that is unlikely.

2) Gaia/Linux or Check Point's code generated it - Whatcha McCallum‌ had a good suggestion earlier to run a fw monitor which will help you determine what sent the echo reply.  Run this command and post the output of a ping test with the NAT added:

fw monitor -e 'accept [9:1]=1;'

How many inspection points (iIoO) does the echo reply pass through?  2?  4?  You could also start a continuous ping then watch the "ICMP messages sent" counter in the output of netstat -s, if it increments in time with the replies the Gaia IP driver is sending them.

One more thing:

Does cphaprob -a if show all interfaces as "up" or are you seeing "partially up" anywhere?  Wondering if the Interface Active Check pnote thinks there is a problem with the network and is sending ping scans into the VLAN and your ping program is somehow interpreting this scan as a reply when it happens to hit the correct address.  Also I assume that cphaprob stat shows a healthy cluster?

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[HristoGrigorov]

Assume you have NAT to two separate hosts behind same IP (that differ by service only). In case one of these hosts goes down and other is still up what is the gateway supposed to do - answer to ICMP or not ?

[Whatcha_McCallu]

In your NAT does the rule specify ICMP?

If not, then continues to flow through the remaining Nat rules.

Cluster and icmp

The cluster will send out icmp requests probing the network to help identify if the gateway is up or not. This will cause the gateway to send our icmp packets to the hosts identified in it's around table.

I remember this as a fallback when the cluster ccp udp8116 (multicast or broadcast) is interrupted.

#cphaprob list.  Could show something along the lines of inbound up / outbound down. 

This still does not explain why the gateway is seeming to reply to an icmp request.

 I'd like to see the fw monitor. Actually if you call into support. I'm sure they can help get to the bottom of this.

[Serhii_Yaholnyt]

I can not now replicate the issue. I have turned off translate destination on client side, installing policy, testing some features with it, then turned it back but the gateway does not reply to my ICMP request. The problem was found in our customer's environment when we were trying to configure NAT for external object. We wanted internal object make able to have access to a web server in internet via private IP. It worked ok but when the real object was unreachable, gateway replied via different ports (for example 443 and 1720; we used tcping and nmap to determine that). And that requests did not go further from gateway. I have replicated the problem in my lab but now its gone and I am trying to replicate it again. 

[Serhii_Yaholnyt]

By the way, I replicated the problem even without NAT configuring and I have the only firewall rule "any any accept".

[G_W_Albrecht]

So what is the final explanation for this ?