Whonix-Gateway broken after last upgrade on Qubes R4.1 (deprecated Qubes release)

Context: Qubes 4.1 with whonix 17 templates. Issue is whonix specific.

Trigger: after upgrading whonix templates (yesterday), prior upgrade was 5th of May.

Symptom: VMs connected to sys-whonix have NO internet access. (debian, hvm, anon-whonix, all). Happened right after the whonix template upgrades. sys-whonix is connected to Tor, circuits are fine, templates can apt-get update without issues…

What I tried:

  1. created a new sys-whonix. same problem: tor is connected but vms connected to this new gateway have no internet access:
[workstation user ~]% curl 1.1.1.1
curl: (7) Failed to connect to 1.1.1.1 port 80 after 0 ms: Couldn't connect to server
zsh: exit 7     curl 1.1.1.1
  1. revert packages? no versions besides latest available in repostory! checked with sudo apt-cache policy <package> . There are no cached packages in the system I could revert to.
  2. I have no backups to go back to… lesson learned.

I’M LEFT WITH NO INTERNET ACCESS!!! HELP

1 Like

Not possible.

1 Like

I have proof the upgrade is breaking the gateway template.

  1. I’ve downloaded again whonix gateway 17 template in dom0, and set it as template for sys-whonix. Sys-whonix works with this outdated template.
  2. I clone this outdated template, upgraded it, and set it as template for sys-whonix. BROKEN. Nothing connected to it has internet connection.

It is proven to be an issue caused by the upgrade.
I don’t know why other people are not reporting this issue… if for some mysterious reason it’s only affecting me , I imagine the whonix team will have to ignore it…

2 Likes

OMG

1 Like
1 Like

@aptcache were you able to solve this?

I experienced the same exact issue, I was on 4.1 and the update broke whonix connectivity, I temporarily restored connectivity by reinstalling the whonix gateway and not updating.

I have now made an in-place upgrade 4.2 using the
qubes-dist-upgrade and then I reinstalled whonix-gateway-17 and it’s still broken.

1 Like

What about installing a fresh template instead?

Any VPNs involved?

1 Like

I have been experiencing this issue, too.

I’ve been on Qubes R4.2 since before the issue began. One day in the last couple months, after upgrading whonix-gateway-17 template, my VMs lost connectivity through sys-whonix.

However, any VM running whonix-workstation-17 can access the Internet through sys-whonix just fine. Any VMs based on debian, fedora, or whonix-ws-16 CANNOT access the network.

Running tcpdump -vvvv -i eth0 in the VM shows a bunch of unanswered ARP requests for the sys-whonix IP address.

This is actually extremely frustrating, and while you might say, “just use Whonix workstation 17” that actually does not work for my application.

I would appreciate guidance troubleshooting this issue; it’s clearly related to some recent change. Unfortunately the arcane and obscure firewall rules and the general convoluted way networking is handled in Qubes and Whonix leaves me at a loss where to begin.

@adrelanos I’ve been using Whonix for years now without issue. This is a real showstopper for me and presumably others who haven’t bothered to sign up for yet another forum account. Assistance would be greatly appreciated.

1 Like

And no, there are no VPNs involved. sys-whonix connects directly to sys-firewall. And again, workstation 17 clients can still access the Internet through sys-whonix. And this issue only began after I updated gateway and workstation templates. So there must be some configuration change to blame.

1 Like

Dunno why I haven’t tried it before, but I can get networking working again when I manually add a static entry for sys-whonix to the ARP table. In the client VM, run sudo arp -s <sys-whonix IP address> fe:ff:ff:ff:ff:ff.

It also seems that DNS query address rewriting isn’t working, so also put your sys-whonix IP address in /etc/resolv.conf.

I would still very much like to get this properly fixed so I don’t have to manually add an ARP entry every time I boot a non-workstation-17 VM.

1 Like

Solution, probably:
See Anonymize Other Operating Systems chapter Gateway Configuration.

2 Likes

Thanks, that’s probably it. I wish there were a better way to document and communicate these quirks, especially when they’re first introduced.

I like how debian notifies users of certain breaking changes: A modal-ish screen during apt upgrade explaining the breaking changes that you must manually exit before the upgrade process continues.

Anyway, thanks for the assistance. I’ll make sure to give a small donation as a token of my appreciation for your work and help here.

1 Like