Can't make app VPN protection work

[nebulon]

So then lets do one more test. If you run host <protected app domain> while being disconnected from the VPN, you should see the server's public IP. Then connect to the VPN and run the host command once more and then you should see the VPN network so for exampls 100.64.0.1

[bazinga]

In both cases the command returns server's public IP.

I am routing all desktop's traffic through the VPN tunnel on my router - every "what is my IP" page I can find online shows my server's public IP, logging into my Nextcloud (on same Cloudron instance) resulted in an email notification saying I've logged in from a new location (with the server's IP address), Event Log entries in Cloudron show server's IP address in "Source IP" attribute.

[bazinga]

This post is deleted!

[bazinga]

This post is deleted!

[nebulon]

@bazinga yes those "whats my ip" pages are correct but that is not the issue. Externally your connection would have your server's public IP.

However, for the VPN protected app on your Cloudron they have to go locally directly between the containers on your server itself, so the public server IP is not the incoming one. Since the host commands in both cases return the public IP, there is something wrong with the DNS resolving. I don't know your exact setup there, but when connecting to the VPN it would change the IPs returned for VPN protected domains to have the 100.64.* ones to the connection does exactly not go via the public route.

Do you have any special or custom DNS configs set on your laptop or a custom DNS server which overwrites your domains?

[bazinga]

@nebulon Thanks for getting back to me yet again. Nothing custom, I do use DoT on my OpenWRT router, but that's all.

With that said, after many hours of debugging and trying many different configurations, I seem to finally be able to access VPN protected apps without any hacks. Took me a while to discover 100.64.* subnet along with other things.

The issue occurs because Cloudron’s per-app VPN protection verifies access by evaluating the client's source IP at the Nginx reverse-proxy level, which breaks when a central network router acts as a gateway and enforces NAT masquerading (Double-NAT).

The solution that worked for me is to implement Split-Horizon DNS at the router level, forwarding the app's domain queries directly to Cloudron’s internal VPN DNS relay (seems to be 10.9.0.1 in my case), which allows traffic to ingress securely via the native WireGuard network interface layer without tampering with the original client packet structure. To make this work seamlessly, users must also ensure individual client devices do not bypass the router's DNS via encrypted Secure DNS features (DNS-over-HTTPS).

Below I'll share the steps required to setup a router so that multiple devices are able to access these protected apps without needing to have VPN connection on each.

One question: why did you guys opt for this VPN protection vs simply allowing users to define a white list of source IPs or domains from where the access would be allowed? Would be much simpler and not require the VPN hassle (no matter on an endpoint or a router).

[bazinga]

Blueprint: Full Split-Tunnel Router-Level VPN for Cloudron Protected Apps (OpenWrt/GL.iNet)

This guide allows all devices on your home network to access Cloudron apps protected by per-app VPN restrictions without running VPN clients on individual machines. It establishes a split-tunnel: your household traffic uses your regular high-speed home internet (maintaining your local ISP IP), while only your Cloudron app traffic securely traverses the WireGuard tunnel.

Configuration Values Used:

• App Domains: my-app.domain.net
• Cloudron VPN Server IP (DNS Relay): 10.9.0.1

Step 1: OpenWrt WireGuard Interface Configuration

Create a new Wireguard interface (Network -> Interfaces) named wg_cloudron (or any other name) and configure it based on the .conf file downloaded from the VPN applicaiton for a device created for the router.

When creating the interface ensure the following is set:

• Allowed IPs (Peers Tab): 0.0.0.0/0
• Route Allowed IPs (Peers Tab): ENABLED (Checked)
• No Host Routes (General Setup Tab): ENABLED (Checked) (Prevents WireGuard from hijacking your home internet gateway).
• Use Default Gateway (Advanced Settings Tab): ENABLED (Checked)
• Use Gateway Metric (Advanced Settings Tab): 99 (Lowers tunnel priority below your standard WAN).

Step 2: Configure Split-Horizon DNS Forwarding

Force your router to resolve your app via Cloudron’s internal VPN DNS relay instead of the public internet.

• Navigate to LuCI ➔ Network ➔ DHCP and DNS.
• In the DNS Forwardings box, add your app lookup rules pointing to the tunnel gateway:

/my-app.domain.net/10.9.0.1

• Click Save & Apply.
• CRUCIAL: In your main router/GL.iNet panel under DNS settings, turn OFF "DNS Rebinding Attack Protection", or it will block these private internal lookups.

Step 3: Add Interface Static Routes

Because "No Host routes" is active, you must give the router a manual map to find the tunnel networks.

• Navigate to LuCI ➔ Network ➔ Static Routes ➔ Static IPv4 Routes screen and add two routes:
  • Route 1 (Tunnel Subnet): Interface: wg_cloudron | Target: 10.9.0.0 | Netmask: 255.255.255.0
  • Route 2 (Cloudron CGNAT Mesh): Interface: wg_cloudron | Target: 100.64.0.0 | Netmask: 255.192.0.0
• Click Save & Apply.

