Not able to access to the internet in a container on a VPN Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern) Come Celebrate our 10 Year Anniversary!Use a docker container as a proxy to use a VPNOpenSwan IPSec phase #2 complicationsselective routing through a VPN tunnelAnonymizing OpenVPN Allow SSH Access to Internal ServerAllowing incoming VPN connections through a Cisco 2921 to a DD-WRT DeviceVPN is up but cannot ping/ssh..etcConnecting two clients openvpnHow to get OpenVPN Client (Mikrotik RouterOS) <-> OpenVPN server (Debian/Linux) setup to workopenvpn: can't manage to control client-to-client connections with iptablesPPTP VPN connects but does not have access to network resourcesIDir '193.174.193.64' does not match to 'vpngw.fh-kempten.de

How to compare two different files line by line in unix?

What's the meaning of "fortified infraction restraint"?

Why do we bend a book to keep it straight?

What was the first language to use conditional keywords?

Significance of Cersei's obsession with elephants?

What is the font for "b" letter?

Why weren't discrete x86 CPUs ever used in game hardware?

Performance gap between vector<bool> and array

Using et al. for a last / senior author rather than for a first author

How does the math work when buying airline miles?

Localisation of Category

How fail-safe is nr as stop bytes?

An adverb for when you're not exaggerating

Most bit efficient text communication method?

What is a fractional matching?

Is it possible for SQL statements to execute concurrently within a single session in SQL Server?

Illegal assignment from sObject to Id

A term for a woman complaining about things/begging in a cute/childish way

Take 2! Is this homebrew Lady of Pain warlock patron balanced?

Why aren't air breathing engines used as small first stages?

Is there hard evidence that the grant peer review system performs significantly better than random?

Project Euler #1 in C++

AppleTVs create a chatty alternate WiFi network

How come Sam didn't become Lord of Horn Hill?



Not able to access to the internet in a container on a VPN



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)
Come Celebrate our 10 Year Anniversary!Use a docker container as a proxy to use a VPNOpenSwan IPSec phase #2 complicationsselective routing through a VPN tunnelAnonymizing OpenVPN Allow SSH Access to Internal ServerAllowing incoming VPN connections through a Cisco 2921 to a DD-WRT DeviceVPN is up but cannot ping/ssh..etcConnecting two clients openvpnHow to get OpenVPN Client (Mikrotik RouterOS) <-> OpenVPN server (Debian/Linux) setup to workopenvpn: can't manage to control client-to-client connections with iptablesPPTP VPN connects but does not have access to network resourcesIDir '193.174.193.64' does not match to 'vpngw.fh-kempten.de



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








6















I'm not able to do a ping in a container when the VPN is started on my host machine.



I try do this :



docker run adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


It fails when the VPN is started but this works :



docker run --net=host adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


I can't always have the --net=host options because we can't use links in docker-compose.



I use IKE to start my VPN. Here is conf of the VPN (without seensible data) :



n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:10
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:1
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-life-secs:28800
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
b:auth-mutual-psk:----
n:phase2-pfsgroup:-1
s:network-host:[network-host-ip]
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:client-dns-addr:8.8.8.8,8.8.4.4
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:any
s:phase1-exchange:main
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
s:policy-level:auto
s:policy-list-include:0.0.0.0 / 0.0.0.0


Here is the results of route -n :



On the host when the VPN is not running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


When the VPN is running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.226.1 0.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
78.109.86.184 192.168.1.254 255.255.255.255 UGH 0 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


On the container (no change if the container is mounted or not) :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.19.0.1 0.0.0.0 UG 0 0 0 eth0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0


I checked other questions and I didn't found something working in my case. I don't think it's related to DNS because I try to access to an IP address.



What can I do?










share|improve this question






















  • did you find a solution to your problem, got the same...

    – Pascal Gula
    Dec 3 '18 at 22:05












  • I don't have a real solution. It still hard. I used docker-debian-ike to act like a proxy. So, when a request is performed in the first container, it's transfered to docker-debian-ike and continue the request.

    – Dougui
    Dec 4 '18 at 15:10











  • thanks for your quick reply, a workaround is still a valid option! :)

    – Pascal Gula
    Dec 5 '18 at 17:52











  • Your question is an answer to my question :). I had problem with connecting to the Internet from container while being connected to a client's VPN. The --net=host option is a solution for my issue.

    – itachi
    Mar 7 at 17:12











  • @itachi I'm glad it's useful for someone. I still have the problem.

    – Dougui
    Mar 7 at 19:49

















