One of our partner needs to setup an GRE over IPsec tunnel with us, we currently have IPsec established but failed to get GRE tunnel built.
Our side we only have an Mikrotik RB1100x4, the partner side they have their IPsec and GRE device seprated, like below:
1.1.1.1(IPsec source) — internet -----> partner’s IPsec router 2.2.2.2 (IPsec destination) — transit network —> parter’s GRE router 3.3.3.3
172.16.1.1(GRE source) — IPsec with GRE encapsulated -----> partner’s IPsec router ---------------> GRE —> 3.3.3.3(GRE destination)1.1.1.1,2.2.2.2,and 3.3.3.3 are 3 public IPs. What they suggests us is to have a loopback interface with a private IP(say 172.16.1.1), and then build GRE tunnel from 172.16.1.1 to their GRE 3.3.3.3 public IP. Will this work? And how can I guarantee the GRE tunnel will run on top of the IPsec?
Thank you for quick reply.
Yes, those 3 are definitely public IPs. I enabled the IPsec logging, but how can I troubleshoot GRE tunnels? I do not see a GRE option in system - logging.
GRE tunnel keepalives have funny addresses in the header and a strict firewall will often block them.
There is usually no need for them anyway, you already have keepalives at the IPsec level.
Can you be more verbose here? I’ve only seen RouterOS-generated GRE keepalives and they had the same src-address and dst-addres as those carrying a real payload, what am I missing?
The source and destination addresses are reversed from what they are for normal traffic.
This may mean they do not match firewall rules that explicitly check for the expected addresses.
OK, thanks for highlighting this. It never came to my mind to look this deep (as I normally deal with application layer keepalives where such tricks are technically impossible).
So actually the GRE keepalive request packet as such uses a normal combination of source and destination address, i.e. the same address tuple as a regular GRE packet carrying a payload. However, it carries a pre-cooked response to itself as its payload, in order that at the responding side, the regular processing of received GRE packets would be sufficient for the keepalive loop path to work. And this is what causes the trouble with the firewall - whereas the keepalive request is originated by the sending router itself, hence it is handled by the firewall chain out, at the responding router, the response is decapsulated from the received request just like any other payload. So the responding router does not originate the response but forwards it, the in-interface being the local end of the tunnel; nevertheless, the source address of the response is one of the own ones of that router. So it is not the firewall of the router where the keepalive functionality is activated but the firewall of the router at the keepalive responding end of the tunnel which causes the keepalive responses to never return to the sender of the requests if it isn’t set to permit forwarding of such “weird” packets.
Regarding GRE keepalives being useless if GRE is encrypted using IPsec, I have to disagree - it’s fine that we have the IPsec keepalives, but if the IPsec SA goes down, the GRE layer learns nothing about it, there is no alarm propagation from the IPsec layer to the GRE layer. So without GRE keepalives, a GRE interface won’t go down if the GRE packets cannot reach the remote router due to the outage of their carrying IPsec SA.
So where we do need to take an action when a GRE tunnel stops working, the use of GRE keepalives is necessary; to allow them to work, forwarding of GRE packets which arrive via GRE interfaces has to be permitted at the responding end. In RouterOS, this used to be handled by the chain=forward action=accept connection-state=established,related,untracked firewall rule which doesn’t care about interfaces, but as of now (6.45.7 while writing this), GRE handling by connection tracking is still totally broken after the fix addressing the GRE-related CVE (all new GRE packets seem to be marked as connection-state=invalid, and often but not always GRE exchanges never become tracked), so a dedicated rule needs to be used to permit the keepalive responses to be delivered.
If the remote end is not a RouterOS one, the same situation must be addressed using appropriate means.
Well, I normally use those GRE tunnels in combination with BGP for the routing, so that serves as yet another layer doing “keepalives”. On links where quick changeover is required (and there indeed are different paths) I use BFD in addition to that.
Under such conditions, having GRE keepalives as well is a bit superfluous.
When you use static routes and want some failover mechanism based on interface being down, indeed it can be good to make them operating and configure the appropriate firewall rules for that.
My comment is mainly intended to point out that enabling GRE keepalives may actually cause the link to fail (where it otherwise would work) depending on firewall and remote system.
Hi @yaomacbt
I’ve the same task in front of me - Gre over IPsec to private APN. Would you mind to post your config?
I’m completely newbie and couldn’t apply wiki example to my case.
BR,
noe123