Hi,

So I have 1 HO, and 2 branches and previously these devices were on 6.43.12 and connected from the individual branch to the HO via IPSec VPN. Had almost no issues for a long time but with occasional hiccups. Today I upgraded all the devices to 6.45.1.

Here is what I did and what happened :

1) Upgraded firmware from 6.43.12 to 6.45.1
2) Disabled scheduler objection that ran a script to resolve DDNS names to fill in the resulting IP addresses into SA-SRC-ADDRESS and SA-DST-ADDRESS
3) Tunnels stayed open for a bit but then dropped.
4) All IPSec windows showed the peer column as "unknown" in all policies (HO and Branches). I went in into each policy object and just applied to get it to update and the unknown changed to the DDNS name of the relevant peer.
5) HO Router IPSec shows "no phase2" for both policies
6) Branch Routers IPSec shows either "no phase2" or "msg1 sent"
7) checking branch routers IPSec Policy Status tab shows SA Src. Address as 0.0.0.0. HO router shows the same in SA Src. Address 0.0.0.0.
8* Logs show "failed to pre-process ph2 packet" or "peer sent packet for dead phase2" on all routers.

I am sure there is no issue with the firmware, but I think with the way they changed the IPSec, something is misconfigured. Any idea what is missing?

Alright so I managed to get it to work. I was basically playing around with the settings and found that :

1) 0.0.0.0 on SA SRC address is not an issue, if phase2 connects the tunnel will work.
2) I went into IPSec > Peers and set Local Address as first, the ip of the router on that end of the tunnel and then secondly, as the public IP of that branch/office. After that, kill all the connections in Active Peers and Flush the SA's. And go back and set it the Peers > Local to blank and disabled. Worked out for me.

That is a security feature that was developed since 6.44! You need to set both Remote and Local Peer IP! Before there was just remote peer IP!

That is a security feature that was developed since 6.44! You need to set both Remote and Local Peer IP! Before there was just remote peer IP!

Thanks for this comment, it saved me. can you point me to exact release note, where this feature was introduced? I'm unable to find it...

Id like se relese note for this too. This was hella long nightmare to search for it !

That is a security feature that was developed since 6.44! You need to set both Remote and Local Peer IP! Before there was just remote peer IP!

I cannot confirm this to be the case in 6.45.7. Here, you can still have no local-address set on peer and it works anyway. Maybe it was an unintentional change somewhere between 6.43.whatever and 6.45.1?

Other than that, officially (i.e. according to the documentation), sa-src-address and sa-dst-address of the policy, which used to be configurable, became read-only properties, and once the peer property of the policy gets set, both the sa-xxx-address are really dynamically inherited from the peer's ones. But the configuration auto-conversion does not automatically do the reverse matching and assign peer value to policies based on sa-src-address and sa-dst-address.

So no way to set sa-src-address and sa-dst-address anymore? I have a site with 6.47 I was using loopback with private ip in prior version.

The detection of NAT is done during the IKE (or IKEv2) negotiation, and the data transport SAs have to behave based on the result of the detection. Hence it makes sense that sa-src-address was inherited from peer's local-address, and sa-dst-address was inherited from peer's address.

Is your use case different?

Hey Sindy, thanks for responding.

You know, I am not even sure anymore LOL. I think all the changes the ROS has been introducing, though the majority of them good, has got me a bit frustrated that I have to relearn stuff when I just want to get it to work and move on. I am in a situation where I have done 5+ differing types of IPsec, L2tp, Gre, PPtP type tunnels for different scenarios in the past months and ever single one has had issues. I have done a ton of these in the past but recently it has taken me a bunch extra time to resolve or I have had to hit up the forum or open a case to get answers. You helped me with the Digital Certs scenario and that works well. Site to site with static IP's works well. Ipsec w/GRE with multiple locations I never had a chance to circle back around to make more attempts and get it to work with more than one tunnel. L2TP/IPsec Road Warrior I have working successfully. PPTP with dynamic IP's works. All I want to accomplish this time around was a simple site to site with Mikrotik's on both ends and one end with a dynamic IP. No L2tp, No GRE just a straight Ipsec tunnel. I am not sure what is going on but my batting average (and probably my brain cells) has dropped a bunch of percentage points :)

I love it that Mikrotik ROS is like the Swiss Army Knife of Routing Operating Systems but keeping up with the pace of change is maddening.

Alright so I managed to get it to work. I was basically playing around with the settings and found that :

1) 0.0.0.0 on SA SRC address is not an issue, if phase2 connects the tunnel will work.
2) I went into IPSec > Peers and set Local Address as first, the ip of the router on that end of the tunnel and then secondly, as the public IP of that branch/office. After that, kill all the connections in Active Peers and Flush the SA's. And go back and set it the Peers > Local to blank and disabled. Worked out for me.

The clients we use connect via an dhcp IP address, that isn't a fixed IP address.
Does any one how to get around this problem when a dynamic IP address is used?

What problem in particular do you have in mind? If the "clients" (initiators) are on dynamic addresses, but the "server" (responder) is on a static one, there is no problem atop short time interruptions when the client's address changed. If the "server" is on a dynamic address but a public one, you can use a dynamic DNS service (for example, but not exclusively, Mikrotik's own "IP cloud" service) and let the "clients" connect to an fqdn rather than an IP number. Again, there will be short breaks when the IP of the responder changes, but ither than that it works...