Using DietPi as VPN Gateway but leave DietPi services (Nextcloud, Jellyfin, Gitea ...) reachable via domain

General Discussion
1

Hi guys,

I want to use my DietPi Odroid N2+ to use as a VPN Gateway to ProtonVPN for all my Devices in my homenetwork. At the same time i want to leave my services (Nextcloud, Jellyfin, Gitea - also a static hosted website over nginx) publicly reachable over my custom domain.

How can i do that?

2

I guess you need to setup split tunnel using iptables to exclude some traffic from VPN. There should be a couple of topics on our forum already.

3

Hello,

Currently I have the WAN-gateway of my home network set to the Odroid. So all the traffic of my home network goes through the Odroid. I also have a Wireguard client set up that connects to ProtonVPN and routes all my home network traffic through the tunnel.

But I don’t know how to exclude Nextcloud, for example, which sits behind an nginx reverse proxy, from being tunneled through the VPN. I also host Homer as a publicly accessible home page and when the VPN is connected, I can no longer reach homer and all other the services through my domain.

Unfortunately I don’t know anything about iptables and all the network stuff in Linux. I have tried many different tutorials but have never been successful.

Thanks

4

Can anybody help me with that?

5

You can only exclude domains in wireguard from being tunneled, not domains. You would need policy based routing like it’s featured in OpenWRT.

But I don’t understand why you wouldn’t reach your homepage when the VPN is connected. It cant resolve the domain, then the DNS inside the ProtonVPN tunnel has a problem. Is it a DynDDNS domain?

You could maybe set a local DNS record with dnsmasq, which redirects the requests from your domain to the local IP of the homer device instead of pointing to your public IP.

6

@Jappe

Main problem is, as soon as you active ProtonVPN, whole traffic from DietPi device is forced inside the VPN tunnel. Means, you try to reach the system on way A but the system is pushing the answer back thru the VPN tunnel on a completely different way B. For the requesting client this doesn’t match :slight_smile: Therefore you need to exclude traffic from VPN tunnel, to be able to get answer back on the same way A :wink:

I know my answer is technically not 100% accurate but should be understandable.

7

Ok I understand now, everything is routed through the tunnel interface.
So a split tunnel would be needed, to only route traffic comming from the LAN throug the VPN or you force the wanted services you want to still listen to eth0 instead of the tunnel interface?

Here is some stackexchange thread with some ip-table rules and a long explenation what they do in detail. Basically it’s policy-based-routing where every traffic from and to the given local IP is routed through eth0 and bypassed the tunnel interface. You would need to tweak these rules to bypass incoming conections from public IPs (users who want to access the webserver) I think.

This is not an exact solution for your problem but a start to build on.