Protective gateway route is not always default

[goug71]

In a scenario where the route toward the secure gateway was not the default route, I came to struggle with protective host-route toward the secure gateway installed toward the default gateway. I'd recommend running a best-match lookup and use this gateway for the protective route instead. I could propose a patch if someone points me toward the code that creates this protective host route.. (too busy to crawl code right now)

[DimitriPapadopoulos]

I'm afraid I don't understand the issue here (I don't have a strong background in networking). An example would help me understand.

[DimitriPapadopoulos]

My guess would be you're after ipv4_protect_tunnel_route() or something like that. Look in src/ipv4.c.

[goug71]

Sure, I should have included a bit of an example.
Imagine that you are multihomed, with secure gateway access on a dedicated link . Your routing table before kickin in openfortivpn would look like this :
default via 192.168.1.254 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.12
209.34.56.0/24 via 10.10.20.254 dev eth1
10.10.20.0/24 dev eth1 proto kernel scope link src 10.10.20.32
And the gateway you want to connect to is at 209.34.56.15. Then the code you pointed me to would install the protective route
209.34.56.15 via 192.168.1.254 dev eth0
instead of
209.34.56.15 via 10.10.20.254 dev eth1,
which would lead to tunnel-loop in persistent mode. I would recommend to install the host route toward existing best-match instead default route.

Also, I'm not too sure the protective route is installed only when necessary (better match exists within the vpn routes).
If this is too complex, maybe a config switch to disable protective route setup would nail 90% user cases.

[mrbaseman]

I see your point. Actually, the protective route is not necessarily based on the default route. But there are two issues with the default route:

• we remove the default route and establish a default route through the tunnel in default tunnel mode. That's a setting we receive from the Fortigate. In contrast, with split tunnel mode the default route is untouched and only a few additional routes are received for the tunnel. I think the situation on dual homed gateways is not correctly addressed by the current code. There are many combinations (if the default route is on the same interface as the vpn gateway, if default tunnel or split tunnel mode is configured, and probably a few more corner-cases)
• there is a confusing error message in the code, namely when removing the default route has failed, the error reads that protecting the gateway route has failed. Actually, protecting the gateway route starts on L.755 and looks up the current route on L. 764

You might have better luck on the dual homed gateway with the --half-internet-routes option or with --no-routes an adding the needed routes manually or with an if-up script. We have a related discussion in #741 and the current issue adds a new aspect on this topic.