I have a x86 router now running 6.44.3, it was running 42.x, remotely we have a mixture of MK routers but most of them are GR3's

We have 10 EoIP tunnels over L2Tp/IPSec vpn/bridge coming into that router. Every now and again one of the EoIP tunnels will drop. We can see traffic from both sides of the EoIP tunnel with torch but no traffic will cross it. The bridge local/remote addresses will ping across the link still. No amount of disabling or re-enabling will resolve the issue.

We added 2 EoIP tunnels Friday last and at that point we lost one of the established tunnels.

We have been rebooting the central router and that generally resolves the block. Monday night every time we rebooted the central router randomly one of the EoIP tunnels would not allow traffic. Every reboot a different EoIP tunnel stopped working. We upgraded to 6.44.3 during those reboots but it didn't resolve itself after the 6.44.3 install/reboot. It was rebooted more times after that.

In the end we disabled some none required VPN connections to other locations (not with EoIP tunnels) in case it was a limit wed hit. That appeared to resolve the issue, whether it was luck or not I dont know. We cant leave the tunnels down long as they are syncing disaster recovery servers and once they go out of sync they take days to come back meaning once we got it back we had to leave it and havent been able to add the disabled vpn's back

The x86 router is level 4 which doesnt appear to have any limits around 10 of any kind.

Can anyone think of a limit we might or hit or has anyone seen anything similar in there configurations.

Tim

I cannot suggest what is wrong with the EoIP tunnels, but if you have Mikrotiks at both ends of each tunnel, and unless you need VLANs to run through the tunnels and at the same time be tagged/untagged on the endpoint Mikrotiks, you can use the L2 tunneling capability of L2TP itself.

To do that, add the name of a local bridge interface as the value of the bridge parameter of the /ppp profile to which the /ppp secret (at HQ side) or /interface l2tp-client (at client side) refers. This way, L2TP will create a separate logical channel to forward L2 frames between the two bridges at the endpoint Mikrotiks. However, as said above, this method is incompatible with vlan-filtering=yes on any of the two interconnected bridges. Both tagged and tagless frames do pass through the tunnel if they come in through another slave port of the bridge, but without vlan-filtering=yes, the bridge cannot do tagging/untagging on any of its slave ports.

I have a x86 router now running 6.44.3, it was running 42.x, remotely we have a mixture of MK routers but most of them are GR3's

We have 10 EoIP tunnels over L2Tp/IPSec vpn/bridge coming into that router. Every now and again one of the EoIP tunnels will drop. We can see traffic from both sides of the EoIP tunnel with torch but no traffic will cross it. The bridge local/remote addresses will ping across the link still. No amount of disabling or re-enabling will resolve the issue.

Make sure you have an input chain firewall rule that allows GRE protocol from the IP at the other end. If you are missing this rule, EoIP may still work in some situations but will be unreliable (you would expect EoIP to not work at all if this rule is missing, but in fact it often does work partially).

I cannot suggest what is wrong with the EoIP tunnels, but if you have Mikrotiks at both ends of each tunnel, and unless you need VLANs to run through the tunnels and at the same time be tagged/untagged on the endpoint Mikrotiks, you can use the L2 tunneling capability of L2TP itself.

Thanks Sindy

Yes we do have vlans on the exit ports of the central router unfortunately to EoIP it has to be, thanks for your prompt reply however, very kind to comment.

Regards

Tim

I have a x86 router now running 6.44.3, it was running 42.x, remotely we have a mixture of MK routers but most of them are GR3's

We have 10 EoIP tunnels over L2Tp/IPSec vpn/bridge coming into that router. Every now and again one of the EoIP tunnels will drop. We can see traffic from both sides of the EoIP tunnel with torch but no traffic will cross it. The bridge local/remote addresses will ping across the link still. No amount of disabling or re-enabling will resolve the issue.

