Double IPsec connection - failing

RouterOS General
1

So we have a central 3011 with a couple of remote offices with 2011s connecting to it via L2TP over IPsec.

At one of the remote offices we have two natted conections. We also have two connections at the main office. The idea is to have the remote router establish two connections with different metrics to the central office router, should one of the connections fail on either side.

Now, I’ve set it up following the wiki guide, using IKE2 and RSA certificates (same as in the other remote offices). ROS versions are 6.43.16 for the 2011 and 6.44.3 on the 3011 (main office).

The connections work just fine when one or the other is up. When both peers are enabled, as soon as the second goes through phase 2, the first one disconnects. Now the second is up and as soon as the first one tries to reconnect, all SAs from the second are dropped and the whole cycle repeats.

I’ve gone through the wiki forwards and backwards and through all the options. For the life of me I can’t figure out why it drops the first connection when the second goes up.

Is there some limitation that a particular certificate can only be used for one connection at a time? Any insight highly appreciated!

2

Anyone?

Edit: update, SAs remain intalled on the central office router (3011) until they time out; in fact several of them for the same IP pair (right now three for one IP pair and two for the other). On the remote router they are removed as soon as one connection replaces the other as stated above.

3

Please try setting “Send INITIAL-CONTACT” to no for both peers. If that does not resolve the issue, it is most likely firewall related. You have to use routing marks for at least one of the connections. Really depends on the configuration, which should be posted for us to be able to help you.

4

Thanks for replying emils. I’ll try setting initial contact to no. Also, I generally use mangle for everything but I tried to simplify the setup on this one by setting the “local address” for each peer. This way each connection was going out over the correct interface. Or at least that’s what it looked like to me. I’ll double check.

I’m on holidays right now so I’ll work this out in about two weeks time. I’ll also post all relevant configurations for you guys to look over. Sorry for not doing that in the first place.

5

Alright, so I had a couple of hours to kill yesterday and decided to look into this. First of all, I got it working! Read on to find out how.

After your comment emils I set “send initial contact” to no on both client and server (not sure if you meant client and server or both peers in the ipsec menu. I had already tried it on the client side only. The ipsec connections now connected simultaneosly though with some issues (mainly with l2tp). So I decided to research the wiki again and found the two relevant parts.

send-initial-contact (yes | no; Default: yes) Specifies whether to send “initial contact” IKE packet or wait for remote side, this packet should trigger removal of old peer SAs for current source address. Usually in road warrior setups clients are initiators and this parameter should be set to no. Initial contact is not sent if modecfg or xauth is enabled for ikev1.

This explanation is not abundantly clear to me. The “this packet triggers the removal of SAs for current source address” part makes sense. However it shouldn’t apply to my scenario as I have two different IPs on each side. Unless of course the second ipsec connection is going out the same interface as the first, right? The rest makes no sense to me. “In road warrior setups the clients are the initiators” (of course) “and this parameter should be set to no”. Why? Unless we’re talking 5 guys on laptops in some hotel all connecting from the same IP, it’d make sense to kill old SAs for that peer? In any case it doesn’t say if it should be set to no on the server or on the client. It seems to imply the server. But this would also imply that one should leave it on client side.

In any case, based on the above I started to suspect a routing and mangle issue so I kept digging. I also expected that setting the local-address parameter would make the connection use the correct interface.

IPsec, as any other service in RouterOS, uses main routing table regardless what local-address parameter is used for Peer configuration.

This was the final piece of the puzzle. My mangle rules were not set correctly and since you can only have one default gateway up in the main table (the others are shown in blue in winbox) I decided to skip using mangle and use routing rules instead. I created two routing marks and then two rules, each with dst-address set to one of the main office’s IPs and action set to “only lookup in table” to its corresponding mark. After this everything’s working as expected.

At this point I’m not sure if the routing, the “send initial contact” setting or both were the problem. And I don’t want to reenable send initial contact as I’m remoting in and I might lock myself out.

edit: typos. Hit submit instead of preview by mistake.

IKEv2 Dual WAN Setup not possible? (2:1 relation)
6

If you want to test and fallback to the previous config you can always use safe mode.

Alternatively or in conjunction with safe mode, you can put a /32 static route in that goes back to the Internet connection you’re accessing from. That way it will always be the most specific route in the table for mgmt.

7

Safe mode was hit and miss for a long time. I think it’s fixed now but a safe mode that isn’t safe is not something I’m willing to trust. I therefore never make changes that might lock me out unless I have a way to physically access the equipment.

The /32 route is not a bad idea. However in this case I’m accessing through the VPN. Neither ISP there provides outside connectivity to our router. Connections have to be initiated from that side. In any case, I can’t test it at the moment it even if I wanted to because the second ISP has been down for the last 48 hours.

edit: forgot the most important bit, thanks IPANetEngineer for chiming in!

8

No prob…the other thing you might want to consider for mgmt if it only allows outbound connections is an SSTP outbound tunnel (which traverses NAT with no issue) to a MIkroTik CHR in Digital Ocean or AWS. That way you can still use the /32 route for the mgmt tunnel and have reliable connectivity outside of the VPN for data traffic.

9

Right on, thanks again!