6















I'm not able to do a ping in a container when the VPN is started on my host machine.



I try do this :



docker run adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


It fails when the VPN is started but this works :



docker run --net=host adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


I can't always have the --net=host options because we can't use links in docker-compose.



I use IKE to start my VPN. Here is conf of the VPN (without seensible data) :



n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:10
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:1
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-life-secs:28800
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
b:auth-mutual-psk:----
n:phase2-pfsgroup:-1
s:network-host:[network-host-ip]
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:client-dns-addr:8.8.8.8,8.8.4.4
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:any
s:phase1-exchange:main
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
s:policy-level:auto
s:policy-list-include:0.0.0.0 / 0.0.0.0


Here is the results of route -n :



On the host when the VPN is not running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


When the VPN is running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.226.1 0.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
78.109.86.184 192.168.1.254 255.255.255.255 UGH 0 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


On the container (no change if the container is mounted or not) :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.19.0.1 0.0.0.0 UG 0 0 0 eth0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0


I checked other questions and I didn't found something working in my case. I don't think it's related to DNS because I try to access to an IP address.



What can I do?










share|improve this question






















  • did you find a solution to your problem, got the same...

    – Pascal Gula
    Dec 3 '18 at 22:05












  • I don't have a real solution. It still hard. I used docker-debian-ike to act like a proxy. So, when a request is performed in the first container, it's transfered to docker-debian-ike and continue the request.

    – Dougui
    Dec 4 '18 at 15:10











  • thanks for your quick reply, a workaround is still a valid option! :)

    – Pascal Gula
    Dec 5 '18 at 17:52











  • Your question is an answer to my question :). I had problem with connecting to the Internet from container while being connected to a client's VPN. The --net=host option is a solution for my issue.

    – itachi
    Mar 7 at 17:12











  • @itachi I'm glad it's useful for someone. I still have the problem.

    – Dougui
    Mar 7 at 19:49













6












6








6


3






I'm not able to do a ping in a container when the VPN is started on my host machine.



I try do this :



docker run adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


It fails when the VPN is started but this works :



docker run --net=host adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


I can't always have the --net=host options because we can't use links in docker-compose.



I use IKE to start my VPN. Here is conf of the VPN (without seensible data) :



n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:10
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:1
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-life-secs:28800
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
b:auth-mutual-psk:----
n:phase2-pfsgroup:-1
s:network-host:[network-host-ip]
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:client-dns-addr:8.8.8.8,8.8.4.4
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:any
s:phase1-exchange:main
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
s:policy-level:auto
s:policy-list-include:0.0.0.0 / 0.0.0.0


Here is the results of route -n :



On the host when the VPN is not running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


When the VPN is running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.226.1 0.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
78.109.86.184 192.168.1.254 255.255.255.255 UGH 0 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


On the container (no change if the container is mounted or not) :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.19.0.1 0.0.0.0 UG 0 0 0 eth0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0


I checked other questions and I didn't found something working in my case. I don't think it's related to DNS because I try to access to an IP address.



What can I do?










share|improve this question














I'm not able to do a ping in a container when the VPN is started on my host machine.



I try do this :



docker run adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


It fails when the VPN is started but this works :



docker run --net=host adiazmor/docker-ubuntu-with-ping ping 8.8.8.8


I can't always have the --net=host options because we can't use links in docker-compose.



I use IKE to start my VPN. Here is conf of the VPN (without seensible data) :



n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:10
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:1
n:network-notify-enable:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-dns-suffix-auto:1
n:client-splitdns-used:1
n:client-splitdns-auto:1
n:client-wins-used:1
n:client-wins-auto:1
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-life-secs:28800
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
b:auth-mutual-psk:----
n:phase2-pfsgroup:-1
s:network-host:[network-host-ip]
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:client-dns-addr:8.8.8.8,8.8.4.4
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:any
s:phase1-exchange:main
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
s:policy-level:auto
s:policy-list-include:0.0.0.0 / 0.0.0.0


Here is the results of route -n :



On the host when the VPN is not running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


When the VPN is running :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.226.1 0.0.0.0 UG 0 0 0 tap0
0.0.0.0 192.168.1.254 0.0.0.0 UG 100 0 0 enp4s0
78.109.86.184 192.168.1.254 255.255.255.255 UGH 0 0 0 enp4s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp4s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c57946727b62
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-e5b5cdaf12ea
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-0f8aa3757cdc
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-89f7a8041283
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-9313de2b3cda
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-5eb78801c6be
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp4s0


