IPSec site-to-site tunnel problems

RouterOS General
1

Hi!

I have two problems with an IPSec site-to-site VPN tunnel. I have two Mikrotik devices, a CCR1016 on the main site and a hex in the branch office.

I established an IPSec tunnel between them using:
Proposal:

  • Auth. Algorithm: sha512


  • Encr. Algorithm: aes-256 gcm


  • PFS Group: ecp521

Profile:

  • Hash Algorithm: sha512


  • Encr. Algorithm: aes-256


  • DH Group: ecp521

The tunnel works fine, has a good performance and the EoIP tunnel I routed through it works as well.
The problem comes when I reboot the branch offiice router. The connection wont establish until I disable the firewall rule:

/ip firewall filter
add action=drop chain=input comment="Drop All Incoming Connections" in-interface=ether1

I have firewall rules enabled that should ensure the proper authentication and connection:

/ip firewall filter
add action=accept chain=input comment="IPSec UDP Accept" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="EoIP GRE Accept" protocol=gre
add action=drop chain=input comment="Drop All Incoming Connections" in-interface=ether1

After I disabled and then re-enabled the Drop all connections rule the tunnel works fine, even if I kill the connection on either routers they reconnect almost instantly.
The other problem I have might not be a problem at all but in the Installed SAs tab in Winbox Auth. Algorithm is listed as none for both phases. Encr Algorithm is listed as aes gcm and Encr. Key Size is listed as 288.

Please help!

2

Add accept rule for ipsec-esp too .

3

I have the rule active on the Main site router. It did not make a difference on the branch office router unfortunately so I deleted it.

4

Can you check the rule “add action=drop chain=input comment=“Drop All Incoming Connections” in-interface=ether1” is last on input chain in filter section and same rules on both sites?

5

Yeah it is. It comes after all the other input rules.

6

Which connection won’t establish? The EoIP one or the IPsec one? Do both routers have a static public IP address or is one of them behind a NAT/its address changes dynamically (perhaps with each reboot)?

If it is the IPsec itself that doesn’t start: just before the “drop the rest” rule in chain=input of /ip firewall filter, place an action=log log-prefix=ipsec-start-packets src-address=the.ip.of.the.other.router one. Then reboot the branch office router and run log print follow-only where message~“ipsec-start-packets”. This should tell you what kind of packets the remote router is sending that your firewall filter blocks.