<p>If you run <code>docker run --rm -it alpine:3.7 /bin/sh</code>, created docker container will use default <code>bridge</code> network.</p>

<p>You can see the properties of this network using the following command: <code>docker network inspect bridge</code>. You can see there to which host interface (usually <code>docker0</code>) the network is associated and also what is the subnet for this network (usually <code>172.17.0.0/16</code>).</p>

<p>Additionally, if you run <code>docker run --rm -it alpine:3.7 ip addr</code> command, you should see the IP address of your container, which should be part of previously mentioned subnet.</p>

<p>Then, Docker by default creates NAT iptables rules, which allows the containers to communicate with outside world (as the container IP address is not known to the internet). You can see the rules using <code>sudo iptables -t nat -nvL POSTROUTING</code> command. It should look similar to:</p>

<pre><code>Chain POSTROUTING (policy ACCEPT 144K packets, 15M bytes)
 pkts bytes target     prot opt in     out     source               destination
  392 75916 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
</code></pre>

<p>Finally, for your container, there is no difference, if you try to reach remote site of your VPN or the internet, as the container only knows how to reach Docker network. You can see that using <code>docker run --rm -it alpine:3.7 ip r</code> command:</p>

<pre><code>default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2
</code></pre>

<p>So when traffic from the container goes via default route, it hits host routing table (I'm not 100% sure if this is right), it is being routed to your tunnel and then iptables NAT rule applies, changing the source IP of your traffic to IP of your end of the tunnel, so returning traffic will come back over the tunnel as well and then back to your container.</p>

CC BY-SA 4.0
2020-05-04T09:01:30.123Z
2020-05-04T09:01:30.123Z
Invidian
<p>My laptop has an IPsec VPN tunnel set up to access a remote site (with my side being the VPN client).</p>

<p>As an experiment, I started up a simple docker container on my laptop using <code>docker run --rm -it alpine:3.7 /bin/sh</code> and from within the container tried to ping one of the remote machines on the other side of the tunnel.</p>

<p>I expected the ping to not work, but I was surprised that it actually did.</p>

<p>I expected that in order to be able to access one of the remote machines from within a docker container, I'd have to first set up the VPN connection from within the container.</p>

<p>If not a full-fledged VPN connection from within the container, I thought that I would <em>at least</em> need to set up some <code>iptables</code> rules on the host machine. (My laptop's private IP address is <code>192.168.10.1</code>, that of the remote server is <code>10.2.5.100</code> and that of my docker container is <code>172.17.0.2</code>.) But even this wasn't needed...</p>

<p>So my question is how is it that communicating with the remote machines through the tunnel <em>just works</em> without any additional setup?</p>

<p>p.s. in case it matters, my laptop is running Arch Linux and I'm using strongswan to set up the IPsec connection.</p>

<docker><vpn>
Accessing remote servers through a VPN tunnel from within docker container
Gautam
# Accessing remote servers through a VPN tunnel from within docker container

(Asked by: username_0 on 2020-05-03)

My laptop has an IPsec VPN tunnel set up to access a remote site (with my side being the VPN client).

As an experiment, I started up a simple docker container on my laptop using `docker run --rm -it alpine:3.7 /bin/sh` and from within the container tried to ping one of the remote machines on the other side of the tunnel.

I expected the ping to not work, but I was surprised that it actually did.

I expected that in order to be able to access one of the remote machines from within a docker container, I'd have to first set up the VPN connection from within the container.

If not a full-fledged VPN connection from within the container, I thought that I would *at least* need to set up some `iptables` rules on the host machine. (My laptop's private IP address is `192.168.10.1`, that of the remote server is `10.2.5.100` and that of my docker container is `172.17.0.2`.) But even this wasn't needed...

So my question is how is it that communicating with the remote machines through the tunnel *just works* without any additional setup?

p.s. in case it matters, my laptop is running Arch Linux and I'm using strongswan to set up the IPsec connection.

**Tags:** docker, vpn


---

## 1 answers

### Answer by username_1 on 2020-05-04. Score: 3 | Accepted answer

If you run docker run --rm -it alpine:3.7 /bin/sh, created docker container will use default bridge network.
You can see the properties of this network using the following command: docker network inspect bridge. You can see there to which host interface (usually docker0) the network is associated and also what is the subnet for this network (usually 172.17.0.0/16).
Additionally, if you run docker run --rm -it alpine:3.7 ip addr command, you should see the IP address of your container, which should be part of previously mentioned subnet.
Then, Docker by default creates NAT iptables rules, which allows the containers to communicate with outside world (as the container IP address is not known to the internet). You can see the rules using sudo iptables -t nat -nvL POSTROUTING command. It should look similar to:
Chain POSTROUTING (policy ACCEPT 144K packets, 15M bytes)
 pkts bytes target     prot opt in     out     source               destination
  392 75916 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0

Finally, for your container, there is no difference, if you try to reach remote site of your VPN or the internet, as the container only knows how to reach Docker network. You can see that using docker run --rm -it alpine:3.7 ip r command:
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2

So when traffic from the container goes via default route, it hits host routing table (I'm not 100% sure if this is right), it is being routed to your tunnel and then iptables NAT rule applies, changing the source IP of your traffic to IP of your end of the tunnel, so returning traffic will come back over the tunnel as well and then back to your container.


---

