unable to connect with latest version

[RichBrew]

since the updated image was released last week, vpn will no longer connect
i have been using the container for about a year with no issues until now
no other changes have been made to the container settings

[RichBrew]

i resolved for the moment by reverting to polkaned/expressvpn:3.57.0.3-1.653ac494

[Dak0r]

I had the same problem. ExpressVPN would connect, but other containers couldn't use it for networking.
I was able to track it down to a DNS issue, as I could ping internet IPs correctly, but using domains would always fail.

Reverting to the previous version also solved it for me.

[Anqui3tas]

reverting also worked for me, I also updated expressvpn from within the container and all is working fine.

[cnschulz]

came here to report same.

[polkaned]

Strange, tests went well.
Just pushed the last version.

[Anqui3tas]

pulled new, still unable to connect.

• attempted multiple locations (US and CA), all fail, no other error logs besides "unable to connect"

reverting to: 3.57.0.3-1.653ac494 works fine

• able to update expressvpn within terminal and connect fine still

using container manager via Synology DSM 7.2 update 3

[Greenford]

watching

[letsbeanti]

Also unable to connect with latest version. Simple Unable to Connect error, no info in logs or in diagnostics. Able to ping directly outside of local network but not connect via expressvpn

confirm that 3.57.0.3-1.653ac494 works fine

[tariq-a]

Fixed in my case by switching to legacy iptables:

RUN update-alternatives --set iptables /usr/sbin/iptables-legacy && update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

[polkaned]

PR #53 adds iptables (ping @ephreal).
Add @tariq-a's fix
Just pushed the new image.

[didster]

Same (or similar) issue.

I have one expressvpn container then other containers which share its network stack with --net container:<vpn>. Worked fine for over a year, works fine with 3.57.0.3-1.653ac494. Doesn't work with 3.59.0.9-1.6575bdf8.

With latest version DNS is broken within the other containers. Works fine within the actual VPN container, but requests from the containers sharing the VPN network stack just timeout.

/etc/resolv.conf on the VPN container contains express VPN entry
/etc/resolv.conf on the sub-containers contain docker's VPN service IP 127.0.0.11 (probably implying its been DNS-leaking for years, oops)

Contents of resolv.conf is the same with 3.57

Hosts are pingable by IPs in sub containers, its just DNS which doesnt work.

Side note seems strange to me when sharing a network stack with --net container:<vpn> docker doesnt also share resolv.conf

[tariq-a]

Yep, I ended up with the same behaviour as @didster with the network stack but haven't had time to figure it out. I ended up removing iptables from the expressvpn container and it resolved the issue (but network lock doesn't work 😞). I'm running this on Docker desktop for Windows with WSL2 so that might be a factor.

[ephreal]

PR #53 adds iptables (ping @ephreal). Add @tariq-a's fix Just pushed the new image.

I've done a few tests myself, and I'm not seeing any issues in the expressvpn container without @tariq-a 's fix. I can ping domains (google.com, github.com, etc), and I can ping IP addresses (8.8.8.8, 1.1.1.1). As @didster says, hosts connecting to the container fail to resolve with DNS.

To test whether this is simply a DNS issue for connecting containers, I did the following prior to adding @tariq-a 's change.

1. Run https://github.com/jonlabelle/docker-network-tools with the --net container:<vpn> option
2. Attempt to ping a hostname
3. Watch the resolution fail
4. Manually change the entry inside /etc/resolv.conf to match the expressvpn /etc/resolv.conf
5. Attempt to ping a hostname
6. Watch resolution succeed

While the container is unable to resolve DNS, internet traffic is not leaked and is instead sent down the VPN tunnel.

After applying @tariq-a 's change, I tested again. The container using expressvpn as a network container succeeds in using DNS as expected, but the traffic is again leaked as can be seen in the image below (ignore the no replies, I can ping google.com as expected).

To me, this seems like DNS to non-expressvpn DNS servers is being blocked within the expressvpn container. This would be expected if the network lock for expressvpn is functioning as expected. Prior to having IPTables, it was possible for the network traffic to be leaked since expressvpn had no control over where the network traffic would flow. This means the network traffic would sometimes go to expressvpn, sometimes not. I'm going to do some more tests throughout today and see what it takes to forward all DNS requests that come through the container to the expressvpn DNS servers.

I'm unable to test the issue of the VPN not connecting with iptables since that doesn't happen for me. I'd personally recommend reverting the iptables changes made to the recent images since traffic is once again being leaked.

[ephreal]

@tariq-a, are you willing to test a container running efreal/expressvpn-deluge:latest as your target for --net container:<vpn>? I've applied my fixes to this image, and it works as expected in my tests. Its currently a quick and dirty hack that allows only dns traffic to leak. I'm looking into a more graceful fix that would allow the DNS traffic to be silently redirected to the expressvpn DNS servers.

The changes I implemented can be seen in my setup file here: https://github.com/ephreal/expressvpn-deluge/blob/main/setup.sh

[pwr22]

@polkaned the changes to use iptables-legacy vs iptables-nft actually is breaking the ability to connect for me. Rolling back to the last image before this (polkaned/expressvpn:3.59.0.9-1.656c98d6) or manually undoing it in the latest image resolves things.

So I'm not sure exactly why that particular change was needed but it looks like it isn't a one-size-fits-all solution. The container is running on:

> cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

> sudo docker version
Client: Docker Engine - Community
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:07:41 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:07:41 2023
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.6.26
  GitCommit:        3dd1e886e55dd695541fdcd67420c2888645a495
 runc:
  Version:          1.1.10
  GitCommit:        v1.1.10-0-g18a0cb0
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[tariq-a]

