Ultra-cheap 3g/4g dongle for VPN connection?

Hi all, I’ve returned with more self-inflicted network problems…

I am happy with my network, but I would really like to be able to log into it when I’m out-and-about. Obviously this calls for some kind of public ip address, maybe some DDNS entries, and an OpenVPN configuration, but here’s the issue: My home network router is behind another router, and that router in turn is the one with the public IP address.

So here’s what I was thinking - the current topology is as shown below:

What if, I could add an ultra-cheap, ultra-lame 3g/4g dongle, exclusively for incoming VPN connections? I.e. when I am at my workstation physically, all traffic gets routed through the normal fast terrestrial connection, via the external router.

And if I am somewhere physically outside, I can create a VPN connection, open an SSH session, and obviously that will use up very little bandwidth - whatever is used by me typing characters, and receiving compilation failures via TTY. But while I’m SSH’d in, if I say do wget <whatever>, that wget will get routed as-usual via the fast terrestrial connection. Illustration (if it makes sense):

Anyone have any thoughts on such a setup? The only issue I can see is that these modem providers often NAT the dongle itself, so I’d be back to square one with regards to a public-addressable IP address for the VPN step. But otherwise, the only thing is finding a super-cheap solution, i’m talking probably 1GB/month type deal. if they cost the same as more expensive 3g/4g modems, i might aswell just get a “real” 3g/4g router, and use that as my upstream connection in general.

Mikrotik supports zerotier natively now. Maybe that would work for you?

Oh that looks super interesting, thanks for throwing that out! will definitely investigate

1 Like

I think the 3g/4g dongle will not give you a public IP, but all be behind GCNAT, unless you can find a cell carrier that will give you a public IP, even then it will not likely be static. Assuming that’s why you wanted to 3G dongle to try and get around if my understanding is correct.

I have never heard of zerotier, but there are peer-peer VPN solutions or you can create your own VPN and put it on a 5USD/mo VPS from amazon or linode.

Sprint was giving customers public IPv4 addresses, albeit dynamic ones which changed very frequently. They were probably the only US carrier to do so. You can get a public and even static IPv4 from other carriers with a business service and high fees for the setup process. Most cellular carriers will give you a public IPv6 address, however, and you could use that instead, along with a Dynamic DNS setup.

Some VPN software will tolerate the double-NAT and allow you to connect over a couple port-forwards, assuming you can set that up on your ISP router. Then you wouldn’t need an LTE hotspot. SSH will work, but performance is not great. ocserv works better, and has clients for most any platform out there.

  • Who is your ISP? They might offer a “static IP” add-on service. This is generally cheaper than a VPN and overall generally more efficient. It might mean that instead of 20 a month you pay 25 or instead of 60 you pay 75. Sometimes they have a business support tier.

  • Tailscale can traverse nat on both sides. TLDR if any of the two two endpoints ends up assigning a fixed UDP port/IP to your client so it can be reused for multiple connections even if only temporarily, then Tailscale can detect that and coordinate encrypted traffic between your two peers such that it uses that mapping, as it basically represents a forwarded port. (for comparison, Tailscale just uses Wireguard underneath). If the above doesn’t work out, Tailscale the company will relay your traffic. I hear zerotier can punch nats as well, but I don’t know enough about it to trust it. In comparison, Tailscale the company publishes their client on GitHub, you can build it and just it if you don’t want to use their release.

  • If you want to have a multi-homed router and want to ensure “reply packets” go through the “correct” interface where “request” packets came from, the canonical solution for Mikrotik is to use “mark-connection” firewall action and route packets based on connection marks. In basic Linux iptables, this is done with a couple of explicit connection tracking rules. (should be documented on lartc if I recall, it’s not a new thing)