Respected Sirs, good afternoon!
I have 3 L009UiGS routers with different firmware - 15.1, 15.2 & 17.2, installed in 3 different locations with different ISPs.
IPSec tunnels are configured between them using the same template. Firewall & NAT rules are also same (please see attached configs).
Traffic between Router2 & Router3 is going fine. But from/to Router1 to Router2 and from/to Router1 to Router 3 - there is no Rx bytes/packets.
I have 2 ideas:
maybe there were some changes between ROS 15.2 and 17.2 that require some additional firewall/NAT rules;
some problem on Router1 ISP side
Could You please advise how to fix problem with IPSec tunnel from/to Router1 to Router2 and from/to Router1 to Router3?
Additional details will be provided (if required).
Thank You in advance! Router1.txt (8.63 KB) Router2.txt (8.6 KB) Router3.txt (8.31 KB)
Since Router1 uses DHCP to obtain its WAN address, it is not clear whether said address is a public one. The way you describe it, it seems most likely to me that it is a public one and that the ISP serving Router1 is blocking ESP, but that’s just a feeling based on some experience from the past.
So to know for sure, look at the output of /ip/ipsec/installed-sa/print at Router1 and Router2.
Are there only addresses in the src-address and dst-address columns (which indicates that use of bare ESP has been negotiated) or there are also ports (:4500 after the address, which indicates that NAT has been detected and UDP-encapsulated ESP is used)?
Is this the same for the SAs towards Router1 on Router2 and the SAs towards Router2 on Router1, i.e. have both routers come to the same conclusion regarding presence of NAT?
Dear Sindy, good afternoon!
Thank You very much for Your time & willingness to help!
Router 1 gets a Public IP from ISP via IPoE using router’s MAC address - so this is a Public IP obtained via DHCP.
Please find attached screenshots of /ip/ipsec/installed-sa/print on Router1 and Router2.
For router 2 - there are more IPSec tunnels on this router and all of them are working fine - except tunnel from/to Router 1. All tunnels are configured with the same template, all firewall & NAT rules are same. In my first post I didn’t mention other tunnels just to simplify the problem’s description.
L2TP VPN - it is my connection from home to specific router via L2TP IPSec VPN.
In these screenshots You can see that all IPSec tunnels have no ports - ports are present only for L2TP VPN.
I also think there is some blocking of thaffic from/to Router 1 on ISP side… but I have no idea how to check it. ISP Support insists that it doesn’t block any traffic…
To check that, start pinging the LAN address of Router1 from Router2 and the LAN address of Router2 from Router1, specifying the correct source address so that the ping request packets would match the respective IPsec policies. While the two pings are running, run the following command on both routers: /tool sniffer quick ip-address=ip.of.the.other.router ip-protocol=ipsec-esp
If the ISP does not block anything, you should see both incoming and outgoing ESP packets at both routers. If you can see only outgoing ones at both routers but no incoming ones, the ISP is blocking ESP. If you cannot see even outgoing ones, either the ping requests do not match the policy or there is some other issue (like the correct policy being shadowed by another one).
Dear Sindy!
Please look at the screenshots below… It looks like I’m doing something wrong - because I don’t see exactly “outgoing” and “incoming” packets…
I wasn’t precise enough. Do ping from one LAN (private) address to another, but sniff for the public address of the remote router. It is enough to show Router 1 and the opposite router (2 or 3). And make the windows where you run the /tool sniffer as wide as your screen allows - Mikrotik dynamically chooses which columns to show depending on the available space, so we could easily lose some of them if the window was too narrow.
OK. So run /ip/ipsec/statistics/print interval=1s on Router 1, then start pinging the private address in Router 1 LAN from Router 2, then stop again. Does any value in the statistics grow while the ping is running and stays the same while it is not?
OK, so most likely the 7.17.2 IPsec doesn’t like something about the ESP packets it receives from 7.15.x and doesn’t decrypt them.
Since you use an individual proposal for each peer even though their contents is the same, it will not affect the other connections if you change the relevant proposals at both ends, So instead of the current auth-algorithms=“” enc-algorithms=aes-256-gcm, try using auth-algorithms=“” enc-algorithms=aes-256-ctr, auth-algorithms=sha256 enc-algorithms=aes-256-cbc, or auth-algorithms=“” enc-algorithms=chacha20poly1305. Does it work with some of these proposals?
Yes, You were absolutely right! I changed Proposals as follows:
Auth Algorithm sha256 and Encryption Algorithm aes-256 ctr (Auth Algorithn was required by Encryption algorithm).
and pings between LANs started immediately!
Thank You very much!!!
Now just two small questions:
please advise which Encryption type would be best in my case (compared to previous settings)?
should I change Proposals for other tunnels on other routers & update their ROS?
P.S. if I can to thank You more than just “thanks” - please let me know in PM. I really appreciate Your valuable support & efforts, and I feel very indebted to You.
Thank You once again!
I am not a cryptographic expert so I cannot suggest which of the encryption algorithms is more secure.
When it comes to throughput and CPU load, the available information is quite inconsistent. The Mikrotik product page does not mention support of encryption in hardware for the L009, but its block diagram says it is built around the IPQ-5018 SoC, and on the IPsec manual page, IPQ-5018 is listed among CPUs that do provide encryption in hardware - however, only for aes-cbc and aes-ctr combined with sha up to sha256, not for aes-gcm. Your first response shows none of the SAs on the 7.15.x device to use hardware encryption, but all of them, including the aes-gcm ones, to use it on the 7.17.2 device. But the changelog from 7.15.1 all the way to 7.17.2 does not mention anything related to hardware encryption on the IPQ-5018.
So if some of your L009 devices running 7.15.x shows high CPU usage or even exhibits performance issues, it may be a good idea to upgrade it to 7.17.2, change the proposals to aes-cbc or aes-ctr based ones, and compare the throughput and CPU load before and after.
As for PMs - except for a few brief periods in the past, they are disabled on this forum. So you can follow this post if you want, but I don’t need any “special thank you”.
