Make homeserver available both on LAN and internet with cgnat. Routing?

Hardware Hub Networking
, ,
1

I have a problem concerning configuration and routing on a reverse proxy that is connected to my local network and via WireGuard VPN to a gateway to the internet. Let me explain:

My home network 192,168,178,0/24 is connected to the internet through carrier grade nat. So my “public” ipv4 is shared with many other users and cannot be used for incoming connections to my nextcloud home server over the internet. My ISP dislikes home servers so much, even my IPv6 prefix changes every 24 hours. I did find a solution for that (do[dot]de does dynamic dns for ipv6 as an included service if you have a domain with them) but I am regularly on networks which support only ipv4. That’s why I am currently working on a different solution to be able to connect via ipv4.

The easiest thing would be to dig a tunnel through the CGNAT to a vps with a public ipv4. But that way I would always - even on my LAN - connect to my nextcloud home server through the internet using the slow upload of my internet connection (only 30Mbit). So this is not a good option. I already have a reverse proxy on my LAN and I want to configure it in a way that it can accept connections from both my LAN and the internet via a WireGuard VPN connections to my vps. I do have a an idea of the setup I want, so let me try to sketch what I am thinking.

[WAN] -–(https)--> [(eth0)-WG-gateway-(wg0)] --> \\
                                        [(eth0)/(wg0)-localRP-(eth0)] --> [NCServer]
[LAN] -------(https)---------------------> //

[NCServer]: My Nextcloud server, running in my LAN: 192,168,178,55

[localRP]: Reverse Proxy running in my LAN: eth0 (192,168,178,50) currently providing SSL certificates for my nextcloud. Needs to accept incoming requests over wg0 and eth0 interfaces and pass them on to [NCServer]. Planned: WireGuard client, connecting to WG-gateway: wg0 (10,8,0,3) (wg0)

[WG-gateway]: virtual server running WireGuard VPN server and nginx reverse proxy server. Public interface: eth0 (some.public.ip.4), WireGuard interface: wg0 (10,8,0,1). Plan: reverse proxy passthrough to upstream reverse proxy in my LAN [localRP] on interface wg0 (10,8,0,3).

In this setup, my domain points to my vps (WG-gateway) which has a static public ipv4. Incoming https-traffic would be passed on to a connected WireGuard client that sits on my LAN [localRP] (10,8,0,3) via a passthrough reverse-proxy. The [localRP] still has the SSL certificates and forwards incoming requests to the nextcloud server.

I believe I can manage to set up and configure most of the plan. Where I am struggling: How do I configure my local reverse proxy routing in such a way that it connects to [WG-gateway] and still accepts incoming https-connections both on wg0 and eth0 and forwards them all to 192,168,178,55? Is there even hope of this working? I don’t really understand routing yet. Help is much appreciated!

2

I’m in IT, so I must avoid answering your direct question, and toss out another question. This is because IT people suck. It’s a social disfunction that hinders many.

Will the isp allow you to pay them an extra $10 for a static public IP which would allow you to avoid all the hard-to-troubleshoot gotchyas of CGnat?

This is what I did because even when I managed to expose my services through a double nat, I still couldn’t browse to 2 of my banking websites and my kids were unhappy that they couldn’t use their consoles very well. Maybe things have changed and I should revisit that extra $10 a month.

So yeah, totally avoided your question.

2 Likes
3

That was my first question to my ISP, if they offer a static ip4 as an option. They do not. Not even a static ipv6 prefix.
I can’t really tell how much of websites not functioning correctly has to do with my ISP or maybe more with my other network quirks (pihole DNS, javascript disabled for all but domain of visited website, cookie autodelete after 20 seconds, rejection of all third party cookies, skipping redirects, cutting referrers and so on). So I can’t really give any advice on how well cgnat works nowadays, sorry :wink:

4

(51) Self-Hosted VPN With Wireguard + Linode! - YouTube

1 Like
5

Thanks, that video is covering the very basics of wireguard, which I do not need help with. As far as I can see, it does not cover client configuration at all. The timestamp covers basic settings on the server, not the client. Sorry, I fail to understand how this helps the client-side integration on my local network.

6

How about something like a cloudflare tunnel? :thinking:

Here’s some basic info & how to set it up:

1 Like
7

This is 100% the first approach I would take on solving for this. Setup the Cloudflare tunnel for external access and then do a DNS override on your LAN and point it to the local proxy to keep the traffic local.

If there are issues using Cloudflare (too exposed, doesn’t work, etc.) and you have control over the external clients, then my fallback would be something like ZeroTier or TailScale and routing to your reverse proxy LAN IP. Both products can expose your LAN via an exit node (TailScale) or a NAT masquerade (ZeroTier) to your remote clients. A quick glance shows TailScale has a DNS server integrated with the product, while ZeroTier requires workarounds.

2 Likes
8

ZeroTier was another option I was thinking of, I just couldn’t remember the name :sweat_smile:

9

Thank you guys. Exposing the server to the internet is not the problem. Doing it in a way that I can still access it with full 2.5GBit/s when at home while still having someone else able to connect to it over the internet at the same time, that is the goal and the challenge. I want to do it with as few third party services as possible, so I can learn the most. Definitely no cloudflare. Zerotier looks interesting and I may want to play with it for a different project, but it is still a black box with an app. Not my goal here.

10

Your problem is the dynamic IP address for doing it all yourself…
These larger companies have figured out ways to circumvent that by some very clever networking methods. But reproducing that yourself is something you’re not capable off. Else I suspect that you wouldn’t be asking for help with just that :sweat_smile:

Therefore, I think that in this case you’re better off picking the “black box” which suits your needs the most.
I took a look at both for my own situation but ended up going for WireGuard instead. My advantage is having fixed IPv4 & v6 address.

I found another thing you could try… it is another “black box”, but it does give you a lot of control. And you can use it for free if you only have very few users connecting to it:

Though if I were you, I’d probably go with ZeroTier :thinking:

2 Likes
11

Would tail scale not help with this? Especially with a changing IP?

12

Would work, has been mentioned as well :thinking:

1 Like
13

I now see lakonius suggested it. (Thanks)

OP looks smart enough to set up pretty much headscale instead, and control the whole stack

2 Likes
14

Well, I have to admit, that logic is sound. But since I do seem to like my networking to cause pain, I’m still gonna try with reverse proxies and WireGuard first and then headscale (thanks @Trooper_ish !) before taking a closer look at ZeroTier.
It feels fantastic to be made aware of all these service. Thank you for that everyone!

2 Likes
15

Don’t forget to toss out an update once you have things working. I’d love to hear how it turns out.

1 Like
16

Cloudflare Tunnel is the way to go. LAN clients connect to the local IP address as usual. WAN clients connect to a public Cloudflare address without any special software. Additionally, you can setup additional authentication on Cloudflare to avoid anonymous traffic from reaching your server’s login page, protecting your from DDoS attacks and exploits on the server software.

Cloudflare tunnel is not like a VPN. It doesn’t route all traffic from the host. It allows Cloudflare to connect to servers inside your network, and expose them in a safe way through Cloudflare’s public infrastructure.

1 Like
17

I think that what you want to do is possible with wireguard and sone dns setup. Use an A record as the entrypoint in your wg config and resolve it to 192.168.xxx.xxx on the home network and to your vps when on the public internet.

On second thought dns trickery may not be needed. You can specify a routing table in the wireguard config, and have both your vps and local server as Peers (entrypoints). By setting AllowedIP properly wg should be able to figure out which hosts are accessible from which entrypoint.

The only drawback is that you‘ll still tunnel local traffic, at expense of some cou load.