Step 4: Configure Policy-Based Routing (PBR)

Tell your routing engine (e.g., vpn-policy-routing) to capture the specific app domains and throw them down the tunnel interface.

• Navigate to your PBR rules and create a policy for your home network:
  • Source Address: Leave blank (applies to all household devices automatically) OR a specific device IP (just for one device).
  • Remote addresses / domains: my-app.domain.net (and more domains for other "protected" apps if you have them).
  • Interface: Select your Cloudron WireGuard Interface (wg_cloudron).
• Click Save & Apply.

Step 5: Disable Browser/Client Encrypted DNS (Leaks)

If any specific machine fails to connect, its operating system or browser is likely using a secure public DNS proxy that bypasses your router.

• In Firefox/Chrome Settings: Search for "Secure DNS" or "DNS-over-HTTPS (DoH)" and turn it OFF.
• Flush Cache: Run ipconfig /flushdns (Windows) or sudo resolvectl flush-caches (Linux) and test using an incognito window.

Troubleshooting: What if your Cloudron uses a different internal IP range?

While 100.64.0.0/10 is the standard Carrier-Grade NAT (CGNAT) block often utilized by private overlay networks, Cloudron or your specific container configuration might serve your apps on a different internal subnet block (such as a standard Docker 172.x.x.x range). If you completed the guide but your browser still spins or returns an error, use the quick check below to identify your exact internal network address.

Find your App's Real Internal IP

Open a terminal or command prompt on a connected client machine and run a network lookup on your app domain:

nslookup my-app.domain.net

Look at the Address line in the output - if it does not start with 100.64.x.x, note down whatever private IP address is returned (e.g., 172.18.16.137).

Update the Static Route to Match

If the lookup returned an IP outside the 100.64.x.x range, you must adjust Step 3 (Route 2) inside your router settings to match your actual subnet architecture:

• If your IP looks like 172.18.x.x:
  • Go to LuCI ➔ Network ➔ Static Routes.
  • Update Route 2 to: Target: 172.16.0.0 | Netmask: 255.240.0.0 (This covers the entire private Docker 172.16.0.0 through 172.31.255.255 address spectrum).
• If your IP looks like 10.x.x.x (and is distinct from your home/VPN subnets):
  • Update Route 2 to: Target: 10.0.0.0 | Netmask: 255.0.0.0.

Once your static route aligns with the IP returned by your Split-Horizon DNS, your policy rules will immediately lock on and stabilize the tunnel stream.

[bazinga]

Extension: Supporting Inbound Proxies (Xray / 3X-UI) to access VPN protected apps

If you are running an inbound proxy server (like Xray via a 3X-UI panel) that connects to your OpenWrt router (e.g., as a client on an inbound wgserver tunnel like 10.4.0.3), Xray will naturally try to use its own application-layer routing and public DNS. This bypasses the router's PBR engine and triggers the "VPN connection required" block. To fix this, you must instruct Xray to natively map your Cloudron domains directly to the internal CGNAT/Docker IP address that your router's PBR engine is already intercepting.

Step 1: Update the Xray DNS Config Template (3X-UI)

1. Log into your 3X-UI panel and confirm DNS is enabled (Xray Configs -> DNS tab)
2. Navigate to Xray Configs -> Advanced tab (or your core JSON configuration template).
3. Locate the "dns" configuration block.
4. Manually add a "hosts" mapping block right above your "servers" array, explicitly binding your app domains to the routed internal Cloudron IP (100.64.0.1):

"dns": {
    "hosts": {
      "my-app.domain.net": "100.64.0.1",
      "my-other-app.domain.net": "100.64.0.1"
    },
    "servers": [
      {
        "address": "localhost",
        "port": 53,
        "skipFallback": true
      },
      {
        "address": "1.1.1.1",
        "port": 53,
        "skipFallback": false
      }
    ],
    "queryStrategy": "UseIPv4",
    "tag": "dns_inbound"
  }

5. Click Save/Update Config and Restart Xray Service.

Step 2: Ensure Router PBR Policy is Set to Catch-All

On your OpenWrt router, make sure your policy rule seamlessly captures this traffic, regardless of whether it originates from a local LAN machine or your proxy's inbound tunnel interface IP (10.4.0.3).

1. Open VPN Policy Routing screen.
2. Verify or create a rule matching this exact profile:
   • Local Addresses / Devices: Leave completely blank (This creates a global catch-all rule for all local and tunnel interfaces).
   • Remote addresses / domains: 100.64.0.1
   • Interface: Select your outbound Cloudron WireGuard interface (wg_cloudron).
3. Click Save & Apply.

[timka]

@bazinga

@bazinga said:

One question: why did you guys opt for this VPN protection vs simply allowing users to define a white list of source IPs or domains from where the access would be allowed? Would be much simpler and not require the VPN hassle (no matter on an endpoint or a router).

Well, someone requested it ^^. If I remember correctly ++

[necrevistonnezr]

Not everyone is on a fixed IP all the time (residential addresses, mobile networks, etc.)

… but why not both? Open a request