Gateway definition quirks

[Andreas_]

I encountered this problem with pfsense (they say it's not bug...), and checked with opnsense now getting the same results:

The definition of a gateway implicitely creates a route via that gateway, if a monitoring ip is given. I found this unexpected, and would like to have a checkbox to disable this behaviour (it will create icmp-redirects unless disabled by kernel params).

Anyhow, if this gateway entry is disabled, the routing will still persist, which I'd call a bug. IMHO a disabled entry shouldn't have any side effect.

[franco]

Is the route only for the monitoring IP (/32 or /128)? If so that sounds reasonable unless it's disabled. Then of course it's a bug:

https://github.com/opnsense/core/issues/557

Thanks for stopping by

[Andreas_]

Yes, the route is a host route.

I found this while "misusing" the gateway for monitoring connectivity, e.g. a remote gateway through an IPSEC tunnel. I defined a gateway with the LAN ip as gateway, and the remote gateway as monitoring ip (to ping through the ip tunnel, the source address must be local; ping would use the WAN address otherwise).
Actually, under some circumstances the icmp-redirect (probably auto-generated by the kernel) from this route can be plain wrong; I found a case when a route 80.x.x.x via 192.168.1.1 made the firewall emit "redirect 80.x.x.x to 80.x.x.x" on the 192.168 interface, advising workstations to go directly to 80.x.x.x. IIRC this occurred when 192.168.1.1 was a carp vif. I had to tune net.inet.ip.redirect=0.

I'd love an explicit option to use gateways just for monitoring purposes, i.e. with no route added, and not requiring the gateway to be locally reachable. This gateway would obviously be not be able to be part of a gateway group.

[franco]

For now, a fix to prevent (and remove) static monitoring host routes has been added.