EOIP Tunnels, only tunnel id = 0 works - Fastpath allows pings (3 - RB953GS-5HnT)

Hello,

I am trying to connect two remote sites to a home site using EOIP Tunnels so that they are all on the same L2 network. I have setup an EOIP tunnel between site 1(home) and site 2 using tunnel id = 0 , and site 1 to site 3 is using tunnel id = 1. Site 1 distributes DHCP to remote sites and acts as internet gateway.

The Problem: Tunnel id 0 will pass everything as it should, but anything other than 0 (1, 2, 12…) does not pass anything. However, if you enable Fast Path then id 1, 2… will pass dhcp and will ping but it will not allow you to connect to any websites through the tunnel ( using site 1 as the gateway).

If I swap tunnel ids between site tunnels then site 3 works ( with id 0) and site 2 does not ( with id 1).

Mikrotik support what am i missing or is this a bug?

I am running the latest routeros and have tried the lastest beta as well

thanks,

I have the same problem. So must be a BUG.

If you enable Fastpath you bypass firewall. so if it is working most likely it is configuration problem in the firewall.

I have tried a couple of firmware versions 6.29.1 and 6.33.2 and the problem is the same.
Only then ID 0 is used its possible to get traffic thru.

In Firmware 6.29.1 the FastPath option is not possible and there its also only works with TunnelID 0.

In 6.33.2 it also only works with TunnelID 0.
I have tried just win entering the Remote Address, and also with both the Remote Address and Local Address.
I have also tried with an without a IPsec Secret.
But with a IPsec Secret FastPath cant be enabled.

But the results are the same its only working with TunnelID set to 0.

Witch is a big problem for our setup because we need a connection out to at least 10 locations and that must me made with eoip since its must support multicast.

I found that one of the default firewall rules was blocking traffic on anything other than id=0. disable your firewall rules one by one until you find it. hope that helps

Can’t you use tunnel id 0 on both tunnels?

I can confirm it works by disabling a filter rule.

For me it was the default rule
/ip firewall filter add action=drop chain=input comment=“default configuration” in-interafce=ether1-gateway

But then the next question is what rule do i have to make to allow the eoip tunnel to work because i assume that that filter rule must be important to secure the firewall.

I can confirm that eoip tunnels with an id greater than 0 starts working after disabling this rule:

;;; default configuration
chain=input action=drop in-interface=ether1-gateway log=no log-prefix=“”

If I re-enable the rule the tunnel still has an “R” next to it (even after disabling and enabling the tunnel) so I’m not sure what’s going on here.

Since the eoip info is by definition inside an IP packet (and therefore not in the IP layer), why is the firewall bothering with it?

Someone should explain why this isn’t a bug I think.

Hi. I have the same problem. Firmware 6.47.6
If. tunnel id=0 work if tunnel id=1 interface don’t run.
I can’t find in firewall line chain=input action=drop in-interface=ether1-gateway log=no log-prefix=“” .
Maybe you decide this problem in last firmware ?
What me do for fix this bug.
Big Thanks/

Disable rule - defconf: drop all not coming from LAN
after that everything will work

Yes, everything will work, including access for all malware. Don’t do that. Use a selective rule only allowing what you really need to allow.
I love this kind of advice to break the firewall completely rather than finding out what is actually wrong. The actual solution has been posted several times here.

Where is the solution? this bug is still not solved

For example here (by @simveck).

Instead of allowing all the garbage from anywhere (which is what happens if you disable the “drop whatever doesn’t come from LAN” rule), you selectively allow only GRE and only from the peer IP.

The actual issue with tunnel-id different from 0 seems to be that EoIP misuses the optional GRE header tunnel ID field, as it only uses two bytes for the actual tunnel ID and the other two bytes for frame size (which changes). This confuses the connection tracking, so it doesn’t see the received EoIP packets as part of an existing connection created by the outgoing packets of the same EoIP tunnel. In fact I don’t get why it is not a problem for tunnel-id 0.

In the default firewall setup, packets belonging to already known connections are allowed by the “accept established” rule at the top of the chain. But this rule doesn’t match for incoming EoIP packets for the reason explained above, so the selective accept rule is necessary.

Also, unless both ends of the EoIP tunnel are configured to send keepalive packets, the rule above must be added to firewalls of both peers even if tunnel-id 0 is used, because without the keepalives, a payload packet from one end of the tunnel must reach the other end of the tunnel so that a response packet could be sent. So if none of the peers accepts the first incoming packet, the tracked connection will never establish on either of them.

thanks thanks. allow GRE its work