Multi-Homed VPS Routing (private-network default route)

A VPS with public and private interfaces can receive a private-network DHCP default route at the same or better priority than its public route. The installer checks for this condition because it can disrupt container return traffic. Inspect the route table before deciding whether it explains an outage.

Symptoms

The panel is unreachable in a browser on https://your-domain — the connection just times out (no error page, no certificate warning).
ssh to the box still works fine, and curl from the box works fine.
Containers can't reach the internet: Let's Encrypt fails, AI APIs are unreachable.
Nothing in the logs explains it.

These symptoms are a reason to inspect routing, DNS and firewall rules; they do not establish the cause on their own.

Why it happens

For example, a route table may contain two defaults at the same metric:

default via 203.0.113.1  dev ens3 ... metric 100   # public
default via 10.1.0.1    dev ens4 ... metric 100   # private (10.x / 192.168.x / 172.16-31.x)

Competing defaults can select an unsuitable egress path for container traffic. Actual route selection depends on the host's addresses, routing tables and rules. Compare the public and private default metrics before applying a change; a firewall or DNS failure can produce similar symptoms.

The fix

Preserve console access and a copy of the existing network configuration before changing routes remotely. Have the hosting administrator confirm which interface is private; applying netplan can interrupt access. If the drop-in file below already exists, inspect it and preserve it rather than overwriting it.

Make the public interface the strict winner by giving the private interface's default route a worse (higher) metric. On Ubuntu/Debian (netplan):

sudo tee /etc/netplan/99-aap-route-fix.yaml >/dev/null <<'YAML'
network:
  version: 2
  ethernets:
    ens4:                       # <-- your PRIVATE interface (NOT the public one)
      dhcp4-overrides:
        route-metric: 4000
YAML
sudo chmod 600 /etc/netplan/99-aap-route-fix.yaml
sudo netplan apply

Replace ens4 with whichever interface carries the private (10.x / 192.168.x / 172.16–31.x) address. Afterwards:

default via 203.0.113.1 dev ens3 ... metric 100    # public — wins
default via 10.1.0.1   dev ens4 ... metric 4000   # private — fallback only

Verify public access and container egress after applying the change. If this drop-in caused a regression, remove only the file created for this change and apply the preserved network configuration using console access. Do not remove a pre-existing operator file.

Let the installer handle it

The installer detects this hazard during its pre-flight checks and prints a warning naming the offending interface. To have it fix the routing automatically (netplan hosts only), run the installer with AAP_FIX_ROUTING=1:

AAP_FIX_ROUTING=1 PANEL_DOMAIN="panel.example.com" ACME_EMAIL="you@example.com" \
  bash install.sh

When no drop-in already exists, it writes the reversible /etc/netplan/99-aap-route-fix.yaml file shown above for the detected private interface. It leaves an existing drop-in untouched; inspect its contents and any apply warning instead of assuming a repair occurred. On non-netplan systems it warns and prints manual guidance instead.