Can't make app VPN protection work

[bazinga]

This post is deleted!

[nebulon]

So since you mention that you see the VPN required page, this means that the IPs nginx (which does the switch to forward or show the placeholder page) config is either wrong here or it sees the wrong IPs. So from an nginx perspective it should allow requests through when the IP is the VPN app container IP.

You seem to be technical enough to maybe can evaluate the nginx configs you see with the network details you have for that Cloudron. Can you take a look over that at /home/yellowtent/platformdata/nginx/applications/<appid>/<appdomain>/conf where the app here is the one which is protected.

[bazinga]

@nebulon So, what exactly should I be looking for in the .conf file there?

When switching VPN Protection on I see at least the following to be added into the conf file:

allow 172.18.16.137;
allow fd00:c107:d509::a;
allow 172.18.16.147;
allow fd00:c107:d509::c;
deny all;
error_page 403 /vpn_required.html;

Plus few other minor changes.

docker inspect ... command returns 172.18.16.147 as an IP for cloudron/io.cloudron.openvpn container. This IP is in the above allow list. Not sure what else to check in the file?

However just thinking this through - after the VPN is traffic routed via a public DNS or internally without going back out on the public internet (eg. my desktop -> Cloudron hosted VPN app -> public internet -> VPN protected app on Cloudron OR my desktop -> Cloudron hosted VPN app -> internal network / local IPs -> VPN protected app on Cloudron)? If it's the former, then I'd expect an "allow" rule for Cloudron's IP.

[nebulon]

well then the configs look correct and the vpn app also seems to have the right IP. So no clue really why your requests then are not going via the VPN as you mentioned earlier. Maybe for good measure restart nginx just to be sure that this for some reason didn't apply.

[bazinga]

I've restarted Cloudron, which restarts everything, so I presume nginx would be ok there too. But I've also restarted nginx multiple times with no effect. Nginx logs show me connecting from Cloudron's IP.

Like I said - when I connect via the VPN even Cloudron's Event Log shows my IP as Cloudron's IP. So highly likely something is broken internally in traffic routing in Cloudron.

How can this be resolved / fixed? What kind of information do you need to troubleshoot this?

With all of these 0day issues I want to make bunch of apps closed from the Internet for the time being, so getting this VPN protection would be a good way to go.

[bazinga]

Well, as soon as I manually edit .conf file and add allow rule for the public IP of Cloudron server - I can access the app protected by VPN Protection. So, something is either broken in network routing (if the expectation for the routing to be done via internal IPs) or the .conf file should include allow PUBLIC-IP rule.

[nebulon]

Ok so if public IP works and this is what nginx sees for the app, this means you are no going via the VPN as if that would be the case nginx would see the local VPN container IP. So this is then the routing discrepancy. Basically for some reason your system reaches the server on its normal public IP and not via the tunnel.

[bazinga]

@nebulon Public IP of the Cloudron server - so I am going through the VPN because my IP is reported as the server's IP.

What happens here - my traffic is routed via the VPN, it gets routed out to the public internet (so I have server's IP) and then it hits the app being protected from the outside (not internally).

My server IP is : 1.2.3.4, my home IP is : 99.99.99.99, I have to add the following to .conf file to access the app when "VPN protection" is turned on:

allow 1.2.3.4;

And like I said before - even when all of my traffic is routed via the VPN (so that "what is my IP" and "dns leak test" report server's IP as my IP) the app still gives me the error page.

[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