UDP (SIP) not passing through an IPsec tunnel randomly

Hello,

anyone any idea?

  • site2site IPsec tunnel over internet,
  • firewall filter rules used at both ends so connection tracking is not disabled for tunnelled traffic,
  • exceptions from src-nat are made,
  • exceptions from fasttracking are made,
  • everything works almost all the time.

However, from time to time, none of the four SIP re-registration attempts sent within 4 seconds passes through. After that happens, these four attempts are repeated every 2 minutes (CPE behaviour) until one of them eventually succeeds. Sometimes the success comes without any known activity on my side after units to tens of minutes, but whenever I manipulate the routing table at the sending RouterBoard in any way, the next registration attempt always succeeds.

Firewall logs and counters show that in the weird state, the packet arrives from the CPE to the sending RouterBoard but never reaches the receiving RouterBoard.

I couldn’t find a way to visualize the actual contents of the routing cache - I assume that since manipulation of routing table, even of routes with dst-addresses not related to the packets in question, fixes the issue, the routing cache is involved in the issue and that such manipulation clears it.

It doesn’t matter whether the SIP service connection tracking is enabled or not. If enabled, the SIP connection lifetime is 60 minutes after a successful registration and 3 minutes after a failed one, if disabled, the lifetime is 3 minutes regardless whether the registration has succeeded or not.

It seems that the issue is triggered when a machine in a LAN subnet of the local Mikrotik, but other than the one on which the src-address of the IPsec policy matches, accesses the remote Mikrotik’s https interface. To make that possible, src-nat to the LAN IP of the local Mikrotik is used in order to make the IPsec policy match the packet. However, the issue doesn’t happen immediately when this https connection is established and periodically transfers data - one or two SIP registrations still got through successfully after the https connection had been established. Vice versa, after tearing down the https connection, it took several unsuccessful registration attempts until the registration has finally succeeded. No routing table manipulation was necessary in that case.