SECURITYCORPPublication active
Field notes
All field notes

Container Security / 02

Proving a container can only reach the internet through a VPN

A practical verification method for network namespaces, kill switches, DNS behavior, and restart persistence.

By Ravi Teja ThotaPublished Aug 24, 202610 min readIntermediate

A VPN badge in a dashboard is not evidence that application traffic is protected. The reliable pattern is architectural: make the application share the VPN container’s network namespace, restrict outbound routes, then test both the healthy and failed states.

VPN-bound workload egress flowApplication shares the VPN container’s network namespace, which routes through the VPN tunnel to the internet. If the tunnel drops, the flow branches to a kill-switch block instead of falling back to the host’s normal route.on dropApplicationTrust boundary: the workload shares the VPN container’s namespace instead of owning a separate interface.Shared networknamespaceVPN tunnelInternetNo silent fallback: a dropped tunnel blocks egress instead of quietly using the host’s normal gateway.Kill-switchblock
Application → shared network namespace → VPN tunnel → internet. If the tunnel drops, the flow branches to a kill-switch block instead of falling back to the host's normal route.
01

Share the boundary

Attach the workload to the VPN container’s network namespace instead of giving it an independent network path. The workload no longer owns a separate interface that can quietly use the host gateway.

Publish required ports from the VPN service, and allow only the private subnets needed for local management.

02

Prove the egress path

Check the public address from inside the application container and compare it with the VPN service. Inspect routes and DNS resolvers as supporting evidence; neither alone proves the actual egress path.

docker exec <app> curl -fsS https://ifconfig.me
docker exec <vpn> curl -fsS https://ifconfig.me
docker exec <app> ip route
03

Test the kill switch

Stop or break the tunnel without detaching the workload. Internet access should fail while explicitly allowed LAN management remains predictable.

Warning

If the application falls back to the host’s normal route when the tunnel drops, the design is not fail closed — treat that as a failed test, not an edge case.

04

Recheck after restarts

A one-time test misses startup races. Restart the stack and the host, then repeat the egress and failure tests. Capture the expected results in a small regression checklist so an image or configuration update cannot silently undo the boundary.

Related guides

01

Building a fail-closed malware gate for automated downloads

How to keep untrusted files away from media services until scanning, verification, and release all succeed.

03

A safer reverse proxy pattern for a private home lab

Split DNS, isolated listeners, internal TLS, and rollback planning without publishing services to the internet.