OK, so I continue.
What happens with a packet if it is not intercepted by an IPsec policy is determined
before the match to IPsec policy's traffic selector is attempted. There is no L3 packet processing layer after the IPsec policy matching which could take any action if no policy matches the packet. All routing and all evaluation of
routing-mark,
connection-mark etc. takes place before IPsec policy matching as
this diagram shows.
Vice versa, if the packet is not routed towards any interface because it matches a blackhole, prohibit or unreachable route, it can never be matched by any IPsec policy (nor even src-nated).
In case of IKEv2 with mode-config and the src-nat rule it creates dynamically, there is additionally the src-nat action in step 2 which is only taken if that IKEv2 connection is active.
But already this is a caveat: only the initial packet of each tracked connection is actually treated by the srcnat
chain of
/ip firewall nat, whereas the src-nat
action on the subsequent outbound packets, as well as the "un-src-nat" action on the inbound packets of the same connection, is done by the connection tracking module alone. So all packets, which belong to connections which have been src-nated to the IP assigned by the VPN server by the dynamically added src-nat rule while the VPN was up, will continue to be src-nated by the connection tracking module even after the VPN connection breaks. But as no IPsec policy will matche them while the VPN will be down, they will be sent out the gateway interface chosen by routing, except that with a wrong source IP address. How far such packet can get depends on the anti-spoofing policies applied along the path, and there is unfortunately no guarantee that your ISP will drop them, so they may even make it to the destination - either with the source address being the one you got from the VPN server when the IKEv2 connection came up, or with your public IP if you don't have a public IP on the Mikrotik itself but on ISP's routing modem.
When your client host initiates a new connection while the VPN has already disconnected, the dynamically created src-nat rule is not present in the srcnat chain, so also in the postrouting chain, the initial packet is treated as any other one.
So:
- to make sure that the packets can be matched by an IPsec policy, they must be routed out via some interface,
- to make sure that they won't leak if they are not matched by an IPsec policy (because the VPN is down), they must be routed out via an interface which actually sends them nowhere.
These two requirements taken together mean that packets belonging to this category must have their own route in step 1 (with the blackhole bridge as a gateway interface), not the common default route which usually uses the WAN as its gateway.
But again, it is just one way how to do it. Your approach, with the "emergency" src-nat rule changing the source IP of those packets which otherwise the dynamically added src-nat rule would process, works as well, except that if used without additional measures, it only prevents the leaked packets from carrying your WAN IP, which may not be sufficient as said above - if your ISP box does NAT, it is likely not to care about the source IP of the packet you've sent to it, so the leaked packets will be sent to the original destination with your normal public IP. So to make that approach fulfil the real goal, you have to complement it with the bridge filter setup I've linked to above, which is the last place where you can stop packets with undesired src-address from being actually sent. However, there are complications associated to that step:
- you cannot insert the bridge filter into the path if the WAN interface is an L3 tunnel (such as PPPoE),
- if also the WAN interface address is dynamically assigned, the bridge filter rule must work with a subnet or more than one may be necessary to let through the traffic which needs to be let through and drop the leaks.