I did a tracert with the NAT rule turned on. Looks like you are correct:
The tracert seems REALLY slow - not just the 51ms below.
Tracing route to 8.8.8.8 over a maximum of 30 hops
1 3 ms 1 ms 1 ms 192.168.65.1
2 51 ms 49 ms 56 ms 192.168.64.1
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
Could it be that the UK router doesn’t know what to do with the French packets? Do I need a corresponding NAT rule in the UK for the .79 packets?
You really hate what comes in via WAN (which is a good strategy). I’ve missed your other filter rules which kill the French laptop’s traffic before the rule we’ve modified yesterday can do it. These are the two following ones:
action=drop chain=forward comment=“Drop incoming from internet which is not public IP” in-interface-list=WAN log=yes log-prefix=“CH_Track !public” src-address-list=not_in_internet (it may actually not be effective because it depends on the not_in_internet address list, I don’t know whether you have edited it out or it is indeed missing in the UK configuration)
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
The remedy is the same - add ipsec-policy=in,none so that they ignore the decapsulated IPsec payload and we’ll finally get there. Or, another possibility, insert a rule chain=filter action=accept ipsec-policy=in,ipsec in-interface-list=WAN between the accept established,related,untracked and the drop invalid ones in filter to accept whatever comes in via an IPsec SA and has not been accepted yet by the accept untracked rule (because it has been marked as untracked by the rules in raw), but this way you’d shadow some more rules in your firewall so maybe better to stick with the former method.
As for the firewall - in principle all the rules in chain=forward of filter which follow the drop all from WAN not DSTNATed, except the very last one, only protect the rest of the world from devices in your LANs gone evil, because the packets which would match these rules but come in via one of the WAN interfaces never reach them as they get killed already by this last rule above them. So these are the rules which would be shadowed by the action=accept ipsec-policy=in,ipsec … one. On the other hand it would not change anything in the great scheme of things as the same rules exist on the French box so they kill such packets already there.
On PublicCloud side it's a route based tunnel so, IPSec policy is limited to single security association so, it is causing connectivity issues. For some reason we can not modify anything on Cloud side of the tunnel.
When I am propose following single policy (which covers both BGP peer ranges and on-premiise & Cloud network ranges) tunnel works perfectly fine but it is causing some internal routing issues on on-premise side.
(which is a good strategy). I’ve missed your other filter rules which kill the French laptop’s traffic before the rule we’ve modified yesterday can do it. These are the two following ones: