If I add the rule as you noted in the other thread, I don't see any changes to my NAT ...
If you mean the policy
as I noted in the other thread, it won't change the dynamically added NAT rule no matter whether that rule matches on the connection-mark
or the src-address-list
as set on the mode-config
The thing is that if the IPsec transport packet doesn't fit to the uplink's MTU, because already the payload packet is large enough and the IPsec headers make it even larger, the router itself sends an ICMP notification "the packet is too large to fit without fragmentation, the maximum size is ..." to the sender of the payload packet (and the sender then sends a smaller portion of the TCP buffer i a new packet). The router sends this ICMP notification from its own IP address; in this particular case, it is quite likely that it uses the one in the LAN subnet. Since you have placed the whole LAN subnet to the address-list
you've put to the mode-config
, the dynamically added action=src-nat
rule matches also on this packet, as it doesn't check for any out-interface
so the fact that the packet should leave via LAN interface is not important. And once the rule changes the packet's source address, the IPsec policy redirects it and sends it down the tunnel so the sender never receives it.
So it may
be sufficient to change the address in the address-list
local from a prefix
(such as 192.168.0.0/24
) to a range
(such as 192.168.0.2-192.168.0.254
) which doesn't include the router's own address in the LAN subnet. With connection-mark
, the situation differs, as the ICMP notifications related to a connection inherit the connection-mark
from that connection.
So the use of the exceptional policy with action=none
is generic - it prevents packets from any src-address
(0.0.0.0/0) to the destination addresses in LAN (dst-address=192.168.0.0/24
in the example above) from reaching the dynamically generated action=encrypt
policy no matter for what reason they've suffered the NAT treatment. What is important is that it was placed before (above) the policy template from which the actual encryption policy is dynamically generated.
From what you wrote it is not clear whether you have tried it and it didn't help or whether you are still at theoretical stage. So please be clear, and if adding the action=none
policy doesn't help, post the output of /ip ipsec policy print detail
(after obfuscating any public addresses).