1

I'm trying to run OpenVPN client inside a Docker container with --up/--down parameters to run an application. The connection is getting established, but all traffic from the application is still going through the default gateway.

The OpenVPN server is pushing "redirect-gateway def1" when the connection is established, but OpenVPN client is not creating additional routes to override the default gateway.

I tried to get my application to dial through the tunnel device, and that is timing out. This was working when I tried from the host machine.

So instead, I tried to establish the routes manually (1 static route to openvpn server, and two routes 0.0.0.0/1, 128.0.0.0/1 for all other traffic, just like it was creating when tried on host machine), and reverted application to follow default routes, and it was timing out still.

When I use the same ovpn config file to connect from the host machine, the additional routes are established. All traffic is going through the vpn tunnel without any timeouts.

I tried the same docker configs on fedora:latest, ubuntu:latest, alpine:latest.

How can I get the tunnel to work inside Docker?

Update: I realised the missing routes is because I was running openvpn with --up/--down parameters. After removing them and running openvpn as a daemon and my program as the blocking process, the routes are getting created, but the requests still time out. I've tested the same thing in a vm and it works there.

0

Containers, unlike a VM, share the same kernel. Because of that, root inside of a container does not have the same access as root outside of a container. Otherwise, the root user could escape the container, mount devices, change it's namespace, etc. Container networking is one of those capabilities that is removed from the root user. To remove all of these restrictions, you can test your code with the docker run --privileged ... option. If that works, you can fine tune with various options to --cap-add. Regardless of whether you get the minimal permissions or not, your host will not be safe from a rogue application running in a container with those settings.

  • Thanks, but I have tried it with --privileged, and also running the container as root, with sudo docker but the requests are still timing out. Docker is running inside a VM, and I was still testing, so root was fine. – dough Nov 2 '17 at 5:55
  • sudo docker runs your client as root, it has no impact on what abilities you have inside the container. Since your networking stack is namespaced inside the container, best guess is your commands are not correct for running inside the namespace. Use --net host to run directly on the host network namespace. – BMitch Nov 2 '17 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.