@ephreal Tried it but get the same problem with expressvpn failing to connect. I'm only able to get it to connect by using iptables-legacy. Your rules do however "fix" DNS for networked containers.

[AlbertDev1]

I tested with latest version and I have this issue. @RichBrew suggestion about revert to older version fix the issue in my case. I am unable to use latest on my setup. It been working perfectly fine in a Proxmox LXC container for a year or so, but latest is not working for me :-(

[polkaned]

Thanks for your reply.
Many thanks to @ephreal for your help about this issue and to find there was DNS leak with network image usage.
I clearly understand the issue now (I do not use expressvpn image as network, but as layer, so I do not have this issue) and I understand why my test did not have any problem.

I find a way to fix this.

First we need to understand that Docker overwrite resolv.conf with its dns server ip (which is a loopback IP).
Expressvpn binary rewrite with its own dns server ip. So the expressvpn container is ok.
The other container (called "app") has the docker service dns server ip. So it doesn't work because iptables deny this flow. App container needs to use the same dns server as the expressvpn container.
However, when we use container network, we can't use dns parameter when we start the run. So we need to find a way to have the resolv.conf of the expressvpn container in the app container.
There is no native way in docker to do it at the run.
I try to do it with a share volume and a command at the container start:

services:
  expressvpn:
    container_name: expressvpn
    image: polkaned/expressvpn
    environment:
      - ACTIVATION_CODE=
    cap_add:
      - NET_ADMIN
    devices: 
      - /dev/net/tun
    stdin_open: true
    tty: true
    command: /bin/bash -c "cp /etc/resolv.conf /shared_data/resolv.conf && bash"
    privileged: true
    restart: unless-stopped
    volumes:
      - shared-volume:/shared_data

  network-tools:
    container_name: network-tools
    image: jonlabelle/network-tools
    network_mode: service:expressvpn
    depends_on:
      - expressvpn
    stdin_open: true
    tty: true
    command: /bin/bash -c "sleep 20 && cp /shared_data/resolv.conf /etc/resolv.conf && bash"
    privileged: true
    restart: unless-stopped
    volumes:
      - shared-volume:/shared_data

volumes:
  shared-volume:

It is a bit ugly, but it seems to work.

[polkaned]

Until you implement this, if image doesn't work with iptables, you can remove it at the runtime.
Change the command /bin/bash with /bin/bash -c "apt-get remove -y iptables && bash".

[polkaned]

I push a new temporary image without iptables: expressvpn-wo-iptables https://hub.docker.com/r/polkaned/expressvpn-wo-iptables

So you have 3 ways to handle that for the moment.
I prefer to use iptables because of the DNS leak and the be sure that the network is blocked if the VPN goes down. We need to improve the docker-compose here #55 (comment).
If his solution if too complicated right now, you can remove iptables packages at the run #55 (comment).
If you don't care about the use of iptables, you can use the image expressvpn-wo-iptables https://hub.docker.com/r/polkaned/expressvpn-wo-iptables

[Nonoss117]

@polkaned , I followed your workaround #55 (comment)
for expressvpn container I did that:

    command: /bin/bash -c "cp /etc/resolv.conf /shared_data/resolv.conf && bash"
    volumes:
      - /mnt/user/appdata/expressvpn/shared_data:/shared_data

I'm using Unraid.
The command for the network-tool
command: /bin/bash -c "sleep 20 && cp /shared_data/resolv.conf /etc/resolv.conf && bash"
doesn't work for me.
Each time I tried, the container starts, waits 20 sec and after the container stops, nothing in the logs.

So I mounted the volume and the file in the network-tool like this :

network-tools
    volumes:
      - /mnt/user/appdata/expressvpn/shared_data/resolv.conf:/etc/resolv.conf

I mounted this volume in each container using expressvpn and it seems to work.
Thanks for the workaround

[Anqui3tas]

I'm still using polkaned/expressvpn:3.57.0.3-1.653ac494 and just updating expressvpn from within the container for now. Has :latest been updated/fixed?

[criscovolante]

I am attempting to use this on an UNRAID system and the docker. I have modified a terminal command with my activation code. The first time I ran the code it appeared to be working correctly but, I needed to make modifications to it. When I uninstalled it, attempted to run docker run polkaned/expressvpn with the modifications, it keeps coming back with my activation failing. What might I need to modify or delete to get past this?

Unable to find image 'polkaned/expressvpn:latest' locally
latest: Pulling from polkaned/expressvpn
b7f91549542c: Pull complete
d94e4e61b935: Pull complete
6cee95b20364: Pull complete
20d93ee187f9: Pull complete
Digest: sha256:5168a7709ae847ef6d215a46e2e9e0397691a07e69c567eba379f045357eec91
Status: Downloaded newer image for polkaned/expressvpn:latest
umount: /etc/resolv.conf: must be superuser to unmount.
Restarting ExpressVPN service: expressvpnd.
spawn expressvpn activate
Want extra privacy? Try Threat Manager. While your VPN is connected, Threat Manager adds an extra layer of privacy by blocking apps and websites from sharing your activity with third-party trackers or communicating with other malicious sites.

To enable Threat Manager, type 'expressvpn preferences set block_trackers true'.

Enter activation code:
Activating...
Activation failed.

This activation code has either expired or is incorrect. Please log in to our website to get your correct activation code and try again.

If you have any questions, please contact us.
send: spawn id exp3 not open
while executing
"send "n\r""
invoked from within
"expect {
"code:" {
send "$env(ACTIVATION_CODE)\r"
expect "information."
send "n\r"
}
"Already activated" {send "n..."
(file "/tmp/expressvpnActivate.sh" line 3)
Please activate your account.
Please activate your account.
Please activate your account.
Please activate your account.