IPsec VTI and default route
I have a net with public IPs, all internet traffic I want to tunnel via IPsec to an internet access point.
In other words, the only traffic that should ever go to the local ISP is the IPSec traffic, all other traffic should go in the tunnel.
So local network would be something like 18.104.22.168/24 and remote network would be 0.0.0.0/0, which of course in theory creates a conflict with the route required to carry the IPSec traffic.
This used to work with regular IPSec, because it snatches the packets once the link is established.
The question is, how would this work with VTi? Since the systems are remote, it's easy for me to lock myself out.
Given that VTi goes into the regular routing tables (or so it seems), putting the default route of 0.0.0.0/0 on the IPSec link, does that create a conflict with the IPsec traffic?
I need to avoid that the system tries to send the encrypted traffic over the tunnel...
With VTI, like you said, it uses routes, not what you put in the P2.
You could policy route traffic out the IPsec VTI interface from inside, rather than relying on the routing table. This wouldn't catch traffic from the firewall, however.
Check your routing table for the IPsec peer, this probably already has a static route entry added putting it out through WAN, which would override the default route, so changing it would still let you get to the IPsec endpoint.
Also if you have access setup to reach the firewall from the WAN for management (locked down to a specific source, at least) then reply-to would still allow you to login to the web interface even if the default route is through another path.
@jimp Thanks, will investigate this, once my system is back up.
One thing in the documentation I don't get is that it says that "Routed IPsec works best when both sides support routed IPsec. It can still work when only one side supports routed IPsec, but most of its benefits are lost."
Exactly would that look like? Not quite clear on how to understand that phrase.
If one side supports routed IPsec and the other side only supports tunneled IPsec, then it can still work provided that you only attempt to send traffic that matches the P2 entries on the remote end. Anything else would fail.