Make sure you have an input chain firewall rule that allows GRE protocol from the IP at the other end. If you are missing this rule, EoIP may still work in some situations but will be unreliable (you would expect EoIP to not work at all if this rule is missing, but in fact it often does work partially).

Thanks for your reply. Just to expand on that, you suggest creating a GRE input from the remote end bridge ip? or from a different ip on the router? I have just tried a GRE rule for the remote end bridge ip and I am getting traffic through that rule?

Regards

Tim

On each end, the input rule in firewall must accept protocol=gre packets from the address from which the opposite end sends the EoIP transport packets. But thinking of it, read also this post as your setup is very similar.

On each end, the input rule in firewall must accept protocol=gre packets from the address from which the opposite end sends the EoIP transport packets. But thinking of it, read also this post as your setup is very similar.

So still not 100% sure on the rule.

Head Office External - 1.1.1.1
Head Office Internal - 192.168.1.1
Head Office Bridge - 3.0.0.1

Remote Office 2.2.2.2
Remote Office Internal - 192.168.2.1
Remote Office Bridge - 3.0.0.2

Head Office GRE Rule allow from 2.2.2.2, 192.168.2.1 or 3.0.0.2?
Remote Office GRE Rule allow from 1.1.1.1, 192.168.1.1 or 3.0.0.1?

I currently am using 3.0.0.1 and 3.0.0.2 after this topic suggestion and am seeing traffic.

Tim

On each end, the input rule in firewall must accept protocol=gre packets from the address from which the opposite end sends the EoIP transport packets. But thinking of it, read also this post as your setup is very similar.

The seperate post of order of layers starting is always possible. Is the resoltuion for starting orders difficult? Could you expand on that?

Tim

On each end, the input rule in firewall must accept protocol=gre packets from the address from which the opposite end sends the EoIP transport packets. But thinking of it, read also this post as your setup is very similar.

So still not 100% sure on the rule.

Head Office External - 1.1.1.1
Head Office Internal - 192.168.1.1
Head Office Bridge - 3.0.0.1

Remote Office 2.2.2.2
Remote Office Internal - 192.168.2.1
Remote Office Bridge - 3.0.0.2

Head Office GRE Rule allow from 2.2.2.2, 192.168.2.1 or 3.0.0.2?
Remote Office GRE Rule allow from 1.1.1.1, 192.168.1.1 or 3.0.0.1?

I currently am using 3.0.0.1 and 3.0.0.2 after this topic suggestion and am seeing traffic.

Tim

Traffic over the L2 EoIP tunnel (3.0.0.1 to 3.0.0.2) doesn't pass through /ip firewall by default; youd'd have to set use-ip-firewall in /interface bridge settings to yes to force L2 frames through /ip firewall rules.

L2TP transport packets run between 1.1.1.1 and 2.2.2.2 so if the L2TP part is up, all necessary firewall rules for these IPs are fine too.

So what remains is the 192.168.1.1 and 192.168.2.1 between which the endpoint devices send the GRE packets transporting the EoIP payload via the L2TP PPP tunnel, but this is where the issue described in the other thread kicks in. If these GRE transport packets arrive with another source address than the one to which the local end sends them (the remote-address of /interface eoip), the input rule doesn't accept them, and even if it does, the EoIP stack ignores them.

Is the resoltuion for starting orders difficult? Could you expand on that?

I would start from adding a type=blackhole route with distance set to e.g. 20 and dst-address matching the remote-address of the /interface eoip. On the server side, a single route like this whose dst-address matches the whole /ip pool from which you assign addresses to the L2TP clients is sufficient. The sole purpose of these routes is to prevent the EoIP transport packets from being routed out the WAN until their "real" route becomes available and thus creating a tracked connection with src-nat treatment. As soon as the L2TP tunnel goes up, this blackhole route gets shadowed by the dynamically created "connected route" with distance=0 (if the EoIP's remote-address is the same like the IP assigned to the L2TP interface on the remote end) or distance=1 if it is a manually configured route to some other destination address which is up on the remote end.