Creating an internal connection between DNS, WireGuard, and Traefik in Docker requires configuring a shared network for service discovery while routing external traffic through the encrypted WireGuard tunnel. By integrating CoreDNS or Pi-hole with Traefik’s dynamic configuration, you ensure that internal hostnames resolve correctly to container IPs within the secure overlay network.
Network Architecture Overview
The core challenge in this setup is ensuring that services inside the WireGuard network can resolve each other’s hostnames without leaking requests to public DNS servers. To achieve this, we must define a specific Docker network that acts as the bridge between the WireGuard interface and the application containers managed by Traefik. This architecture relies on three distinct layers: the physical or virtual network interface provided by WireGuard, the Docker internal network for service communication, and the Traefik reverse proxy layer for routing and TLS termination.
It is crucial to understand that WireGuard operates at Layer 3 (network layer), while Docker networks operate at Layer 2/3 depending on the driver. By attaching the WireGuard container to a custom bridge network, we allow it to act as a gateway or a peer within that subnet. Other containers, such as those running databases or web applications, attach to the same network. Traefik, acting as the edge router, listens on ports exposed to the WireGuard interface, allowing clients connected via the VPN to access services using internal domain names.
Configuring the WireGuard Container
The first step is to deploy the WireGuard container with the correct permissions and network settings. The container must have NET_ADMIN capabilities to manage the network interfaces. We will use the wireguard/wireguard image or a similar lightweight alternative. The configuration involves generating keys and defining the peer connections. In your docker-compose.yml, ensure the WireGuard service is attached to a custom network, for example, named secure-net.
version: '3.8'
services:
wireguard:
image: linuxserver/wireguard
container_name: wireguard
cap_add:
- NET_ADMIN
- SYS_MODULE
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/London
- SERVERURL=vpn.yourdomain.com
- SERVERPORT=51820
- PEERS=2
- PEERDNS=auto
- INTERNAL_SUBNET=10.133.133.0
volumes:
- ./config:/config
ports:
- 51820:51820/udp
networks:
- secure-net
restart: unless-stopped
networks:
secure-net:
driver: bridge
Note the PEERDNS=auto setting. This instructs the client to use the DNS server specified within the WireGuard configuration. However, for our internal Docker integration, we need to override this behavior so that queries for internal domains go to our local DNS resolver rather than Google or Cloudflare public DNS. This is where the next component comes into play.
Integrating Internal DNS Resolution
To handle internal name resolution, we deploy a lightweight DNS server like CoreDNS or dnsmasq within the same secure-net network. This DNS server will be responsible for resolving hostnames of other containers in the Docker environment. For instance, if you have a Nextcloud container named nextcloud, the DNS server must return its IP address when queried for nextcloud.secure-net or simply nextcloud depending on your search domain configuration.
You can configure CoreDNS to forward non-internal queries to upstream DNS providers while handling internal zones locally. Alternatively, you can use Docker’s built-in DNS resolver if all services are on the same network, but this often fails when cross-network communication is required or when strict isolation is needed. A dedicated DNS container offers more control over caching and forwarding rules.
Ensure that the WireGuard configuration points to this DNS container’s IP address. In the WireGuard server config file (/config/wg0.conf), set the DNS directive to the IP address of your DNS container within the secure-net network. This ensures that any device connecting to your VPN uses your internal DNS for lookups, preventing DNS leaks and enabling seamless access to internal services.
Configuring Traefik for Internal Access
Traefik serves as the entry point for all HTTP and HTTPS traffic coming from the WireGuard network. It needs to be aware of the services running behind it and route requests based on hostname. Configure Traefik to listen on the WireGuard interface. In your Traefik static configuration, specify the provider as Docker and enable the watch flag to detect new containers automatically.
providers:
docker:
endpoint: "unix:///var/run/docker.sock"
exposedByDefault: false
network: secure-net
By specifying the network parameter, Traefik only discovers containers attached to secure-net. This prevents accidental exposure of internal services to other networks. Each target container must have labels indicating how Traefik should route traffic. For example:
labels:
- "traefik.http.routers.myapp.rule=Host(`myapp.local`)"
- "traefik.http.services.myapp.loadbalancer.server.port=8080"
When a user connects via WireGuard and requests myapp.local, their DNS query resolves to the Traefik container’s IP. Traefik then routes the request to the appropriate backend service. This setup creates a fully functional internal ecosystem where security, routing, and resolution are tightly integrated.
Verifying Connectivity and Troubleshooting
After deploying all components, verify the connectivity by pinging the DNS server from a WireGuard client. Check the logs of the WireGuard container to ensure peers are connecting successfully. If DNS resolution fails, inspect the DNS container’s logs for errors and ensure that the WireGuard configuration’s DNS field matches the correct IP address. Additionally, check Traefik’s dashboard to confirm that routers and services are active and receiving traffic.
If you encounter issues with packet loss or latency, consider adjusting the MTU settings in both the WireGuard configuration and the Docker network. WireGuard typically requires an MTU of 1420 or lower to accommodate overhead. You can set this in the WireGuard config using MTU=1420. Furthermore, ensure that firewall rules on the host machine allow UDP traffic on port 51820 and TCP/UDP traffic for the services exposed by Traefik.
This architecture provides a robust foundation for private cloud services. It leverages Docker’s networking capabilities for service discovery, WireGuard for secure transport, and Traefik for flexible routing. By carefully aligning these components, you create a secure, self-hosted environment that behaves like a professional enterprise network.
Frequently Asked Questions
Can I use Traefik with multiple Docker networks?
Yes, Traefik can monitor multiple networks by listing them in the provider configuration. However, you must ensure that the routing rules do not conflict and that each network has distinct subnets to avoid IP collisions. This allows you to segment different types of services, such as separating development environments from production.
How do I prevent DNS leaks when using WireGuard?
To prevent DNS leaks, always configure the PEERDNS setting in your WireGuard client to point to your internal DNS resolver. Additionally, use a kill switch on your client device to block all internet traffic if the WireGuard tunnel drops, ensuring no unencrypted DNS queries escape the secure tunnel.
What happens if the DNS container goes down?
If the internal DNS container fails, clients connected via WireGuard will lose the ability to resolve internal hostnames. They may fall back to public DNS if configured to do so, which could expose traffic. It is recommended to run redundant DNS instances or use Docker’s built-in DNS as a fallback mechanism for critical services.
Is it possible to expose internal services to the public internet securely?
While this setup focuses on internal access, you can extend it by configuring Traefik to also listen on public interfaces with proper authentication and rate limiting. However, exposing internal services directly increases risk. A better approach is to use a separate public-facing Traefik instance that proxies requests through the internal network, maintaining strict separation of concerns.
How do I update certificates for Traefik in this setup?
Traefik supports automatic certificate management via Let's Encrypt. Configure the ACME resolver in your Traefik dynamic configuration to store certificates in a volume. When the DNS container is used for validation, ensure it supports the necessary DNS challenge records. This automates SSL/TLS renewal for all internal and external domains managed by Traefik.