On the container (no change if the container is mounted or not) :



Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.19.0.1 0.0.0.0 UG 0 0 0 eth0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0


I checked other questions and I didn't found something working in my case. I don't think it's related to DNS because I try to access to an IP address.



What can I do?







vpn docker






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Feb 2 '18 at 2:29









DouguiDougui

3712




3712












  • did you find a solution to your problem, got the same...

    – Pascal Gula
    Dec 3 '18 at 22:05












  • I don't have a real solution. It still hard. I used docker-debian-ike to act like a proxy. So, when a request is performed in the first container, it's transfered to docker-debian-ike and continue the request.

    – Dougui
    Dec 4 '18 at 15:10











  • thanks for your quick reply, a workaround is still a valid option! :)

    – Pascal Gula
    Dec 5 '18 at 17:52











  • Your question is an answer to my question :). I had problem with connecting to the Internet from container while being connected to a client's VPN. The --net=host option is a solution for my issue.

    – itachi
    Mar 7 at 17:12











  • @itachi I'm glad it's useful for someone. I still have the problem.

    – Dougui
    Mar 7 at 19:49

















  • did you find a solution to your problem, got the same...

    – Pascal Gula
    Dec 3 '18 at 22:05












  • I don't have a real solution. It still hard. I used docker-debian-ike to act like a proxy. So, when a request is performed in the first container, it's transfered to docker-debian-ike and continue the request.

    – Dougui
    Dec 4 '18 at 15:10











  • thanks for your quick reply, a workaround is still a valid option! :)

    – Pascal Gula
    Dec 5 '18 at 17:52











  • Your question is an answer to my question :). I had problem with connecting to the Internet from container while being connected to a client's VPN. The --net=host option is a solution for my issue.

    – itachi
    Mar 7 at 17:12











  • @itachi I'm glad it's useful for someone. I still have the problem.

    – Dougui
    Mar 7 at 19:49
















did you find a solution to your problem, got the same...

– Pascal Gula
Dec 3 '18 at 22:05






did you find a solution to your problem, got the same...

– Pascal Gula
Dec 3 '18 at 22:05














I don't have a real solution. It still hard. I used docker-debian-ike to act like a proxy. So, when a request is performed in the first container, it's transfered to docker-debian-ike and continue the request.

– Dougui
Dec 4 '18 at 15:10





I don't have a real solution. It still hard. I used docker-debian-ike to act like a proxy. So, when a request is performed in the first container, it's transfered to docker-debian-ike and continue the request.

– Dougui
Dec 4 '18 at 15:10













thanks for your quick reply, a workaround is still a valid option! :)

– Pascal Gula
Dec 5 '18 at 17:52





thanks for your quick reply, a workaround is still a valid option! :)

– Pascal Gula
Dec 5 '18 at 17:52













Your question is an answer to my question :). I had problem with connecting to the Internet from container while being connected to a client's VPN. The --net=host option is a solution for my issue.

– itachi
Mar 7 at 17:12





Your question is an answer to my question :). I had problem with connecting to the Internet from container while being connected to a client's VPN. The --net=host option is a solution for my issue.

– itachi
Mar 7 at 17:12













@itachi I'm glad it's useful for someone. I still have the problem.

– Dougui
Mar 7 at 19:49





@itachi I'm glad it's useful for someone. I still have the problem.

– Dougui
Mar 7 at 19:49










1 Answer
1






active

oldest

votes


















0














Facts-ish:



  • Outbound traffic from your container without the --net=host mode is translated (NAT/PAT) to the host's IP address on the 192.168.1.0 network (bridge mode)

  • Your VPN creates a tap interface in the 192.168.226.X network (it might well be .1/32).

  • Your VPN creates a second default route with lower metric than the usual default route to send all the traffic through the VPN (tap interface).

Considerations:



When the host sends outbound traffic for a new connection (i.e. not replying for an incoming one) it has to decide which route to apply and also which interface is suitable for that traffic.



Based on the route table above, traffic generated on the host will choose the tap interface as it has a lower metric than the en4ps0 interface.



The root cause of the problem:



Traffic generated from inside the container will get translated to the host's IP address in the en4ps0 interface, so it will apply the route suitable for that interface, thus completely skipping the VPN.



