search

tasket / Qubes-vpn-support

VPN configuration in Qubes OS
GNU General Public License v3.0
126 stars 28 forks source link

Qubes-vpn-support stops working after upgrade to 4.1 #65

Closed tetrahedras closed 1 year ago

tetrahedras commented 2 years ago

Using both fedora-34 and debian-11 templates, Qubes-tunnel and Qubes-vpn-support no longer work after upgrade to Qubes 4.1.

See discussion here: https://forum.qubes-os.org/t/qubes-tunnel-blocking-all-traffic-including-vpn/9305/5

jorgejones7711 commented 2 years ago

Same here. Worked fine with fedora 33 and earlier versions, but 34 and 35 (in testing) don't work. I know the author has a preference for debian, but it would be nice to see an effort to support fedora 34.

tetrahedras commented 2 years ago

On Fri, May 13, 2022 at 07:27:45PM -0700, jorgejones7711 wrote:

Same here. Worked fine with fedora 33 and earlier versions, but 34 and 35 (in testing) don't work. I know the author has a preference for debian, but it would be nice to see an effort to support fedora 34.

I would be happy if it worked with Debian, but it doesn't even seem to do that!

tetrahedras commented 2 years ago

Found a solution here: https://github.com/QubesOS/qubes-issues/issues/7261 https://forum.qubes-os.org/t/user-tor-vpn-internet-4-1-broken/6900/8

I had to do the following to get this all up and working:

  1. in the qubes-vpn-handler.service unit file, change the check condition directory from vpn-handler to qubes-vpn-handler
  2. Check which ARP request was failing using sudo ip neigh in the VPN VM
  3. Manually create an ARP record in the VPN VM using sudo arp -s VPN_ENDPOINT_IP -i eth0 fe:ff:ff:ff:ff:ff
  4. Ensure the VPN VM is connected to sys-whonix. It didn't work at all with the regular firewall.

The problem (as described in the links above) is that Qubes 4.1 changed how it handles ARP.

tetrahedras commented 2 years ago

Related issue: https://github.com/QubesOS/qubes-issues/issues/7123#issuecomment-1136277213

tasket commented 2 years ago

Interesting. But I wonder if I somehow ended up with an atypical configuration since I've been using 4.1 since alpha and have not re-installed it, only updated it. I've been using several different VPN services without issues.

Need to investigate...

(see Update below)

tetrahedras commented 2 years ago

On Thu, Jun 02, 2022 at 06:48:02PM -0700, tasket wrote:

Interesting. But I wonder if I somehow ended up with an atypical configuration since I've been using 4.1 since alpha and have not re-installed it, only updated it. I've been using several different VPN services without issues.

Need to investigate...

If only I could figure out what was atypical about my configuration :)

I created quite a few new VMs, installed from scratch, used different VPN services... all without issue.

tasket commented 2 years ago

Update: Looks like my Qubes config is normal, however I turned on the 'egress' option in my sys-vpn config at some point. This allowed ARP and DNS to work regardless of which template I used.

Regardless of whether its a fresh Qubes install on a different machine or my regular Qubes system, the other reports of it being specific to fedora-34 template appear accurate. While I did have an odd delayed-startup issue with a debian-11 sys-vpn (with no egress) that appears to be resolved with recent Debian updates.

IIRC there have been at least two prior issues with Fedora templates, for which Debian required no workaround or was only temporarily affected. This could be yet another instance.... and its a good time to remind ppl that Fedora is an unstable distro; even Qubes devs appear to wish they had settled on something different (like Debian or Alpine) or at least waiting for help in replacing it in Qubes. I heartily suggest switching your sys-vpn instances to the debian-11 template; IMO it has been rock-solid for this purpose and all others.

For now, specifying vpn-handler-egress (mentioned in the Qubes-vpn-handler docs) in the sys-vpn services will allow fedora-34-based VMs to work. This will remove protection of accidental clearnet access from within the sys-vpn; I think for most ppl this would not be an issue – and it may even become the default setting in future releases. Most ppl shouldn't be trying to do 'other interesting things' inside their sys-vpn VM anyway, and that's the main scenario where the default anti-egress group restriction offers protection.

So the workarounds are: Switch to debian-11 or enable the egress firewall mode.