I’m trying to establish a gre6 connection between 2 routers on the internet. I couldn’t get it working. So I tested 2 routers on my local network which are inside the same ipv6 subnet, and I still can’t get it working. I disabled the /ipv6 firewall filter rule that disables traffic on the input chain completely, even added a rule to allow gre and it still doesn’t work.
gre using ipv4 works fine between the same routers.
Am I missing something? Is anyone else using gre6 on 6.46.6? I know this worked at one point because I’ve used it before between routers across the internet.
Just to be complete, I did do a packet sniffer trace for gre packets and I saw traffic going both ways once I enabled the gre6 interface. But the link never gets established, which makes me think this is bug somehow. Or I’m missing something.
I should say I always disable the keepalive at gre level (both on v4 and v6) as it provides me with no extra function as I always run BGP and often even BFD over the links.
Maybe keepalive does not work with gre6? Without keepalive the link of course is always up and running once it is enabled (i.e. the router has no way of knowing if it isn’t).
I gave it a try on 6.45.7, and first of all, I couldn’t find out how to disable keepalive on /interface gre6.
Next, I can see by sniffing on a hAP ac lite that the GRE keepalive packet gets unpacked from the tunnel, but no firewall rule can see it (raw/mangle/filter), and the hAP ac² on the other end keeps seeing the tunnel down, regardless whether there are any ipv6 firewall rules on the hAP ac lite or not; on the other hand, the hAP ac lite keeps seeing the tunnel as Running although even sniffing at the hAP ac² doesn’t show the keepalive packet to be received. So it is definitely rotten multiple ways.
Just click the up-arrow right of the fields that show interval and count.
In a /export it shows up as !keepalive
Keepalive is troublesome even on IPv4, it is probably a MikroTik patch compatible with some other router product, native Linux does not support it.
The way this works is a bit strange, it sends a tunneled packet to the other side that would normally be sent in the other direction (due to src and dst address) and the other side duefully routes it the other direction and it is received back.
Of course this causes conflicts in many secure configurations…
Hm, I am pretty sure I’ve tried /interface gre6 unset 0 keepalive before, but there must have been a typo. Now it worked (and set !keepalive works too).
And after all the issue on my side was that broken firewall security patch for GRE, which marks input GRE packets as connection-state=invalid also in IPv6 firewall. Again, I was pretty sure that I have added protocol=!gre to the chain=input connection-state=invalid action=drop rule in /ipv6 firewall filter, but I obviously haven’t. So now it works even with keepalive enabled.
So acruhl, the above may be the issue in your case as well (the received GRE packet being dropped by the “drop invalid” rule before reaching the “allow gre from xxx” rule, despite the fact that GRE packets to the remote IP are being sent so connection-state=established should handle the incoming ones).
Yes, you have to add a forward filter rule action=accept in-interface-list=all-gre protocol=gre action=accept (or something more restrictive) if you need to use the keepalives.
However, what I can see with the hAP ac lite is that the keepalive packet emerges from the tunnel according to the sniffer, the firewall doesn’t log it, nor does the sniffer show it to be leaving through any interface, but the sniffer at the hAP ac² shows it to arrive; on the hAP ac², the sniffer shows the keepalive packet from the hAP ac lite to come and leave properly. So there is still something else rotten, on top of the wrong marking of GRE packets as connection-state=invalid.