Here is a look at my Installed SAs and the associated traffic:
Site1
Site2
You are right, it seems the configuration logic differs between GRE, IPIP, and EoIP on one hand and L2TP on the other, the former three do not support the use-ipsec parameter and the fact that ipsec-secret parameter is present (even if empty) is sufficient for them to use IPsec.
You can see that the SA traffic can get from Site 2 to Site 1, whereas traffic from Site 1 to Site 2 leaves Site 1 but is never seen at Site 2. The SAs show that ESP is used, and ESP is permitted in the input chain of your firewall filter at both sites, and no drop rule exists earlier in the firewall.
So the only explanation which comes to my mind is that one of the ISPs is blocking ESP in one direction. You should be able to confirm this by running the Torch tool on both WAN interfaces. Check the Protocol checkbox and choose ipsec as the Protocol value from the pre-defined list. When pinging the IP address associated to the GRE interface on Site 1 from Site 2 (you can start the ping and then switch over to Torch or you can have two tabs/windows open simultaneously), you should see ESP packets in both directions in the Torch results at Site 1, but only in one direction on Site 2. Don’t worry if it shows Site 1 as source and Site 2 as destination, it’s quite a mess in Torch, the important point is that you can see only one direction.
Come back with the result. If it confirms the suspicion, you can either talk to both ISPs or do a small trick to make RouterOS think that there is a NAT at one side, which will make it use the NAT traversal mode and thus encapsulate ESP into UDP.
If you can see ESP packets in both directions also on Site 2, post the output of /ip firewall connection print where protocol=ipsec-esp (after obfuscating the public addresses) from there.
I agree with that. The fact that plain GRE works OK and this simple config of IPsec doesn’t points to some filtering.
You normally do not really need to open firewall ports or protocols with this symmetric IPsec because the “established/related” match will
process all replies to outgoing traffic, and both sides send outgoing traffic to eachother that perfectly matches the incoming traffic.
On an unfiltered connection the “GRE with automatic IPsec” configuration typically works on first try.
(sorry for mentioning “use IPsec”, indeed it is not a separate parameter here but it is implied by “opening” the input field for IPsec secret)
Yes, these are the results I get. Site 1 has traffic going both ways, Site 2 only has traffic going out.
How would I go about making RouterOS think there is NAT on one side? I’m assuming I would be doing this at Site 2, but please correct me if I’m wrong.
It is actually not important at which side you imitate the NAT.
Let’s define a couple of symbolic addresses:
- p.p.p.p is the public IP address of the Mikrotik where you implement the trick,
- i.i.i.i is one of its private addresses on LAN, it must not be from the subnet you use for GRE,
- w.w.w.w is the WAN gateway (from the same subnet like p.p.p.p),
- r.r.r.r is the public IP address of the remote Mikrotik.
The following should be sufficient:
/ip firewall nat
add chain=dstnat action=dst-nat src-address=r.r.r.r dst-adress=p.p.p.p protocol=udp dst-port=500,4500 to-addresses=i.i.i.i
/ip route
add dst-address=r.r.r.r gateway=w.w.w.w pref-src=i.i.i.i
On top of the above, change the local-address in the /interface gre configuration to i.i.i.i.
I assume that a src-nat or masquerade for traffic sent out via WAN already exists, and that no other rule in chain dstnat shadows the one above.
When you say one of its private addresses on LAN, should it be an address that is not assigned to a device? Or does it not matter if it has been assigned?
It must be Mikrotik’s own address assigned to some other interface than the WAN one and the GRE one, not an address of another device on the LAN.
Thank you for the clarification.
Configuring this at Site 1, would it look like this?
Would this also work without GRE?
Yes.
Yes.