Nexpose and Checkpoint VPN Tunnels

[Terri_Hawkins]

This is a weird question but I am hoping someone can help me with a weird issue.

We have a cluster of 16000 devices running R81.10 and about 100 remote gateways on a mix of 140 and 1530 devices, all with the latest hotfixes (including the main cluster).  We are using IPSec VPN to connect our remote sites to our primary locaton. All the traffic to or from them goes thru the 16000 cluster prior to going anywhere else, on or off network.

The remote locations are small, but on each gateway we have put 4 vlans with some pretty large subnets. Most do not use even close to 10% of the addresses, but because everything is getting more and more on the internet we wanted those addresses available (gates, irrigation systems, cameras, etc).

I use Nexpose scanner to do vulnerability scans on all of our devices each month. The problem I am having is I keep running out of licenses on nexpose because when it scans these remote locations, if there is not a device at an address the checkpoint responds to the request so it gets counted.  If I just did not get a reply to the ping that would not happen (I am working with nexpose on this also).

My question is: is it normal that the checkpoint responds with "destination host unreachable" instead of just timing out? It seems like with a site to site tunnel it should just look like they are on our network so I am wondering if perhaps I don't have my communities set up correctly. This is a copy of my tracert and ping when there is no device.  If the device is there but not turned on it just times out, but the tracert still finds the checkpoint first.   

I am not asking what is wrong with my community, I'm just asking if other people who have vpn communities also get this kind of response (unless by looking at this you say oh, I know what that is!) I am specifically wondering about the tracert showing the inside gateway hop, the isp hop, and then the device being reached. I would have expected to see it just going straight there without seeing that.  

Also, if there is something I can do to make it not reply with destination host unreachable and just time out that would be great too. 

No device on other end:

Pinging 10.100.20.10 with 32 bytes of data:

Reply from 99.999.999.99: Destination host unreachable.
Reply from 99.999.999.99: Destination host unreachable.
Reply from 99.999.999.99: Destination host unreachable.
Reply from 99.999.999.99: Destination host unreachable.

Tracing route to 10.100.20.10 over a maximum of 30 hops

  1     2 ms     2 ms    <1 ms  172.18.103.1
  2     1 ms     1 ms     1 ms  172.16.106.9
  3     1 ms    <1 ms    <1 ms  172.16.100.41
  4     1 ms     1 ms     1 ms  InsideCluster [172.31.888.88]
  5    15 ms    14 ms    14 ms  static-99-999-999-99-tamp.fl.frontiernet.net [99.999.999.99]
  6  static-99-999-999-99.tamp.fl.frontiernet.net [99.999.999.99]  reports: Destination host unreachable.

Device is there:

Pinging 10.100.20.24 with 32 bytes of data:

Reply from 10.100.20.24: bytes=32 time=17ms TTL=123
Reply from 10.100.20.24: bytes=32 time=17ms TTL=123
Reply from 10.100.20.24: bytes=32 time=17ms TTL=123
Reply from 10.100.20.24: bytes=32 time=17ms TTL=123

Tracing route to 10.100.20.24 over a maximum of 30 hops

  1     1 ms     1 ms    <1 ms  172.18.103.1
  2    20 ms    52 ms    51 ms  172.16.106.254
  3    <1 ms     1 ms    <1 ms  172.18.42.2
  4     1 ms    <1 ms     1 ms  InsideCluster [172.31.888.88]
  5    14 ms    14 ms    14 ms  static-99-999-999-99.tamp.fl.frontiernet.net [99.999.999.99]
  6    14 ms    14 ms    14 ms  10.100.20.24

[the_rock]

I cant speak for anyone else, but I can tell you that every time I had seen this problem, it was related to routing.

Andy

[Terri_Hawkins]

So right now I do not have a route for the internal addresses, they just use the route of last resort (which is the firewall). You think that is what does it? I could have routes added for those subnets and send the traffic to the switch behind the firewall!  That would be great, think I will try it. Thanks!!!

[the_rock]

Sounds like a plan!

[G_W_Albrecht]

You do know that it is the GW that sends Destination Unreachable ? ICMPv4 has 16 different Destination Unreachable types, Code 0 to 15. So it is ping and traceroute that give you these, not the CP. But why do you scan for unused IPs at all ? You should have a list of all devices present and not have to scan all possible IPs...

[Terri_Hawkins]

We do the scan for everything behind the firewall since that will help us discover new devices.  We have a report of newly discovered devices generated that way.  I'll have to see if there is a better way to do that within our product. Thanks for the reply!

[Machine_Head]

You could block icmp type 3?

[Timothy_Hall]

It would appear that the firewall's Gaia OS is unable to obtain an ARP mapping for the nonexistent host and is sending the Destination Unreachable.  Traffic emanating from the firewall is subject to the rulebase just like any other traffic, so simply create a new rule on the firewall/cluster in question like this:

src=firewall/cluster object

dst=nexpose

service=dest-unreach

action=drop

Just make sure that the implied rule "Accept outgoing packets originating from gateway" still has its default positioning of "before last" and has not been changed to "first" or the above rule will not work.

[Terri_Hawkins]

I am absolutely going to try this, it would be a quick and easy fix while I check to see if I do have a routing issue or if there is another way to generate my newly seen devices report. I'll post how it goes.  Thanks so much! 

[PhoneBoy]

ICMP Host Unreachable messages come from an upstream device, typically.
You can always block these in the Access Policy.