TRANSPARENCY: this post was generated by AI. The fix is by AI. I did my best to ensure that the AI tested for DNS leaks and vulnerabilities the fix might create. Be skeptical. Use at your own risk.

I am sending the report to ExpressVPN support.

---

[AI generated text from here on in.]

I found and worked around a DNS compatibility bug between ExpressVPN 14.2.0 and Pop!_OS 24.04.

This is not a general "VPN tunnel will not connect" problem. ExpressVPN reported Connected, the tunnel passed traffic to literal IP addresses, and the public address changed to an ExpressVPN exit address. However, DNS failed, so browsers timed out and most applications appeared to have no internet.

Environment

• Pop!_OS 24.04 LTS with COSMIC
• /etc/os-release: ID=pop, ID_LIKE="ubuntu debian"
• systemd 255
• NetworkManager 1.46.0
• systemd-resolved enabled and active
• ExpressVPN 14.2.0+13656
• Reproduced with Lightway UDP and WireGuard

Root cause

The installed ExpressVPN script /opt/expressvpn/bin/openvpn-updown.sh contains this test:

# NOTE: Work-around for DNS bug in Ubuntu 24 - where resolvectl may hang
if /usr/bin/systemctl --version | grep -q "systemd 255"; then
  hasUbuntuDnsBug=1

It does not check the distribution. It assumes every system running systemd 255 has the Ubuntu 24 DNS bug.

Pop!_OS is based on Ubuntu, but it is a separate distribution and identifies itself as ID=pop. On this machine, resolvectl works normally. Nevertheless, ExpressVPN took its Ubuntu workaround path, bypassed systemd-resolved, and directly overwrote /etc/resolv.conf with:

nameserver 100.64.100.1

Because /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, this also writes into a file managed by systemd-resolved.

The ExpressVPN SDK then repeatedly logged errors including:

Temporary failure in name resolution
User IP fetch did not complete within 2s

Workaround

This is an unofficial, local workaround. It makes the Ubuntu-specific branch require an actual Ubuntu ID, allowing Pop!_OS to use the script's existing systemd-resolved integration.

Disconnect ExpressVPN first. Back up the script without overwriting an existing backup:

test ! -e /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix && \
sudo cp -a \
  /opt/expressvpn/bin/openvpn-updown.sh \
  /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix

Apply the one-line change:

sudo sed -i \
  's@if /usr/bin/systemctl --version | grep -q "systemd 255"; then@if grep -q "^ID=ubuntu$" /etc/os-release \&\& /usr/bin/systemctl --version | grep -q "systemd 255"; then@' \
  /opt/expressvpn/bin/openvpn-updown.sh

Validate the shell syntax and inspect the exact change:

bash -n /opt/expressvpn/bin/openvpn-updown.sh
sudo diff -u \
  /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix \
  /opt/expressvpn/bin/openvpn-updown.sh

The diff should show exactly one changed line:

-if /usr/bin/systemctl --version | grep -q "systemd 255"; then
+if grep -q "^ID=ubuntu$" /etc/os-release && /usr/bin/systemctl --version | grep -q "systemd 255"; then

Do not continue if the diff shows any other change.

Verification

After reconnecting, these commands should show that the systemd stub remains intact and the VPN interface owns the global DNS route:

For WireGuard:

readlink -f /etc/resolv.conf
grep '^nameserver' /etc/resolv.conf
resolvectl status wgexpressvpn0
timeout 8 getent ahostsv4 www.google.com

For Lightway:

readlink -f /etc/resolv.conf
grep '^nameserver' /etc/resolv.conf
resolvectl status tun0
timeout 8 getent ahostsv4 www.google.com

Expected results:

/run/systemd/resolve/stub-resolv.conf
nameserver 127.0.0.53

The VPN interface should show:

Current DNS Server: 100.64.100.1
DNS Domain: ~.

In my test, ExpressVPN logged Applying nameservers using systemd-resolved..., DNS worked immediately, and normal HTTPS traffic used the VPN exit.

