We have IPSec configured between a Mikrotik CPE and our HQ location using a non-Mikrotik firewall. On the 6.47.x code train specifically for new feature ‘ipsec - allow specifying two peers for a single policy for failover’.
We are able to successfully establish PH1/PH2, and can pass traffic between both sides whether traffic is initiated from our HQ or from the remote Mikrotik CPE. So far, so good.
We have an IPv4 loopback interface built on the Mikrotik for management, and would like HQ to be able to access this loopback interface via the IPSec tunnel at all times even if the Mikrotik’s LAN interface is down. However, currently HQ is only able to access the loopback interface if the Mikrotik LAN interface is up at the time the IPSec tunnel was established.
If the Mikrotik LAN interface goes down AFTER the IPsec tunnel is established, HQ can still ping/connect to the Mikrotik loopback interface.
However if the Mikrotik LAN interface is down when the IPSec tunnel is being established, then HQ is unable to access the loopback interface (even after PH1/PH2 successfully establishes) until the Mikrotik LAN interface is brought up.
Any idea what we are missing on the config to enable hitting the loopback bridge interface from the IPSec tunnel when its member ports are down during IPSec establishment?
I would say that the key is that the loopback bridge had no member ports at all - in that case, it stays up permanently. If you assign it a /32 address from the LAN subnet so that a single /24 policy was sufficient, it will constitute a “subnet” of its own, so it must not be the IP which is used as a gateway by the hosts in the LAN.
Also, the add interface=ether2 row under /interface bridge port indicates that ether2 used to be a member of some bridge you have deleted in the meantime, so the row is now useless at the best, possibly it even causes some issue.
Have tried a second loopback bridge ‘MGMT’ with no member ports - still unable to ping the CPE across the IPSEC tunnel until one of its LAN ports has been initialized. Tried the standalone MGMT bridge with a /32 inside the LAN subnet, and also separately tried as its own standalone /32 with a second Phase2 (as shown in the updated code snippet below). Same as before, no ability to ping the CPE until one of the LAN ports has been brought up even though can see successful PH1/PH2 establishment - if a LAN port is brought up, can then ping/manage the CPE via the IPSEC tunnel on either the MGMT /32 or the original /24 IP even if we subsequently bring the LAN port down.
Fixed the whoops on the ether2 not being linked to the original loopback bridge.
Any other thoughts? Have also previously tried setting an admin MAC address on the MGMT bridge and a static route for its /32; STP is disabled as well.
Yes, but it’s a guesswork as you’ve again posted only the part of configuration you deem related. The IPsec policies’ traffic selectors only get an outgoing packet for matching after all the “normal” routing and firewall handling has been done and the packet is just about to be sent out via the chosen interface. If no route to the packet’s destination address is active while the packet is being sent, the policies never see that packet as it is not routed anywhere. So if the “normal” route to the HQ’s address from which you ping the “loopback” address of the Mikrotik (which can be a default route, it’s not a law of physics that a default route must use WAN as a gateway) uses the LAN interface as a gateway, the packets sent to that address never reach the policy matching stage. If it is the case, the explanation why it works if you disconnect the LAN after the pinging has started would be the routing cache.
Appreciate you having taken a look - definitely understand wanting to see the entire config, especially as you correctly mention there are several other stages in the packet flow that can cause issues.
That being said, turns out enabling NAT-T resolved the issue (was hard disabled on the HQ firewall). The CPE LTE connection is via a CGNAT IPv4 address, so is required to be the initiator. With NAT traversal running, we are now able to successfully hit the loopback IP as soon as the tunnel is established whether or not the CPE ethernet interfaces are up at the time the tunnel is established.
OK, so the actual reason why it worked when Mikrotik’s LAN ports were up was that the hosts connected to the LAN were sending something to the HQ addresses, so these packets got encapsulated into IPsec transport packets, which have then pinched a pinhole in the NAT. When the LAN ports were down, no IPsec transport packet was sent towards the HQ, hence the ones carrying the ping requests in the opposite direction could not make it through that NAT. Plus it only worked at least the way it did due to the fact that no other IPsec client was connected to the HQ from behind the same public address, as only one ESP flow per remote IP can be handled by a NAT that uses just a single public IP (ESP has no notion of ports so there is no information allowing to tell one flow from another).