VPN client is resolving the public Traefik address.

OpenCode VPN Access Report

Problem
OpenCode at opencode.prettybird.zapplebee.online can return HTTP 403 Forbidden even when the user believes they are connected through UDM-hosted OpenVPN.

Observed Evidence
Traefik access logs showed the denied request with:

- RequestHost: opencode.prettybird.zapplebee.online
- DownstreamStatus: 403
- RouterName: opencode-web@file
- ClientHost: 50.212.170.185
- OriginStatus: 0

The 403 is generated by Traefik before forwarding to OpenCode. OriginStatus 0 confirms the backend was not contacted.

Current Traefik Allowlist
The OpenCode router uses an ipAllowList middleware allowing only:

- 192.168.1.0/24
- 192.168.3.0/24

The denied source IP, 50.212.170.185, is not in either allowlisted range.

Root Cause
The VPN client resolves opencode.prettybird.zapplebee.online to the public 207.x.x.x address. Because the destination is the public Traefik/WAN address, the client reaches Traefik over the normal public internet path rather than as a 192.168.3.x OpenVPN client.

As a result, Traefik sees the request source as the public client IP 50.212.170.185 instead of the VPN subnet. The ipAllowList correctly denies it.

Why This Can Happen
OpenVPN on UDM is commonly configured as split tunnel. Split tunnel routes private LAN/VPN networks through the tunnel, but public IP destinations still use the client's normal internet route. Since opencode.prettybird.zapplebee.online resolves to a public IP, it does not automatically use the VPN path.

Recommended Fix
Use split DNS for VPN clients so:

opencode.prettybird.zapplebee.online -> 192.168.1.86

Replace 192.168.1.86 if Traefik's LAN IP is different.

With split DNS, VPN clients connect to Traefik through the LAN/VPN path, and Traefik sees an allowed private source address instead of the public client IP.

Temporary Test
From the VPN client, test the intended behavior with:

curl --resolve opencode.prettybird.zapplebee.online:443:192.168.1.86 https://opencode.prettybird.zapplebee.online/api/health

Expected result:

HTTP 200 with {"healthy":true}

Alternative Fixes
Push a route for the public 207.x.x.x address through the VPN, or configure full-tunnel VPN. These are broader network changes than split DNS.

Not Recommended
Adding 50.212.170.185/32 to the Traefik allowlist would allow that public IP without requiring VPN routing. That weakens the VPN-only access model and should only be done intentionally.