The ping might fail due to asymmetric traffic, your VPN software black-holing traffic to/from en4ps0, etc - but the point here is that your container's traffic does not go through the tunnel because of the NAT/PAT.



Depending on your underlying network and other requirements, the macvlan driver might be a better choice than bridge or host. Alternatively you'll have to re-think your architecture or the need to put a VPN on the host (and not on a separate host / device instead)






share|improve this answer























  • Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

    – Dougui
    Mar 13 at 18:50











  • Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

    – Dougui
    Mar 13 at 19:01











  • Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

    – Pedro Perez
    Mar 15 at 15:33











  • As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

    – Pedro Perez
    Mar 15 at 15:34











  • Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

    – Pedro Perez
    Mar 15 at 15:34











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f895278%2fnot-able-to-access-to-the-internet-in-a-container-on-a-vpn%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














Facts-ish:



  • Outbound traffic from your container without the --net=host mode is translated (NAT/PAT) to the host's IP address on the 192.168.1.0 network (bridge mode)

  • Your VPN creates a tap interface in the 192.168.226.X network (it might well be .1/32).

  • Your VPN creates a second default route with lower metric than the usual default route to send all the traffic through the VPN (tap interface).

Considerations:



When the host sends outbound traffic for a new connection (i.e. not replying for an incoming one) it has to decide which route to apply and also which interface is suitable for that traffic.



Based on the route table above, traffic generated on the host will choose the tap interface as it has a lower metric than the en4ps0 interface.



The root cause of the problem:



Traffic generated from inside the container will get translated to the host's IP address in the en4ps0 interface, so it will apply the route suitable for that interface, thus completely skipping the VPN.



The ping might fail due to asymmetric traffic, your VPN software black-holing traffic to/from en4ps0, etc - but the point here is that your container's traffic does not go through the tunnel because of the NAT/PAT.



Depending on your underlying network and other requirements, the macvlan driver might be a better choice than bridge or host. Alternatively you'll have to re-think your architecture or the need to put a VPN on the host (and not on a separate host / device instead)






share|improve this answer























  • Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

    – Dougui
    Mar 13 at 18:50











  • Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

    – Dougui
    Mar 13 at 19:01











  • Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

    – Pedro Perez
    Mar 15 at 15:33











  • As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

    – Pedro Perez
    Mar 15 at 15:34











  • Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

    – Pedro Perez
    Mar 15 at 15:34















0














Facts-ish:



  • Outbound traffic from your container without the --net=host mode is translated (NAT/PAT) to the host's IP address on the 192.168.1.0 network (bridge mode)

  • Your VPN creates a tap interface in the 192.168.226.X network (it might well be .1/32).

  • Your VPN creates a second default route with lower metric than the usual default route to send all the traffic through the VPN (tap interface).

Considerations:



When the host sends outbound traffic for a new connection (i.e. not replying for an incoming one) it has to decide which route to apply and also which interface is suitable for that traffic.



Based on the route table above, traffic generated on the host will choose the tap interface as it has a lower metric than the en4ps0 interface.



The root cause of the problem:



Traffic generated from inside the container will get translated to the host's IP address in the en4ps0 interface, so it will apply the route suitable for that interface, thus completely skipping the VPN.



The ping might fail due to asymmetric traffic, your VPN software black-holing traffic to/from en4ps0, etc - but the point here is that your container's traffic does not go through the tunnel because of the NAT/PAT.



Depending on your underlying network and other requirements, the macvlan driver might be a better choice than bridge or host. Alternatively you'll have to re-think your architecture or the need to put a VPN on the host (and not on a separate host / device instead)






share|improve this answer























  • Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

    – Dougui
    Mar 13 at 18:50











  • Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

    – Dougui
    Mar 13 at 19:01











  • Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

    – Pedro Perez
    Mar 15 at 15:33











  • As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

    – Pedro Perez
    Mar 15 at 15:34











  • Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

    – Pedro Perez
    Mar 15 at 15:34













0












0








0







Facts-ish:



  • Outbound traffic from your container without the --net=host mode is translated (NAT/PAT) to the host's IP address on the 192.168.1.0 network (bridge mode)

  • Your VPN creates a tap interface in the 192.168.226.X network (it might well be .1/32).

  • Your VPN creates a second default route with lower metric than the usual default route to send all the traffic through the VPN (tap interface).

Considerations:



