Answering to myself - as you speak about "Customer's IPsec tunnel", I conclude that the customer runs his own IPsec peer on one of those 2.2.2.x addresses against some remote IPsec peer.
If that is really the case, the fact that outgoing connections initiated by 2.2.2.x are not excluded from your your action=masquerade
rule may be the root cause of the trouble in the following scenario:
- the customer's device listening at 2.2.2.x acts as an IPsec responder, so the initial IKE or IKEv2 packet comes from the remote side. Hence you forward it to the customer's device without passing through any NAT rule and thus your Mikrotik firewall's connection tracker establishes a connection without any NAT handling for the IKE session(s).
- thanks to the above, the IKE NAT-T detection doesn't detect any NAT between the peers, and so the peers choose ESP to transport the encrypted payload
- the customer's device is the first one to send an ESP packet towards the remote one; as there is no tracked connection yet for this ESP exchange in your Mikrotik's connection tracker, this first packet is matched by the action=masquerade rule and the source address of the packet is changed from 2.2.2.x to 126.96.36.199, which causes the remote device not to accept it (or, if another ESP communication is already in progress on 188.8.131.52, the connection is not created an the packets are not getting through because there woudl be an unresolvable conflict, given that the firewall would be unable to identify to which of the two connections a received ESP packet for 184.108.40.206 belongs and forward it appropriately. The SPIs differ per direction and are negotiated encrypted so there is no way to match the packet to one of the connections by its SPI value.
If the above is what actually happens, it is enough to add src-address=!220.127.116.11/28
to your action=masquerade
rule, and then use /ip firewall connection remove where protocol~"ipsec" and srcnat
to remove the existing connection with srcnat handling activated. The match pattern for the protocol
field in the remove
command is ipsec
because the same what I've described for ESP would happen for AH as well.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.