I tested again with Lightway UDP and re-enabled ExpressVPN's malicious-site, tracker, and ad blockers without breaking connectivity. A packet capture showed DNS requests and responses only on tun0; no port 53 traffic left through the physical Ethernet interface. ExpressVPN's DNS leak and WebRTC leak tests both passed.

Rollback

Disconnect ExpressVPN, then restore the original file:

expressvpnctl disconnect
sudo cp -a \
  /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix \
  /opt/expressvpn/bin/openvpn-updown.sh

Caveats

• This is not an official ExpressVPN patch.
• It modifies a root-owned vendor script. Verify the diff before reconnecting.
• An ExpressVPN update may overwrite the change.
• Do not blindly reapply this workaround after an update. Check whether ExpressVPN has fixed the detection logic first.
• The ExpressVPN daemon has a separate compiled systemd-255 check, so it may continue logging Ubuntu 24 DNS bug is present even though the patched DNS script uses systemd-resolved. Split tunneling was disabled during my tests.
• The better upstream fix would detect actual resolver capability, with a timeout, instead of inferring behavior from the systemd major version alone.

TRANSPARENCY: this post was generated by AI. The fix is by AI. I did my best to ensure that the AI tested for DNS leaks and vulnerabilities the fix might create. Be skeptical. Use at your own risk.

I am sending the report to ExpressVPN support and x-posting on the ExpressVPN subreddit.

---

[AI generated text from here on in.]

I found and worked around a DNS compatibility bug between ExpressVPN 14.2.0 and Pop!_OS 24.04.

This is not a general "VPN tunnel will not connect" problem. ExpressVPN reported Connected, the tunnel passed traffic to literal IP addresses, and the public address changed to an ExpressVPN exit address. However, DNS failed, so browsers timed out and most applications appeared to have no internet.

Environment

• Pop!_OS 24.04 LTS with COSMIC
• /etc/os-release: ID=pop, ID_LIKE="ubuntu debian"
• systemd 255
• NetworkManager 1.46.0
• systemd-resolved enabled and active
• ExpressVPN 14.2.0+13656
• Reproduced with Lightway UDP and WireGuard

Root cause

The installed ExpressVPN script /opt/expressvpn/bin/openvpn-updown.sh contains this test:

# NOTE: Work-around for DNS bug in Ubuntu 24 - where resolvectl may hang
if /usr/bin/systemctl --version | grep -q "systemd 255"; then
  hasUbuntuDnsBug=1

It does not check the distribution. It assumes every system running systemd 255 has the Ubuntu 24 DNS bug.

Pop!_OS is based on Ubuntu, but it is a separate distribution and identifies itself as ID=pop. On this machine, resolvectl works normally. Nevertheless, ExpressVPN took its Ubuntu workaround path, bypassed systemd-resolved, and directly overwrote /etc/resolv.conf with:

nameserver 100.64.100.1

Because /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, this also writes into a file managed by systemd-resolved.

The ExpressVPN SDK then repeatedly logged errors including:

Temporary failure in name resolution
User IP fetch did not complete within 2s

Workaround

This is an unofficial, local workaround. It makes the Ubuntu-specific branch require an actual Ubuntu ID, allowing Pop!_OS to use the script's existing systemd-resolved integration.

Disconnect ExpressVPN first. Back up the script without overwriting an existing backup:

test ! -e /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix && \
sudo cp -a \
  /opt/expressvpn/bin/openvpn-updown.sh \
  /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix

Apply the one-line change:

sudo sed -i \
  's@if /usr/bin/systemctl --version | grep -q "systemd 255"; then@if grep -q "^ID=ubuntu$" /etc/os-release \&\& /usr/bin/systemctl --version | grep -q "systemd 255"; then@' \
  /opt/expressvpn/bin/openvpn-updown.sh

Validate the shell syntax and inspect the exact change:

bash -n /opt/expressvpn/bin/openvpn-updown.sh
sudo diff -u \
  /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix \
  /opt/expressvpn/bin/openvpn-updown.sh

The diff should show exactly one changed line:

-if /usr/bin/systemctl --version | grep -q "systemd 255"; then
+if grep -q "^ID=ubuntu$" /etc/os-release && /usr/bin/systemctl --version | grep -q "systemd 255"; then

