Public VPS Ingress

Purpose

The public VPS is the internet-facing entry point for applications hosted on the Bytek home network.

The VPS prevents individual home services from being exposed directly through the Bell router. Public HTTPS traffic reaches the VPS first, then travels through an encrypted WireGuard tunnel to the home network.

The VPS provides:

A stable public IPv4 entry point. Public TCP port 443. An encrypted path to the home network. Separation between the public internet and private service backends. A recovery console independent of the home network. A controlled point for public firewalling.

Service Information

Setting Value Public IPv4 address 38.29.213.101 Primary purpose Public HTTPS ingress Public application port TCP 443 Home-network transport WireGuard Administration SSH key authentication SSH port Confirm current hardened SSH port Operating system Confirm current Linux distribution Hosting provider Confirm current VPS provider Public DNS provider WHC cPanel Monitoring Uptime Kuma

Architecture Role

The VPS does not host the main Bytek applications.

The VPS forwards approved traffic to the home network.

The primary traffic path is:

A client opens a public application hostname. WHC DNS resolves the hostname to 38.29.213.101. The client establishes HTTPS to the VPS on TCP port 443. The VPS forwards the permitted connection through WireGuard. The home WireGuard gateway receives the traffic. The gateway forwards the request to Traefik at 192.168.2.182. Traefik selects the correct application backend.

The VPS must not have direct access to all home-LAN services unless a specific rule requires it.

Public Hostnames

The following public DNS records point to the VPS:

Service Hostname Public Destination Nextcloud cloud.bytek.ca 38.29.213.101 BookStack docs.bytek.ca 38.29.213.101 Authentik portal.bytek.ca 38.29.213.101 Vikunja projects.bytek.ca 38.29.213.101 Traefik dashboard proxy.bytek.ca 38.29.213.101 Uptime Kuma status.bytek.ca 38.29.213.101

The public hostname pve.bytek.ca must not point to the VPS.

Proxmox remains available only through the LAN or a trusted remote-access method.

Public HTTPS Flow

External HTTPS requests follow this sequence:

WHC public DNS returns 38.29.213.101. The incoming connection reaches the VPS on TCP port 443. VPS firewall rules verify that the connection targets an approved public entry point. The VPS forwards the traffic through the WireGuard tunnel. The home WireGuard gateway forwards the connection to Traefik. Traefik terminates HTTPS or processes the forwarded connection according to the configured design. Traefik routes the request by hostname.

The VPS does not need separate public ports for every HTTPS application because Traefik distinguishes applications by hostname.

WireGuard Connection

The VPS maintains a WireGuard peer relationship with the home WireGuard gateway.

The tunnel is used for:

Public HTTPS ingress. Approved management traffic where explicitly configured. Connectivity testing between the VPS and home gateway. Delivery of traffic to Traefik.

The existing VPS tunnel must remain separate from any future laptop or phone VPN.

Do not reuse:

The same WireGuard client keys. The same peer address. The same interface configuration. The same subnet for road-warrior clients without deliberate routing design.

WireGuard Health

Review the tunnel using:

sudo wg show

Verify:

The home peer is listed. A recent handshake exists. Transfer counters are increasing. The expected tunnel addresses appear. Allowed IPs contain only intended routes. The endpoint and keepalive settings match the deployment.

A recent handshake confirms peer connectivity but does not prove that application forwarding works.

Test the complete application path separately.

VPS Firewall Policy

The VPS firewall should allow only required public and administrative traffic.

Required Public Access

TCP 443 for hosted HTTPS applications. The required WireGuard UDP port. The hardened SSH management port.

Traffic That Must Remain Private

Do not expose the following home ports through the VPS:

Service Port Proxmox VE TCP 8006 Pi-hole DNS administration Private management port Nextcloud AIO management TCP 8080 Nextcloud AIO backend TCP 11000 Uptime Kuma backend TCP 3001 Authentik backend TCP 9000 Vikunja backend TCP 3456 BookStack backend TCP 6875 Docker API Any Docker API listener Home service SSH TCP 22

New public ports must be documented before being added.

SSH Administration

VPS management uses SSH key authentication.

Recommended SSH controls include:

Disable password authentication. Disable direct root login where the administration model permits. Restrict accepted users. Use an Ed25519 key. Store the private key securely. Use Fail2ban or equivalent rate limiting. Keep the VPS provider console available for recovery. Restrict SSH using the VPS firewall where practical.

Confirm the current SSH listener using:

ss -lntp

Confirm SSH service health using:

systemctl is-active ssh

Expected result:

active

Do not place the private SSH key in BookStack.

Public DNS Management

Public DNS records are managed through WHC cPanel.

When adding a new public application:

Create an A record for the new hostname. Point the record to 38.29.213.101. Use a short TTL during the initial deployment. Create the matching Pi-hole split-DNS record. Create the Traefik router and service. Confirm the application backend is reachable from Traefik. Confirm certificate issuance. Test internally. Test externally using cellular data or another external network. Add Uptime Kuma monitoring. Update BookStack documentation.

Do not point public DNS directly to:

A private home address. The application VM. Traefik’s private IP. Proxmox. Nextcloud AIO management.

Public Application Onboarding Checklist

Before exposing a new application through the VPS, confirm:

The application works directly on its private backend. The application VM has a reserved IP. The Proxmox firewall allows Traefik to reach the backend. The public WHC record points to 38.29.213.101. Pi-hole points the hostname to 192.168.2.182. A Traefik route exists. The Traefik backend uses the correct current IP. A valid HTTPS certificate is issued. Authentik is configured if the application requires SSO. The application does not expose an administrative backend unintentionally. Uptime Kuma monitors the routed service. The VM is covered by the Proxmox backup job.

