EOIP Tunnel between two Mikrotiks, one is behind CGNat with VPN with Post Forwarding

Hello,

So I have the following situation. I am trying to establish an EOIP tunnel between two routers in two different countries. One is behind CGNat and I am utilizing PureVPN’s Dedicated IP and Port Forwarding service on it by connecting through IKEv2. I can log into it remotely through Winbox and I can ping the routers from one another. When I create an EOIP tunnel, there is no traffic going on between the two. Does anyone have any idea what the issue is and how I can configure an EOIP tunnel to get multicast IPTV between the two?

You need to allow GRE on the firewall. Probably IPSec ports too if you’re using that to encrypt your tunnel.

So on the one that is connected to the PureVPN, currently all ports are open. The other one has been added to the DMZ of my ISP router and has the GRE port open in the firewall

So both routers are NOT mikrotik, and neither has a public IP?

The thing is that GRE is not a port but a protocol (like UDP or TCP), and unlike TCP and UDP, it has no notion of ports, which means NATing it is more complicated and somewhat limited as compared to the protocols that use ports.

I know nothing about the PureVPN’s service, so I don’t know whether the public address is fully dedicated to you or whether you can use just some number of UDP/TCP ports. In any case, have a look at L2TP with BCP - it transports Ethernet frames using. UDP transport packets.

You only mention one of the routers to have a CGNAT address, which implies that the other one has a public one? If so, you don’t need the PureVPN at all, as the L2TP server can be listening on the router with public IP and the L2TP client can connect from the CGNAT one.

If you are running RouterOS 7, you can set up a Wireguard tunnel and use it to carry EoIP transport packets. I would not say it is simpler than L2TP+BCP but by experience it is simpler to configure Wireguard than IPsec, which you can use to carry EoIP transport packets already when running RouterOS 6. In either case, the setup would also not require the PureVPN service, as for both these encryption protocols it is enough that just one of the peers listens on a public address, and both use UDP as transport so they can be NATed.

Both routers are Mikrotik of course. Like I said, one has a dynamic IP but DDNS is enabled on it. The other one is behind an ISP Router with CGNat so to get around this I have PureVPN with a dedicated IP and port forwarding. I have an IKEv2 connection on the Mikrotik and I can confirm that I can connect to WInbox from WAN.

As I explained above, I have a dedicated IP (only mine) from PureVPN and I can control all ports. I got PureVPN with the intention of setting up an EoIP tunnel.

As far as Wireguard, I already have Wireguard to that location through another router but Wireguard is L3 and has packet losses which is bad for video streaming.

As I explained above, a port number is not the same like protocol number. So even if the PureVPN service does a 1:1 dstnat to the private address it assigns to your Mikrotik, it may still do that only for TCP and UDP and ignore GRE. You would have to use snifing (/tool sniffer quick ip-protocol=gre) to see whether the EoIP transport packets do reach the router via the PureVPN’s 1:1 dstnat.

BTW, the fact that the address is dedicated to you for incoming connections does not necessarily mean that it PureVPN does not use it to src-nat outgoing connections from their other clients at the same time, which might be one explanation of the assumed absence of GRE NATing.


Two points here:

  • if you have packet loss on Wireguard, you’ll have it on other protocols as well, unless one of your routers is in a dictature where ISPs are obliged to block or degrade VPN connections
  • to pass a GRE packet through a NATing device that does not support NATing of GRE, you have to encapsulate the GRE packet into an UDP or TCP one. So what I suggested was to use the Wireguard addresses as the local-address and remote-address on the /interface eoip rows.

Recommend skipping pureVPN since you have two MT routers and using a third party VPN to try some hack is a waste of time.

OPTIONS:

  1. Use Wireguard transparently to encrypt and run EOIP over it! Example → https://forum.mikrotik.com/viewtopic.php?p=990837#p990836

  2. Use Wireguard transparentlyy to encrypt and run L2TP over it! Example → https://forum.mikrotik.com/viewtopic.php?t=182340

Para 9 e.

Thank you both for the input, all good information.. I will ask PureVPN about this, because if it is the way you described it, then it is not worth paying for that service and I am within the 7 days of cancellation so I can cancel it.

As far as Wireguard, I will take a look at maybe setting that up.

I stumbled upon this… PPP + BCP bridge

https://mum.mikrotik.com/presentations/KH17/presentation_4192_1493374138.pdf

Take a look at the second part of the PDF.. it seems that it does not need a public IP on both sides, which would be perfect and it would be L2. Do you think it would work in my case?

For all VPN protocols supported by Mikrotik, it is enough that just one end of the link has a public IP address, or at least that you can set up port forwarding from a public IP address to that Mikrotik. Out of them, three use UDP as transport - IPsec, Wireguard, and L2TP. OpenVPN in ROS 7.x can use UDP as well but the forum keeps reporting issues with that. Using TCP as VPN transport is not a good idea in general, using GRE is even worse, for different reasons.

L2TP has its own encryption but it has long been considered too weak to really protect anything, and there is no way how the client could verify the authenticity of the server, so MITM attacks are ridiculously easy. So if encryption matters to you, you have to use IPsec or Wireguard as an encryption layer for L2TP. L2TP has its own mechanism of L2 tunneling (the BCP) which has some advantages and some disadvantages as compared to EoIP or VxLAN. The transport packets of all three (L2TP, EoIP, VxLAN) can be encrypted using IPsec or Wireguard, but only L2TP can be set to split large payload packets into multiple transport ones so that the transport ones would not require fragmentation, which too often causes issues because many networks drop non-first fragments. So L2TP with BCP and MLPPP configured with transport packet size limit adjusted to the MTU of the path between the client and the server seems to provide the smoothest experience.