-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internet DNS resolution no longer works in internal bridge network #7262
Comments
cc @djs55 |
This is not just an issue on Docker for Mac. I'm running Docker CLI on Debian and seeing a similar issue with resolving DNS. |
@dathbe If that issue also exists with no Docker Desktop involved, that's an Engine bug. Could you open a ticket on https://github.com/moby/moby please? |
I was able to get my Docker Containers to connect to VPN- finally. I use Docker Desktop for Mac v4.29. After weeks of trouble shooting, I found that-- under features under development -- an option for "Enable Host Networking". I'm not usually a fan of selecting these new features while under testing. BUT, frustrated I gave it a try. And everything suddenly went back to normal. I was able to connect to my VPN. DNS issue fixed and my setup went back to functioning normal again. I don't know where/how to access this in Docker for other platforms.... but this selection worked for me and my setup.The feature doesn't necessarily feel "optional" since not having it selected broke my entire setup and prevented my Containers from accessing the Internet (or in my case connecting to my VPN) without being selected. If the feature was mandatory to be selected for my setup to continue working post-Update.... Docker should have selected it for me automatically. |
Description
I use Compose. I have two networks:
private
(bridge, internal)public
(bridge)I have these containers:
wireguard
- in both networksprivate
andpublic
at the same time. Provides VPN. Single instance only.worker
- in networkprivate
only. Multiple instances. These have adns
config added with a public DNS server IP to allow resolution of public domains.Objective: The
worker
internet traffic must only ever go throughwireguard
and never leave the host machine directly. Local DNS must continue to work so the containers can resolve each other's IPs and talk to each other. Internet DNS must also resolve.Issue 1: This is difficult to setup because Docker networking does not have the right tools for the job. It is not possible to change a network's default gateway to point to a container IP.
Solution for issue 1: I added
NET_ADMIN
capability toworker
and used this script to change the default route:Issue 2: With
NET_ADMIN
capability, nothing prevents the container from changing the default route again and pointing back to the Docker default gateway, at which point it would bypass the VPN traffic.Solution for 2: That's why I use the
internal
network flag onprivate
, which addsiptables
firewall rules that prevent traffic from leaving that network completely.Issue 3: These
iptables
rules block all traffic with IPs outside of theprivate
CIDR. So it won't let traffic pass through thewireguard
VPN because the IPs fall outside of theprivate
CIDR.Solution for 3:
I created another container with capability
NET_ADMIN
and critically withnetwork_mode: host
. This container then adds moreiptables
rules to theDOCKER-USER
chain. It runs:This will allow traffic destined to internet IPs to be exchanged between
private
containers. Crucially, it still blocks traffic that is sent to the Docker's original default route, but allows internet traffic to go to thewireguard
container.The reason I chose to do this setup in a container is because I wanted the entire application to be self-contained and portable, instead of relying on host machine startup scripts.
After jumping through all the hoops above, I got my networking setup working. Traffic goes from
worker
inprivate
viawireguard
inprivate
, and exits viawireguard
inpublic
but now in a VPN tunnel. Theworker
containers cannot bypass this even if they get hacked and change their default route.Now for the actual issue I have: this setup worked fine all the way to v4.28.0 (139021). Traffic went through correctly. Local DNS resolved correctly. Internet DNS also resolved correctly. After updating to v4.29.0 (145265), the internet DNS no longer works. Cannot resolve internet names. Local resolution continues to work. Traffic still flows through correctly, I can
ping 8.8.8.8
fromworker
just fine.I could do something like
echo "nameserver 8.8.8.8" > /etc/resolv.conf
inworker
and that would allow me to resolve internet names but also prevent me from resolving local Docker names. I do not know what changed or where between v4.28 and v4.29, but internet resolution no longer works since v4.29.Reproduce
As you can see, this is a pretty elaborate setup which also requires an active WireGuard connection, the latter I cannot provide for you. If necessary, I can make a repository to put my
docker-compose.yaml
in there together with the.sh
scripts, but it will require you to supply your ownWireGuard
config anyway. Let me know what you need.Expected behavior
No response
docker version
Client: Cloud integration: v1.0.35+desktop.13 Version: 26.0.0 API version: 1.45 Go version: go1.21.8 Git commit: 2ae903e Built: Wed Mar 20 15:14:46 2024 OS/Arch: darwin/amd64 Context: desktop-linux Server: Docker Desktop 4.29.0 (145265) Engine: Version: 26.0.0 API version: 1.45 (minimum version 1.24) Go version: go1.21.8 Git commit: 8b79278 Built: Wed Mar 20 15:18:01 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.28 GitCommit: ae07eda36dd25f8a1b98dfbf587313b99c0190bb runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0
docker info
Diagnostics ID
a
Additional Info
No response
The text was updated successfully, but these errors were encountered: