Strange routing with VTI and 0.0.0.0 phase 2
-
Hi,
I witnessed a routing behavior that I don’t understand.
The task was to set up a VTI IPSec tunnel between a FortiGate 6.2.2 and a pfSense 2.4.4-p3. It is common practice to use 0.0.0.0/0.0.0.0 as the phase 2 selectors on FortiGates. pfSense-to-pfSense tunnels I usually operate with /30 transit networks on the VTI tunnel, but in this case I wanted to try out 0.0.0.0/0 on the pfSense, too.
The tunnel is established correctly. When I assign the interface, the gateway is created. I turn off gateway monitoring and set up a static route over this gateway (routing on the FortiGate correspondingly). At this point, local and remote networks still cannot communicate.
They can communicate (immediately), if I activate the advanced option “Use non-local gateway through interface specific route”. However, after a while the default route is pulled to the IPsec tunnel. This makes no sense to me, since the global default gateway setting remains unchanged. Why does the VTI gateway take precedence? It seems that 0.0.0.0 is interpreted here as a default route, although this should not be the case in this context. Everything works fine with a /30 network.
Best,
Morlock -
we were discussing something similar just yesterday
https://forum.netgate.com/topic/150118/how-to-config-2-or-more-dailup-ipsec-vpn-tunnel-using-remote-gateway-ip-0-0-0-0-the-error-is-showning-the-following-input-errors-were-detected-the-remote-gateway-0-0-0-0-is-already-used-by-phase1-dailup-2/4
for your reference here https://redmine.pfsense.org/issues/9768
jimp said Other areas of pfSense assume things about that address, like making static routes for the peer, setting up DNS monitoring for hostnames, etc. It's nowhere near as simple as you imply.that said use something like dyndns instead of 0.0.0.0
-
It's similar, but different, since I am talking about the phase 2 selectors, not phase 1 counterparts.
The point with phase 2 selectors on VTI is, that they should be ignored for routing. pfSense seems not to support defining routes just via a particular interface, but relies on the remote gateway IP that is derived from the phase 2 network. Consequently, the adjacent 0.0.0.0/0 "network" is parsed as the default route in my case. At least that's my theory.