When the host sends outbound traffic for a new connection (i.e. not replying for an incoming one) it has to decide which route to apply and also which interface is suitable for that traffic.



Based on the route table above, traffic generated on the host will choose the tap interface as it has a lower metric than the en4ps0 interface.



The root cause of the problem:



Traffic generated from inside the container will get translated to the host's IP address in the en4ps0 interface, so it will apply the route suitable for that interface, thus completely skipping the VPN.



The ping might fail due to asymmetric traffic, your VPN software black-holing traffic to/from en4ps0, etc - but the point here is that your container's traffic does not go through the tunnel because of the NAT/PAT.



Depending on your underlying network and other requirements, the macvlan driver might be a better choice than bridge or host. Alternatively you'll have to re-think your architecture or the need to put a VPN on the host (and not on a separate host / device instead)






share|improve this answer













Facts-ish:



  • Outbound traffic from your container without the --net=host mode is translated (NAT/PAT) to the host's IP address on the 192.168.1.0 network (bridge mode)

  • Your VPN creates a tap interface in the 192.168.226.X network (it might well be .1/32).

  • Your VPN creates a second default route with lower metric than the usual default route to send all the traffic through the VPN (tap interface).

Considerations:



When the host sends outbound traffic for a new connection (i.e. not replying for an incoming one) it has to decide which route to apply and also which interface is suitable for that traffic.



Based on the route table above, traffic generated on the host will choose the tap interface as it has a lower metric than the en4ps0 interface.



The root cause of the problem:



Traffic generated from inside the container will get translated to the host's IP address in the en4ps0 interface, so it will apply the route suitable for that interface, thus completely skipping the VPN.



The ping might fail due to asymmetric traffic, your VPN software black-holing traffic to/from en4ps0, etc - but the point here is that your container's traffic does not go through the tunnel because of the NAT/PAT.



Depending on your underlying network and other requirements, the macvlan driver might be a better choice than bridge or host. Alternatively you'll have to re-think your architecture or the need to put a VPN on the host (and not on a separate host / device instead)







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 12 at 17:36









Pedro PerezPedro Perez

2,915167




2,915167












  • Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

    – Dougui
    Mar 13 at 18:50











  • Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

    – Dougui
    Mar 13 at 19:01











  • Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

    – Pedro Perez
    Mar 15 at 15:33











  • As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

    – Pedro Perez
    Mar 15 at 15:34











  • Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

    – Pedro Perez
    Mar 15 at 15:34

















  • Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

    – Dougui
    Mar 13 at 18:50











  • Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

    – Dougui
    Mar 13 at 19:01











  • Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

    – Pedro Perez
    Mar 15 at 15:33











  • As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

    – Pedro Perez
    Mar 15 at 15:34











  • Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

    – Pedro Perez
    Mar 15 at 15:34
















Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

– Dougui
Mar 13 at 18:50





Thank you very much for your answer. I created a network with docker network create -d macvlan -o parent=enp4s0 --gateway=192.168.1.254 --subnet=192.168.1.0/24 vpn. Now, I can ping a domain when the VPN is ON but I cannot access to the container from my host. I tried with localhost and with the given IP. Do you have an idea?

– Dougui
Mar 13 at 18:50













Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

– Dougui
Mar 13 at 19:01





Also, I'm not able to access to domains behind the VPN so I guess it doesn't do the translation.

– Dougui
Mar 13 at 19:01













Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

– Pedro Perez
Mar 15 at 15:33





Hi, maybe you need to add a route for the container to use the IP address of the host as gateway (and make sure the host can route traffic, check the forwarding flag), then apply NAT/masquerading rules in iptables to "hide" behind the host's IP traffic from the container to the hosts behind the VPN

– Pedro Perez
Mar 15 at 15:33













As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

– Pedro Perez
Mar 15 at 15:34





As per accessing the container from the host, I'm guessing some iptables rule might be blocking that traffic... maybe a simultaneous tcpdump on the host and inside the container will shed some more light.

– Pedro Perez
Mar 15 at 15:34













Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

– Pedro Perez
Mar 15 at 15:34





Finally, I'd like to say that at this point you might want to use an external machine to connect to the VPN and route traffic against that... it seems the setup is getting too complex

– Pedro Perez
Mar 15 at 15:34

















draft saved

draft discarded
















































Thanks for contributing an answer to Server Fault!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f895278%2fnot-able-to-access-to-the-internet-in-a-container-on-a-vpn%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020