Do not continue if the diff shows any other change.

Verification

After reconnecting, these commands should show that the systemd stub remains intact and the VPN interface owns the global DNS route:

For WireGuard:

readlink -f /etc/resolv.conf
grep '^nameserver' /etc/resolv.conf
resolvectl status wgexpressvpn0
timeout 8 getent ahostsv4 www.google.com

For Lightway:

readlink -f /etc/resolv.conf
grep '^nameserver' /etc/resolv.conf
resolvectl status tun0
timeout 8 getent ahostsv4 www.google.com

Expected results:

/run/systemd/resolve/stub-resolv.conf
nameserver 127.0.0.53

The VPN interface should show:

Current DNS Server: 100.64.100.1
DNS Domain: ~.

In my test, ExpressVPN logged Applying nameservers using systemd-resolved..., DNS worked immediately, and normal HTTPS traffic used the VPN exit.

I tested again with Lightway UDP and re-enabled ExpressVPN's malicious-site, tracker, and ad blockers without breaking connectivity. A packet capture showed DNS requests and responses only on tun0; no port 53 traffic left through the physical Ethernet interface. ExpressVPN's DNS leak and WebRTC leak tests both passed.

Rollback

Disconnect ExpressVPN, then restore the original file:

expressvpnctl disconnect
sudo cp -a \
  /opt/expressvpn/bin/openvpn-updown.sh.before-popos-dns-fix \
  /opt/expressvpn/bin/openvpn-updown.sh

Caveats

• This is not an official ExpressVPN patch.
• It modifies a root-owned vendor script. Verify the diff before reconnecting.
• An ExpressVPN update may overwrite the change.
• Do not blindly reapply this workaround after an update. Check whether ExpressVPN has fixed the detection logic first.
• The ExpressVPN daemon has a separate compiled systemd-255 check, so it may continue logging Ubuntu 24 DNS bug is present even though the patched DNS script uses systemd-resolved. Split tunneling was disabled during my tests.
• The better upstream fix would detect actual resolver capability, with a timeout, instead of inferring behavior from the systemd major version alone.

I had mini-swe-agent (using deepseek-v4-flash) build a harness based on itself that uses a GUI based on Pyxel game engine. My preference was for a GUI over a TUI, with the added ability for the AI to create drawings in the space. I wanted something like TempleOS or the C64 (iirc) which integrated text and graphics, so you could work on a sprite animation inside the GUI, see it, manipulate it, etc.

It’s still in a very primitive state. But it works. It’s talking to deepseek-v4-flash, and it’s doing pretty well, although there are some problems and some weirdness.

I’m posting because I want to gauge interest in the project.

I plan to make sure all the licensing is good. I need to check to see if the ai copy/pasted swe code into its base or not.

I plan to clean it up a little, use it a little more, and post a public repo under the MIT license, open source.

I wanted it to be something like the Logo programming language in the past.

Mostly, I want the evolution of this thing to super-enable people to make games with it and to do all kinds of other stuff. Right now, presently, I think young kids might go gaga over it. I know I would have.

Please let me know what you think.

I had mini-swe-agent (using deepseek-v4-flash) build a harness based on itself that uses a GUI based on Pyxel game engine. My preference was for a GUI over a TUI, with the added ability for the AI to create drawings in the space. I wanted something like TempleOS or the C64 (iirc) which integrated text and graphics, so you could work on a sprite animation inside the GUI, see it, manipulate it, etc.

It’s still in a very primitive state. But it works. It’s talking to deepseek-v4-flash, and it’s doing pretty well, although there are some problems and some weirdness.

I’m posting because I want to gauge interest in the project.

I plan to make sure all the licensing is good. I need to check to see if the ai copy/pasted swe code into its base or not.

I plan to clean it up a little, use it a little more, and post a public repo under the MIT license, open source.

I wanted it to be something like the Logo programming language in the past.

Mostly, I want the evolution of this thing to super-enable people to make games with it and to do all kinds of other stuff. Right now, presently, I think young kids might go gaga over it. I know I would have.

Please let me know what you think.