I am trying to pass IPSEC traffic through a router that is doing NAT and routing public IPs. It appears to be dropping the tunneled traffic on the floor and I can’t figure out why. Public IPs changed for security. My config is below. I welcome all input. =)
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=Internet list=WAN
/ip address
add address=10.64.0.1/23 interface=bridge network=10.64.0.0
add address=2.2.2.2/28 interface=bridge network=2.2.2.0
add address=1.1.1.2/30 interface=Internet network=1.1.1.1
As you have posted only part of the configuration, it is not really clear whether the Mikrotik itself uses IPSec policies to catch plaintext traffic and encrypt it or whether the problem is transit of IPsec transport traffic between two other devices through that Mikrotik. Catching traffic using policies doesn’t make friends with fasttracking as @Sob wrote but the symptoms are not that all packets are dropped, only 99% of them which allows TCP sessions to work but really slow.
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 1.1.1.2, which causes the remote device not to accept it (or, if another ESP communication is already in progress on 1.1.1.2, 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 1.1.1.2 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=**!**2.2.2.0/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.