Service Validation

Confirm the VPS Public Address

Verify that public DNS resolves application hostnames to:

38.29.213.101

Confirm the WireGuard Tunnel

Use:

sudo wg show

Expected:

Recent handshake. Increasing transfer counters.

Confirm Public Port 443

Use:

ss -lntp

Confirm that the intended ingress service or forwarding mechanism is listening on TCP port 443.

Confirm Routing to the Home Network

Test the intended WireGuard peer or private tunnel address.

A successful tunnel ping confirms network reachability but not application-level routing.

Confirm an Application Through the VPS

From an external connection, open a public application such as:

Open Authentik

The request should reach Authentik without exposing the private backend port.

External Testing

External testing must use a network outside the home LAN.

Suitable test methods include:

A phone with Wi-Fi disabled. A laptop connected through a mobile hotspot. A remote trusted network. A public external monitoring service.

Testing from the home LAN may use Pi-hole split DNS and therefore bypass the VPS.

To validate public ingress, confirm the client resolves the hostname to 38.29.213.101.

Monitoring

Recommended Uptime Kuma monitors include:

Monitor Target VPS host Public VPS address Public HTTPS TCP 443 on the VPS WireGuard peer Home tunnel peer Authentik external route portal.bytek.ca Nextcloud external route cloud.bytek.ca BookStack external route docs.bytek.ca Vikunja external route projects.bytek.ca

Monitoring should distinguish:

VPS host availability. Public port availability. WireGuard tunnel availability. Traefik routing. Application health.

A successful ping does not prove HTTPS or WireGuard forwarding is functioning.

Logging

Review logs for:

SSH authentication failures. Firewall drops. WireGuard handshake loss. Forwarding failures. Unexpected public-port listeners. Repeated scans or brute-force attempts. Kernel networking errors.

Useful sources may include:

System journal. SSH journal. Firewall logs. WireGuard status. Reverse-proxy or forwarding logs, depending on the VPS design.

Do not copy active tokens, private keys, or full authentication headers into BookStack.

Failure Impact

If the VPS is unavailable:

External access to hosted applications fails. Internal LAN access should continue through Pi-hole and Traefik. Proxmox remains available internally. Nextcloud AIO management remains available internally. Pi-hole remains available internally. Authentik may remain available internally. Existing local application sessions may continue.

The VPS is therefore critical for external access but not for normal LAN access.

Common Failure Scenarios

Public DNS Resolves Incorrectly

Symptoms:

External clients connect to the wrong host. Certificate issuance fails. Application is unreachable externally.

Check:

WHC A record. Public resolver results. Record TTL. Accidental AAAA record.

WireGuard Handshake Is Missing

Symptoms:

VPS is reachable. Public TCP 443 may be open. Home applications are unavailable through the VPS.

Check:

Home internet connection. Home WireGuard gateway. Peer keys. Endpoint. Allowed IPs. UDP firewall rules. Persistent keepalive.

Tunnel Works but Application Fails

Symptoms:

WireGuard handshake exists. Traffic counters increase. Public hostname returns timeout or gateway error.

Check:

Forwarding rules. NAT rules. Traefik IP address. Traefik firewall. Application backend. Hostname routing. Certificate state.

Internal Access Works but External Access Fails

This usually indicates a problem with:

WHC public DNS. VPS. WireGuard. Home gateway forwarding. Public firewalling.

Internal split DNS bypasses those components.

External Access Works but Internal Access Fails

This usually indicates a problem with:

Pi-hole. Split-DNS records. Client DNS settings. Browser DNS over HTTPS. LAN firewall rules.

Recovery Procedure

If all public applications become unavailable:

Confirm the VPS is running through the hosting-provider console. Confirm the public IP is still 38.29.213.101. Confirm SSH access. Confirm the WireGuard interface. Confirm the latest home-peer handshake. Confirm transfer counters. Confirm IP forwarding and firewall rules. Confirm TCP 443 is listening. Confirm the home WireGuard gateway is running. Confirm Traefik is running. Test one application directly from Traefik. Test the public hostname from an external network. Review logs before changing configuration.

If SSH is unavailable:

Use the VPS provider console. Verify the SSH service. Verify the VPS firewall. Verify disk space. Verify the network interface. Restore SSH configuration from a known-good backup if required.

Backup and Recovery Data

Preserve the following VPS information:

WireGuard configuration. WireGuard public and private keys. Firewall rules. SSH configuration. Authorized SSH keys. Network forwarding rules. NAT rules. Service configuration. Provider account and console access. Public IP information. Recovery procedure.

Private keys must remain in a password manager or encrypted backup.

BookStack should record the location of secrets, not the secret values.

Security Review Checklist

Only approved public ports are open. SSH password authentication is disabled. SSH private keys are protected. Root SSH behavior matches the hardening policy. WireGuard keys are unique. WireGuard Allowed IPs are narrow. Public TCP 443 reaches only the intended ingress path. Proxmox TCP 8006 is not exposed. Application backend ports are not exposed. The Docker API is not exposed. Firewall and authentication logs are reviewed. Provider console access works. Recovery credentials are stored securely.

Document Control

Owner: Bryan Gagne-Plante Public address: 38.29.213.101 Primary role: Public HTTPS ingress Home transport: WireGuard Public DNS provider: WHC cPanel Last verified: YYYY-MM-DD Last external-access test: YYYY-MM-DD Last WireGuard recovery test: YYYY-MM-DD SSH recovery tested: Yes / No Known limitations: External application access depends on one VPS and one WireGuard tunnel