I’ve trawled the forum for clues but I can’t see anything that fits this very simple question:
Should I be able to connect to hosts on my corporate VPN from a container configured similar to the compose below?
If I configure that compose below to host mode obviously I can hit servers on the corporate VPN but I have a private network of containers that cannot be in host mode as they interact on specific ips for end to end service testing. However there is now a requirement for one of the containers to access a server on the corporate VPN which it can’t even by ping. NB: the container can resolve the address but ping fails.
If it’s relevant the VPN on the host is cisco anyconnect
command: /bin/sh -c "tail -f /dev/null "
- subnet: '172.24.0.0/16'
Any clues/solutions or diagnostic advice greatly appreciated
The most common problem is that VPN connections alter the route (0.0.0.0 or a range that collides with the docker network ranges) or do not use split-tunneling (which allows local and vpn communicaition)
If you are able to reach devices on your lan, then the vpn connection should use split-tunneling.
You could check the routing table, though the “how” depends on your os and version.
Thus said: Are your running Docker Desktop or Docke-CE? And on which os?
Docker ce on ubunu 20.04 the container bullseye as you see. Thanks for the prompt response
You haven’t mentioned whether you are able to reach devices in your lan when you are connected to the vpn. Does it work?
Please share the output of
Oh yes of of course the cisco anyconnect is doing it’s stuff. The output is minimal if not.
ip route returns 60 lines I’d rather not paste all here given it’s got company public ips I might get in trouble for publishing.
Typical output 1 of 60
192.168.8.0/24 dev cscotun0 proto unspec scope link
Is there anything specific I should be looking for in the output?
As I pointed out earlier if I put the docker container in host mode it can access the servers fine I have no local lan as such as I work remotely.
This is the output piped into grep for the docker. Note 172.24 is my compose
ip route | grep 172
default via 172.20.10.1 dev wlp0s20f3 proto dhcp metric 600
188.8.131.52 via 172.20.10.1 dev wlp0s20f3 proto unspec
172.16.0.0/14 dev cscotun0 proto unspec scope link
172.20.0.0/16 dev docker0 proto kernel scope link src 172.20.0.1 linkdown
172.20.10.0/28 dev wlp0s20f3 proto kernel scope link src 172.20.10.4 metric 600
172.20.10.1 dev wlp0s20f3 proto unspec scope link
172.23.0.0/16 dev br-72de436f12bb proto kernel scope link src 172.23.0.1 linkdown
172.24.0.0/16 dev br-60cdb7d306ae proto kernel scope link src 172.24.0.1
Theses routes look somehow strange:
If looks like your physical interface has an ip from the ip-range of the default docker bridge. This can’t be right.
I assume wireshark could help to identify where the culprit is.
I’m on a 4G network that’s what it dishes out
I’ll get someone on a normal router to give me there output tomorrow but I’ve been on 4G for months and that’s what Yoigo in spain give you.