Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Serhii_Yaholnyt
Contributor

Pinging nonexistent object

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?

16 Replies
Whatcha_McCallu
Employee
Employee

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.

0 Kudos
Serhii_Yaholnyt
Contributor

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.

0 Kudos
Whatcha_McCallu
Employee
Employee

Sorry about that. I miss read your statement.

What do you see with fw monitor?

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

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Serhii_Yaholnyt
Contributor

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.

0 Kudos
Alejandro_Mont1
Collaborator

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?

0 Kudos
Serhii_Yaholnyt
Contributor

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.

0 Kudos
Vladimir
Champion
Champion

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
Contributor

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?

0 Kudos
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 ?

0 Kudos
Timothy_Hall
Champion
Champion

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
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 ?

0 Kudos
Whatcha_McCallu
Employee
Employee

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.

0 Kudos
Serhii_Yaholnyt
Contributor

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. 

0 Kudos
Serhii_Yaholnyt
Contributor

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

0 Kudos
G_W_Albrecht
Legend
Legend

So what is the final explanation for this ?

CCSE CCTE CCSM SMB Specialist
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events