When using Ike2 with mode change, it is quite complicated to avoid LAN leaking to the internet when the IPsec peer is down.
This is because the dynamic src-nat rule disappear when the peer is down, causing the LAN traffic to be routed unencrypted to Internet through the default route gateway.
The workaround is to create a new default route with policy routing for the LAN traffic needing encryption before reaching Internet, and use a bridge without port as the gateway.
Like this when the peer is down, the LAN traffic cannot be routed to Internet because there is no output port in the bridge.
When the peer is up, the LAN traffic is routed to the bridge, then go to the MPLS check then IP check, where it enter IP routing and go to postrouting. At the exit of postrouting it is catched by the IPsec policy and sent to Internet with a new routing decision after IPsec encryption.
This is only like this that LAN traffic can go out of the the blackhole bridge gateway.
The drawback of this solution is that there is no ICMP network unreachable sent back, then users need to wait for an HTTP session timeout for example before to know there is a connection problem.
It would be simpler to have an option in the Mode-config setup to create a dynamic firewall filter rule when the peer is down,
This could be a dynamic rule in Raw prerouting, with a jump to a settable chain, so that we can kill leaking traffic here. Or in forward so that we can use a reject action with ICMP network unreachable for example.
**This seems important to me because :
the workaround is not evident to find (except perhaps for very advanced users)
this kind of IPsec setup will produce LAN leaks when IPsec peer is down
this is even more important because an IPsec peer down will silently reroute the LAN traffic unencrypted to the default Internet gateway. That can translate to a security disaster.**
The blackhole bridge as a gateway for the traffic which must not leak is a safer way than any dynamically added/enabled firewall rule, as the packet processing in kernel is faster than any firewall rule modifications (which are done from userspace), so a few packets could often leak before the rule would become active.
Ok thanks i did not know this. You have a very impressive knowledge
So a modification in the IPsec process (IPsec is in kernel mode isn’t it ?) could probably be done to reject input traffic when there is no peer available.
This would be simpler than the blackhole bridge story. Most users probably don’t know how to protect from IP leaking when an IPsec peer is down with IKE2 / mode-config setup.
And even worst i feel that some users are not aware of the leaking risk with this setup. For this reason this should be managed in Router OS, at least through a mode-config option to avoid leaking, regardless the final method (action in the IPsec process or dynamic firewall rule).
I add unreachable routes to all private subnets (whole 10.0.0.0/8, etc) as a simple default way how to prevent leaks. Then if some subnet exists (either static or from VPN) and should be reachable, there’s more specific route to it and it works nicely.
Except with IPSec, because it doesn’t add any routes, but does require active route to remote subnet, so I have to manually add it. I also use empty bridge as gateway, because it’s enough that the route exists and when it actually doesn’t lead anywhere, there aren’t leaks when tunnel is down. But it’s the same problem, router thinks that it’s always active, even when it isn’t. And I don’t like that I have to add it manually.
What I’d like is what I’ve seen on Linux (???swan, and I don’t know if it was default or optional). It added dynamic routes to remote subnets when it connected with peer, with gateway same as system default gateway (but gateway doesn’t really matter, just that the route exists).
Err, which traffic in particular? As long as we talk about statically configured policies, these prevent packets from leaking anywhere simply because they exist - according to the IPsec standard, a packet matching the traffic selector of any existing policy must be intercepted by that policy, and if no SA is currently associated to the policy, such packet must be dropped. More than that, a packet which inverse-matches an existing policy but has not arrived via its associated SA must be dropped too.
But here we talk about a dynamically created policy, which is (are) only created once the peers establish an IKE session and negotiate the policy using mode-config, so while there is no active peer, there is no related policy either. So blocking or blackholing that traffic must be provided using means outside IPsec, or there must be a statically configured policy with action=discard which gets superseded by the dynamically created policy once it is created. To do this, the policy template from which the policy is dynamically created must be placed before (above) the action=discard one.
Which end are we talking about? The responder which decides what IP address, and what split-include list of subnets it can talk to, to assign to the initiator, or about the initiator which doesn’t know even the address it will get from the responder before the IKE session is established?
Many users are not aware of many security risks, which doesn’t stop them from setting up VPNs and permitting remote access over the internet (and then being surprised by the consequences). I feel sick when I see people copy-pasting solutions from the forum, or even worse, Youtube, without even trying to understand them.
Even stronger. Most user don’t know that their IKEv2 is leaking during the connection is coming up.
I use marking all IKEv2 traffic with a routing mark which in NAT is redirected to nothing.
This in NAT is not static nor are the connection marking in Mangle. It is a complex script handeling that for 10+ connection and for different type of traffic. It is very flexible but it depends of a scheduler that runs it every 10 seconds. As long the Mangle rules (max. 10 seconds) are not generated for a new connection that routing marked traffic will be still stopped in Nat.
Removed connections are also stopped and after max. 10 seconds the connection marking for that connection is stopped and is not hitting anymore the redirector to nothing.
It adapts on adding or removing connections and when there is available IKEv2 connections, you are dead in the water till IKEv2 connections come available.
