topic Path monitor setup using tunnel interface in Next-Generation Firewall Discussions

Path monitor setup using tunnel interface

raji_toor — Mon, 23 Jan 2023 20:42:16 GMT

Setting up a path monitor on a static route where source is a tunnel interface.

I am able to ping from CLI with tunnel interface IP as source. But the route does not get installed.

ping source 10.0.0.1 host 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=280 ttl=57 time=21.4 ms
64 bytes from 4.2.2.2: icmp_seq=281 ttl=57 time=21.3 ms
64 bytes from 4.2.2.2: icmp_seq=282 ttl=57 time=21.5 ms

Remote side is Azure and doesn't support tunnel interface with an IP. And I don't want to rely on any single Azure resource IP which might get deleted by someone else bringing tunnel down.

With static route I would be able to use multiple remote IP's for monitoring.

And I need to monitor it so I can remove associated routes so traffic transfers to 2nd tunnel using another internet link

Re: Path monitor setup using tunnel interface

Metgatz — Mon, 23 Jan 2023 23:37:31 GMT

Hello @raji_toor

With the All condition you are saying that when there is no connectivity to 172.19.252. "and" 4.2.2.2.2.

Now the best recommendation is to ping at least 2 or 3 IPs from the other end. If the other end cannot place an IP on its tunnel interface, there is no problem, as long as that IP is allowed through the tunnel, i.e. through the interesting traffic of the IPSEC tunnel, there will be no problem if only from your source you ping the IP that you assign to your tunnel that is allowed in the tunnel.

Now if you have a route with metric 10 and with a path-monitoring, the idea is that when this failure condition occurs, the route will be removed from the FIB and the route will be added, the route to the same destination, but with metric 30 for example, will take the place.

Best regards

Re: Path monitor setup using tunnel interface

raji_toor — Tue, 31 Jan 2023 18:58:45 GMT

My mistake was I was not trying to ping IP on the other end of the tunnel. Instead just pinging a public IP. I was thinking if internet is down tunnel is down anyways. Pinging an IP across the tunnel within Azure works.