So now you know why you should have done the obfuscation the way I suggest in my automatic signature rather than blindly remove the IP addresses completely.
It seems that what I’ve suggested as an explanation may be true, except that the trigger event is not a WAN failover but simply a long enough pause in traffic, after which the ESP starts being sent again and the action=masquerade chain=srcnat comment=GW out-interface=ether1 src-address=!10.240.240.250 rule changes the source address to the .162 one. Or the IPsec stack is confused, hard to say.
What does /ip firewall connection print detail where dst-address~“ip.of.the.client” show in this state? If it shows src-address=x.x.x.163 and reply-dst-address=x.x.x.162, the ISP stack behaves correctly and we have to prevent the action=masquerade rule from acting on ESP by adding protocol=!ipsec-esp to it; if already the src-address is x.x.x.162, it means that the IPsec stack has chosen a different IP to send the ESP after the pause; in that case, you would have to place a chain=srcnat protocol=ipsec-esp dst-address=ip.of.the.client action=src-nat to-addresses=x.x.x.163 before the first action=masquerade one.
Still not luck.. one of IPSEC tunnel works at the moment, but other one still not Working one use the right gw ip .163.
Other non working /ip firewall print still show ip with .162 for some reason. Same thing i can see in captured packets.
This /ip firewall connection print … shows that the IPsec stack has bound the connection properly to .163 but the firewall has src-nated it to .162.
So do prevent the masquerade rule from acting on ESP by adding a protocol=!ipsec-esp match condition to it as I’ve suggested in my previous post (it is not a 100% clean solution but good enough for this particular case and I don’t want to overload you with details at this stage). Since rules in the nat table only act on the first packet of each connection, you have to remove the existing src-nated ESP connection from the conntrack data after the modification: /ip firewall connection remove [find where srcnat and protocol=ipsec-esp]
The next packet will re-create the tracked connection, but without the src-nat.
Ok. Some how got working both tunnels now. I have added protocol=!ipsec-esp to my main GW .163
/ip firewall nat
add action=masquerade chain=srcnat comment=GW out-interface=ether1
src-address=!10.240.240.250 protocol=!ipsec-esp
So use /ip firewall connection print detail where srcnat and protocol=ipsec-esp .
But as it is working now, chances are high that this command will also show nothing because the NATed connection has expired in the meantime due to lack of any traffic updating it. To double check, use /ip firewall connection print detail where **!**srcnat and protocol=ipsec-esp , you should see the working connections.
Sindy could you explain again for me simply stupid what did fixed this my issue:
That i removed all srn-nated connections ? Or that i have added this rule to my GW ?
The modification of the masquerade rule was necessary to prevent newly created ESP connections from getting src-nated.
The removal of already existing src-nated ESP connections may have been necessary, or may have been not.
The thing is that there is the actual ESP connection as handled by the IPsec stack, and there is the understanding of that connection as handled by the firewall. The IPsec stack doesn’t know anything about the existence of the firewall, and the firewall has no other information about the actual connection but observation of its packets flowing through it. So if there is a long-term silence (more than 10 minutes by default) in both directions, the firewall forgets about the connection. Once the IPsec stack receives a payload packet from LAN and sends an ESP one carrying it, the firewall cannot find any connection matching that packet, so it creates a new one. Before the modification, this new connection got src-nated, so the remote peer ignored the ESP packet because it was coming from an unexpected address.
And it sometimes worked because in some cases, the first ESP packet after the silence came from the peer, not from the local IPsec stack; in that case, the firewall has created a connection without any NAT.
