We have several GRE over IPSEC tunnels configured, all of them between Mikrotik routers. Everything works fine except one issue we are observing, the tunnel always drops at the SA soft expiration time.
We have tried different SA expiration intervals and it always happens the same. Right now we have set 26h for the proposal and 52h for the peer so the SA expires in about 24h and we can force the renegotiation to happen during the night.
Has anyone observed this behaviour?
Our Mikrotiks run ROS 6.44, the IPSEC tunnels are configured using IKE2 and modeconfig to allow remote dynamic IP clients. We also tried playing with DPD, changing check=strict to obey, exact… with no luck.
It seems the expiring SA gets removed before the new one is negotiated, therefore the connection is always lost for 3 minutes aprox. That’s the time that takes the full initial negotiation.
We keep facing this issue. No solution / workaround found yet. We are thinking in scheduling a script to kill all the ipsec connections once during the night so that we keep the tunnel stable in the daytime.
We have also observed that having the devices in different timezones affect the SA expiring time. See picture atached.
Any ideas? Is this supposed to happen? Should we always have a tunnel drop when renegotiation is made?
What if we configured back the default and recommended lifetime values of 4 hours? 6 tunnel drops per day?
We would appreciate some input, we can not afford these drops in our network.
Doing some reading we see other vendors have implemented some Make-before-break / rekey / keepalive methods to avoid such disconnects.
I don’t have much input.. sorry! I checked my IPSec configs, and I found that a second set of SA’s get created, both sets exist for maybe 30 seconds and then the first set a is removed. My soft lifetime is 30 minutes, hard lifetime is 1d. The status of the SAs say 24/30 for “add lifetime”. It’s after 24 minutes I notice my SA’s get recreated. I’ve done FTP transfers lasting several hours and there are no disconnects while SAs are re-established. My config varies from yours though. Exchange Mode=main, DPD=120, DPD-Max-Fails=5. Both sides have static IPs. My packages are 6.43.12. I suppose you can’t copy that since one side is dynamic.
Years ago I had problems with a Mikrotik and Cisco, I had no control over the Cisco. I too had to use a script to ping a remote host. If the host stopped replying, the tunnel was down. So the script would flush the SAs and do more pings to trigger a renegotiation. I would lose 3 pings while renegotiating but the 4th was usually a success. I had to check the remote host every 5 seconds, tunnel would be down for a max of 10 seconds at a time.
Thank you very much for your answer! I suspect this issue is caused by Mikrotik’s IKEv2 implementation. As you are using exchange mode=main your tunnel runs on IKEv1.
We had a previuos VPN configuration using ike1 and main / aggresive modes, but to be honest, I can’t say if we had this same problem. Also we were mixing different vendors hardware and it wasn’t the most stable configuration.
We can’t go back to ikev1 because we want to handle dynamic clients with or without NAT. Actually we went for IKEv2 to avoid implementing scripts to do the tricks. This is a production environment and we can’t do too much testing.
To sum up, some bulletpoints:
IKEv2 negotiation takes 3 minutes on average. Is this normal?
SAs get removed before new ones are established so the tunnel drops everytime. It takes 3 minutes to come back due to the previous point.
We finally solved the issue. All this strange behavior was caused by the ISP router.
Our Mikrotik concentrator has public IP, is not behind NAT and the ISP router was supposed to do nothing but passthrough / routing. But the last was not true.
I found the ESP ALG was enabled on it. The moment we disabled it the IPSEC tunnels started to negotiate fast and now work like a charm.
I also enabled ESP Header Forwarding, but I think it does not affect in our setup. ESP Header Forwarding: When enabled, this feature allows forwarding of packets from 6rd tunnel endpoints, to and from legitimate node addresses, with an upper layer protocol of type Encapsulating Security Payload (ESP) in their outer IP extension header chain
