Hi, I am having an issue with IPSec/IKEv2 tunneling to Azure VPN. The tunnel connects and work fine but every now and again the tunnel disconnects and then the remote Mikrotik displays ‘Responder’ under IP/IPSec/Active Peers when it should read ‘Initiator’. I have to delete the entry to have the tunnel reconnect. Is there a setting I can use to make sure that the client router always sets itself as initiator? The Peer setting is set to ‘Send INITIAL_CONTACT’ and passive is disabled.
Thanks
I am not very sure but i have noticed mikrotik will respond anyway if the other peer will try to reestablish the connection so the setting should be set on the remote peer to as Passive only maybe. Why do You have to delete the entry after connection is reestablished? You shouldn’t loose connectivity to the tunnel after reestablished.
Does the connection reestablish in fixed interval or occasionally? Have you configured a lifetime or DPD Interval? Set loging for ipsec, debug to see more what is happening.
What i think is that probably you should have timeouts and droppings in your connection. Try setting a greater DPD Interval and DPD Maximum failures on both peers if you don’t wan’t your connection to be reestablished frequently because of timeouts.
Correct, you can prevent the peer from actively initiating a connection by setting passive=yes, but there is no way to prevent it from accepting incoming connections initiated by the remote peer.
@sv000008, send-initial-contact has a different meaning than the intuitive one, it actually means that any new session from a given IP address (port is ignored) replaces any existing sessions from that IP address.
So the question is why the connection initiated by the AWS peer negotiates different policies than the one initiated by Mikrotk - normally, both peers acting as initiators do not cause any trouble. So as @vasilaos wrote, analysis of logs is the next step to do.
Thanks for the responses guys, I might not have been clear and maybe the answer will remain the same but just for clarification, Azure VPN is providing the IPSec/IKEv2 tunnel facility and acts as the responder (IPSec/IKEv2 Server) and our offices connect to it. Our sites with Mikrotik devices connect directly to the Azure VPN virtual gateway.
Regards
Stephen
Hi, for whatever reason, once the link has dropped it doesn’t reconnect and when I look at Active Peers, my Mikrotik says says responder in the ‘Side’ column. If I delete that entry then the new entry that appear says ‘Initiator’ the then only does the tunnel reconnect. See image below. At the moment it is correct saying ‘Initiator’
So we’ve actually got several mysteries here - why the connection fails, why it re-establishes with swapped roles of the peers, as you say that the AWS peer acts as a responder only, and why the tunnel doesn’t work in this case.
As already said, only logging can shed some light on what actually happens.
So disable the peer or identity representing the AWS at the Mikrotik end (and if possible, also any other peers so that the log doesn’t collect “noise” from other IPsec sessions), open a command line window (by pressing the [Terminal] button), and write the following there:
/system logging add topics=ipsec,!packet
/log print follow-only file=ipseclog where topics~“ipsec”
Then, enable the AWS peer/identity and wait until the failure happens again and you can see the Responder row to appear in the Active Peers table. Once that happens, stop the /log print … command, download the file ipseclog.txt and read it - the answers should be there.
If you cannot find the answers on your own, follow the hint in my automatic signature just below to anonymise the log file and post it; just be aware that the public IPs are also present in the hexadecimal dumps in the log so you should sanitize these also (169.255 will be seen as a9 ff, translate the other two bytes too).
Also post the configuration export and the output of /ip ipsec policy print detail both when the tunnel is OK and when the Active Peers row is the Responder one.
I have that same switching of initiator to responder after the life-time refresh. This only happens to the connections that use NAT-T.
After the refresh/reconnect (not manually initiated) it still works fine here.
Remark, the connections are made directly and no gateway (NAT) router in between. The NAT is most probably on the other side with the VPN provider.
Thanks for the info guys will take a look at it.
A workaround that you can do is to kick automatically active peers that have responder status by script to avoid manually until you find the root of the problem
I tried exactly that and then they did not connect anymore and lost the connection. I had no time to test it any further.
I was using this script and it made things worse:
/ip ipsec active-peers;
remove [find side="responder"];
Sorry for necroposting but i have same issue with ipsec tunnel between VMware router and mikrotik. Sometimes tunnel just stuck, i cant ping another side until i flush SA keys. When tunnel stuck mikrotik also changing side status from initiator to responder. Time between when tunnel stuck is different, sometimes it working for one week, sometimes it stuck every day. Maybe someone have an idea how to fix this problem ? Thank you.
Two years later physics has not changed - without collecting a log, ideally from both peers (no idea what a “VMware router” actually means), it is impossible to find a fix. A workaround could be what has already been suggested by @vasilaos - it requires a scheduled script to work autonomously, and instead of removing the active-peer, I disable and re-enable the peer when a similar (not identical) issue happens with Windows server as the IKE (v1) peer.
Thank you for reply, VMware router means - VMware NSX Edge
I think i’ll Install syslog server, and try to catch problem. This problem can appear today or maybe in a week.