Hello,
I want to set up a GRE Tunnel with my hap ac3 LTE. I’m used to set up GRE tunnels with mikrotiks that has a WAN IP from normal ISP Internet, but now i’m using a 4G network.
I have internet on my router, did the GRE tunnel settings but it is not running. My question is if it is possible to run a GRE tunnel with a 4G network.
GRE or EoIP Tunnels can get complicated to a degree. I’ve given up on them and am using SSTP tunnels and “Binding SSTP Server” interfaces. Much more reliable going through the public internet and still am able to pass my multicast traffic without a problem.
-tp
Someone who hasn’t give up on GRE please 
Pack the GRE into IPsec. This will make it look like UDP from the outside, so the mobile operator will be able to NAT it, and from inside you’ll still have the GRE (with an even smaller MTU). You can use null encryption in order to save resources, as you didn’t care about encryption anyway.
Do you have a public IP on the LTE interface? And if you do, is it even accessible from the outside? I’ve seen mobile operators assigning public IPs to LTE devices but NATing them to other public IPs anyway.
And I’ve seen mobile operators assigning public IP addresses to LTE devices and not doing any NAT, but still running firewall and DPI systems on behalf of their users.
I have a public IP but i cannot acces the router, not even with the DDns. I think thats where the problem starts
Another problem is that (at least in RouterOS) for GRE you need to have a static peer address, and your LTE device likely has a dynamic address.
When you want a hub-and-spoke VPN where the hub is on a fixed address and spokes have dynamic addresses, GRE is not very convenient.
GRE/IPsec could be a little better, but unfortunately in RouterOS it is not exactly easy either. It lacks the capability to call a script upon IPsec establishment so the GRE endpoint address can be set accordingly. That would have to be done in a scheduled script (instead of event-driven).
I guess a better option for you is L2TP (best over IPsec). As sindy already wrote, there is more chance that those UDP-encapsulated protocols work over mobile operator’s networks, and it is a better option than SSTP or OpenVPN (which are TCP based, RouterOS does not support OpenVPN over UDP in 6.x).
Sounds like that. And as GRE doesn’t have the notion of port like TCP or UDP, it cannot be handled by NATs, so the mobile ISPs often block it completely.
So you need one device on a public IP, which will act as a “server”, to which the hAP ac³ will be connecting as a “client”. The IPsec configuration generated automatically if you specify the ipsec-secret field is not suitable for the purpose, as you need that the “server” side doesn’t act as an IPsec initiator because it doesn’t know the other peer’s address, and as it creates a transport mode policy whilst you may need a tunnel one. And if you want to use null encryption (no point in doing so on hAP ac³ which supports encryption in hardware, but I don’t know the capabilities of the other device nor the legislation in your country), the default proposal used to dynamically generate the policy is also not suitable.
So all in all, you need to manually set up a peer accepting connections from anywhere and not initiating any at the device with a public IP accessible from outside, and an initiator peer on the hAP ac³. It may work with a transport mode policy and the local-address of the GRE tunnel at hAP ac³ linked to the LTE WAN IP, but if the IP changes over time, you may be better off with using a tunnel mode policy and a static private IP at the hAP ac³ end; at the other end the public IP may be used. The GRE tunnel will then be configured between the private IP at the hAP ac³ end and the public one at the other end.
However, there is a catch - if there is actually no NAT between the LTE WAN and the internet, the IPsec would use ESP for transport, which is often treated equally bad like GRE by mobile operators. If it is the case, you need to link also the IPsec peer at the hAP ac³ end to the private IP, forcing NAT into the path between the peers this way. This will make the ESP get encapsulated into UDP, which must be treated properly by the ISP, as otherwise almost nothing would work.
I understand you completely.
Let me try and explain exactly what I want to do.
At my company we use GRE tunnel between to mikrotiks with a static WAN IP. One mikrotik is placed in our server room and the other in a building we manage. This works well as they have both a Public IP address.
Sometimes we have projects were we do not have a Public IP or internet connection yet. So we thought about using a LTE connection router.
You recommended me using L2TP over IPsec, but now you know a little bit the situation, do you maybe have other recommandations?
Yup, had this with a customer of mine in Malawi, they were using public IPs belonging to some company in USA but NATed the connection out to another rage on way out
Well, that is not really correct. GRE can be handled by NAT, and often on consumer NAT devices it sort of works, but as it does not get the testing coverage
of TCP and UDP there often are subtle bugs.
And of course it can only work when the first GRE packet is sent by the device behind the NAT, so the packet from the other side can be treated as a reply.
As there are no port numbers, the address of the server has to be unique, i.e. only one system behind the same NAT can connect to each server.
(there is an additional ID field in the GRE header but RouterOS cannot set it)
I use L2TP/IPsec in similar situations: a GRE tunnel exists between buildings and is over fiber or DSL, and we have an LTE stick at the subsidiaries that uses L2TP/IPsec to connect to the main office as a backup. This does not require a static address, just the standard dynamic (and nonpublic) address received from an LTE provider and running over their CGNAT.
This works, but there is a restriction: there can be only a single client behind the same NAT, so when you have some of those projects running and you always use the same LTE provider you have the risk they are behind the same CGNAT and it won’t work.
However, we have multiple IP addresses on the server side (2 /29 networks on internet) so we can work around that by using different server addresses for a couple of clients.