Ipsec is a security feature that allows for the implementation of a secured end-to-end tunnel over the public internet as well as the encryption of the data passing through the tunnel. Over the years, the demand for IPsec VPN has increased exponentially and so has the demand for network administrators who are skilled in the deployment of this advance feature. Recently, Mikrotik, Cyberoam, Checkpoint and a few other network equipment manufacturers have simplified the configuration of the IPsec VPN, thanks to the simplicity of their GUI. Even the almighty Cisco through it Cisco Configuration Professional (CCP) has also simplified IPsec VPN setup on its security devices. On a Mikrotik router, with a few clicks and proper router setups and NAT rules, your IPsec tunnel will be up in no time. But like every good thing, it comes with a barrage of problems.
Site-site VPN tunnel: Credit Google
One of the most common problems users of Mikrotik face when using it for site to site IPsec VPN is that the connection fails to establish after any of the two routers is restarted. This usually happens at the commencement of daily operation when the routers are powered up. When this happens, a user goes through series of undocumented troubleshooting procedures aimed at re-establishing the connection. Having experienced this, I have put together these simple steps that will help put a stop to Mikrotik Ipsec connectivity issues.
To appreciate this solution, one needs to have a grip of what happens when a communication needs to take place over an IPsec tunnel. There are two phases involved. The phase 1 takes care of authentication while the phase 2 is saddled with the encryption of data sent through the tunnel. Depending on your preference, the phase 1 may make use of MD5 while phase 2 may use the camellia 256 encryption mechanism. For an IPsec tunnel to be established, phase 1 must be successful. Unfortunately, the problem on which this article is written, happens in phase 1. Because the authentication phase was not successful, the tunnel could not be established. To make matters worse, the keys and all parameters remain correct and the same on both routers. So what could be wrong? Read on.
Here is how a user by name Royalpublishing summed it up on Mikrotik forum:
“I am on 6.33 and I have just dealt with this ongoing issue for like over a year now and I am getting extremely frustrated by this. It seems like this problem just randomly pops up once every few months or so and this morning was one of them. It’s not a firewall issue here, all VPN routers have input rules to allow all traffic. Even after a reboot of all routers involved, they still won’t connect which just blows my mind. Disabling the non tunnel related IP addresses, IPsec rules, flushing the SA’s, and re-enabling rules didn’t seem to work for me however I was not onsite and had to connect remotely via winbox and had to be extremely careful not to lock myself out. It seems like the outages where these messages are displayed in the event logs last for around 30 minutes at a time and then traffic starts passing again.”
Just like him, I was faced with this problem and after several temporary solutions, the issue was permanently resolved when I upgraded from routerOS 6.37.5 to 6.39.3. While there are many proposed solutions by different users, many of which never worked for me, the issue was resolved through software update.
Conclusion:
In conclusion, this issue is caused by a bug and it is not peculiar to you alone. Since Mikrotik releases bug fixes in subsequent updates, the issue can easily be resolved through software updates on both routers. To carry out software updates on the router, simply click on system>>packages>>check for updates. Note that for this to work, the router must have an active internet connection with an assigned functional DNS server address.
