WireGuard Gateway

Purpose

The WireGuard gateway connects the public VPS to the Bytek home network through an encrypted tunnel.

The gateway allows public HTTPS traffic to reach Traefik without exposing individual home services directly through the Bell router.

The WireGuard gateway provides:

Service Information

Architecture Role

The WireGuard gateway sits between the public VPS and the home LAN.

When an external user opens a hosted application:

The WireGuard gateway does not host the applications.

The gateway only provides secure transport and controlled forwarding.

Primary Traffic Flow

The normal public application path includes:

Only required application traffic should pass through this path.

WireGuard Interface

The WireGuard interface contains:

The existing interface name, tunnel subnet, listening port, and peer address should be recorded after checking the active configuration.

Useful checks:

If the interface is not named wg0, replace wg0 with the actual interface name.

Do not copy the private key into BookStack.

Key Management

WireGuard authentication uses public and private key pairs.

Gateway Private Key

The gateway private key:

Gateway Public Key

The gateway public key may be stored in documentation.

The public key identifies the gateway to the VPS peer.

VPS Public Key

The gateway configuration contains the VPS public key.

The VPS private key remains only on the VPS.

Key Rotation

If a private key is exposed:

Allowed IPs

WireGuard Allowed IPs control routing and peer address validation.

The gateway and VPS must use narrow Allowed IP entries.

Allowed IPs should contain only:

Avoid using overly broad routes unless the architecture requires them.

Do not add the full home LAN to a peer merely for convenience without reviewing the security impact.

IP Forwarding

The gateway requires IPv4 forwarding.

Check the current value with:

sysctl net.ipv4.ip_forward

Expected result:

The persistent setting should be stored in a file under /etc/sysctl.d/.

If forwarding is disabled, the WireGuard handshake may succeed while application traffic still fails.

Network Address Translation

The gateway may use NAT when home-LAN devices do not have a route back to the WireGuard tunnel subnet.

NAT allows an internal destination to see the connection as originating from the WireGuard gateway’s LAN address.

Advantages:

Limitations:

NAT rules should be narrow and limited to required source networks, destinations, and ports.

Firewall Policy

The WireGuard gateway must permit only required tunnel traffic.

Required Traffic

Typical required traffic includes:

Restricted Traffic

The VPS should not automatically receive unrestricted access to:

Each additional route should have a documented purpose.

Traefik Forwarding

The primary application destination behind the WireGuard gateway is Traefik.

The gateway should forward approved public HTTPS traffic to Traefik rather than directly to individual application VMs.

This keeps public routing centralized.

Proxmox Management Through the Tunnel

Proxmox management is not part of the normal public ingress path.

If emergency Proxmox access through the VPS is intentionally enabled, use a narrow route such as:

Do not expose Proxmox TCP 8006 directly on the VPS public interface.

The preferred long-term remote-management method is a dedicated road-warrior VPN for the administrator’s laptop or phone.

Separation From a Future Remote-User VPN

The current WireGuard connection is used for VPS ingress.

A future laptop or phone VPN must use:

Do not reuse the VPS key pair or peer configuration for remote-user devices.

The VPS tunnel and a road-warrior VPN serve different purposes.

Service Startup

The WireGuard gateway should start early after a host reboot.

Preferred dependency order:

The WireGuard service should be enabled at boot.

Check the active service using:

systemctl status wg-quick@wg0 --no-pager

If the interface name differs, replace wg0 with the correct name.

Expected service state:

Health Validation

Confirm the Interface

Use:

sudo wg show

Confirm:

Confirm Tunnel Addressing

Use:

ip -br addr

The WireGuard interface should show the expected tunnel address.

Confirm Routes

Use:

ip route

The required tunnel and LAN routes should be present.

Confirm Forwarding

Use:

sysctl net.ipv4.ip_forward

Expected:

Confirm Firewall

If UFW is used:

sudo ufw status numbered

If iptables NAT is used:

sudo iptables -t nat -L -n -v --line-numbers

If nftables is used:

sudo nft list ruleset

Review only the firewall system actually used by the gateway.

End-to-End Validation

A successful WireGuard handshake does not prove application forwarding works.

Validate the complete path.

From the VPS

Test the home WireGuard peer or tunnel gateway address.

Then test Traefik through the tunnel on the intended destination and port.

From an External Client

Use:

Open a public application such as:

Open Authentik

The application should load through:

From the Home LAN

The same hostname should resolve through Pi-hole and bypass the VPS.

This verifies that public and private paths both work.

Monitoring

Recommended Uptime Kuma monitors include:

Monitoring should distinguish between:

Common Failure Scenarios

Handshake Is Missing

Possible causes:

Handshake Exists but Applications Fail

Possible causes:

Internal Applications Work but Public Applications Fail

This usually indicates a problem with:

One Public Application Fails

If other public applications work, the tunnel is probably healthy.

Check:

Tunnel Stops After a Power Failure

Check startup order:

Troubleshooting Order

When public ingress fails:

Do not regenerate WireGuard keys as an early troubleshooting step.

Logging

Useful log sources include:

Review the WireGuard unit using:

journalctl -u wg-quick@wg0 --since "30 minutes ago" --no-pager

Replace the interface name if necessary.

Look for:

Configuration Backup

Protect the following gateway data:

The VM or LXC is included in the Proxmox backup system.

The WireGuard private key should also exist in an encrypted recovery location.

Do not put the private key directly into BookStack.

Recovery Procedure

If the gateway VM or LXC is corrupted:

If the key is unavailable:

Security Checklist

Validation Checklist

Document Control