What’s happening is this: When the VPN connection is off, LAN is working fine. As soon as I connect to the VPN, LAN stops working.
All I want is VPN internet access alongside access to a device on my LAN with a fixed IP address e.g. 192.168.1.77. Due to the way Qubes works, the normal “allow LAN access” setting in VPN apps doesn’t work.
Can someone please share what I need to do to accomplish this?
(I know doing internet and LAN access in separate qubes is “better” from a security standpoint, but that won’t do the job in my case.)
You haven’t provided sufficient information for any one to be able to
help you easily.
You have not said what VPN you are using, and how you have configured
it in the VPN qube and in Qubes.
I’ll take a guess and say that you have configured the VPN qube to pass all traffic down the VPN tunnel when it is active. You may have done
this deliberately or it may have been done for you by the VPN
application.
If the VPN limits are enforced on the VPN qube itself, then you must look
out the firewall settings that are set by the VPN application, and
modify them to allow traffic to the LAN. How you do this will depend on
what the VPN application does.
If the VPN limits are enforced on the upstream qube, (sys-for all
perhaps?), then you need to adjust the upstream firewall to allow
traffic to the LAN from that qube.
I’m working blind, but I hope there’s enough there to help.
I’m using Mullvad VPN, the desktop Linux application set up with their downloadable .deb package.
I set it up on a StandaloneVM (copied from debian-11), and it gets its network from sys-firewall.
(Then I have other AppVMs with firefox etc. that get their network from that VPN VM I just mentioned)
Does this provide enough info? I haven’t done any manual editing myself of anything, and I’m not sure exactly what the Mullvad VPN app’s “Allow LAN access” feature really does to the underlying firewall.
Does anyone here have the technical expertise to help me get LAN access (access to that particular LAN IP address 192.168.1.77) working alongside the VPN?
If you want to be able to access e.g. 192.168.1.77 set up an extra appVM for just that use case and attach it to a firewallVM with limited connection to just this given ip address and attach this firewallVM to your netVM. This way you make sure that you truly isolate the one thing from your vpn activities.
On the second though, can you elaborate what you mean by “attach”? And by netVM you mean the one with my VPN right? I like the concept of isolation, I’m just not sure if it will give me internet VPN and LAN IP access in the same vm ultimately. (Depends on what you mean exactly)
The way I suggested it will not give you both in one appVM - that is the idea of isolation. You will have two different routing (but they can run side by side). And if you need something in your appVM that is going through your vpn from the appVM that is routed to your home network (e.g. 192.168.178.77) you can transfer it between the appVMs without changing the routing.
I suggest you check some documentation if have not yet:
Routing through vpn: appVM-1(stuff you want to push through the tunnel) => vpnVM => firewallVM-1 (only allow the routes to your vpn servers unless you fixed that in your vpnVM already) => sys-firewall => sys-net (qube holding your network device);
Routing to home network: appVM-2(stuff you want to push to your home network) => FirewallVM-2 (only allow the routes to your home network [e.g. 192.168.178.77]; this way you make sure that apps in this qube do not anything else on the internet) => sys-firewall => netVM (qube holding your network device);
With this setup you can easily inspect if everything runs as intended by e.g. running “iftop” or “wireshark” in the given firewallVM. In my setup the networking qubes are set up as disposable qubes
This firewall rule could also be applied to FirewallVM-1.
I suspect that the OP will need to modify their VPN configuration to add a priority route to their LAN network that bypasses the VPN tunnel. I suspect that this can be handled with PostUp and PostDown commands for the tunnel — to create the bypass and remove it during VPN start and stop.
You could also put the rules from firewallVM-1 and firewallVM-2 in sys-firewall for my part I like to keep these things separate.
I suggested a way I would do it. There might be others.
P.s.: There is a thread about using the mullvad app in qubesOS. I came to the conclusion that it is too much tinkering to get it working - so I do it “old school”
I noticed that “sudo iptables -L” on the VPN vm (where Mullvad app is installed) gives me exactly the same results no matter what I choose (enabled or disabled LAN, kill switch, etc.) in the Mullvad app or even if I quit the app.
So now I don’t understand what to look for. I thought “sudo iptables -L” was the firewall settings but apparently I’m wrong. Can you point me in the right direction?
Here are my constant (always unchanged) “sudo iptables -L” in case it helps:
Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
DROP udp -- anywhere anywhere udp dpt:bootpc
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
DROP all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
QBS-FORWARD all -- anywhere anywhere
DROP all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain QBS-FORWARD (1 references)
target prot opt source destination
My use case is a bit uncommon: I use the Nix package manager which keeps its store in /nix/store - and the other LAN device is a Nix remote build machine. However Nix also happens to require internet access, therefore the problem.
The /nix/store tends to get big (gigabytes) so manually keeping build outputs from within it in sync between VMs is impractical.
That being said, a true solution would be appreciated. Let me reformulate:
How can I route all internet traffic (not LAN traffic) of a qube (e.g. Standalone qube made from debian-11 template) into another specific qube (e.g. whonis or vpn or plain old sys-firewall).
How can I route all LAN traffic of this same qube into plain old sys-firewall?
Those two combined would solve my problem. Any ideas on this @unman ?
Also this way there’d no need to mess with the VPN qube, keeping a nice separation of concerns (that @sm95 hinted at).
The issue is that in almost every case (whonix, Tor gateway,
sys-firewall) the routing table in that qube is designed to pass all
traffic upstream in the same way. For a Tor gateway the design is to
pass all traffic via Tor; for a VPN the design is to pass all traffic
via the VPN.
The only way to change this behaviour in Qubes is to “mess with” the
gateway, and how you do this will depend on how the gateway is
implemented.
Broadly speaking, these gateways will have rules in the prerouting
table that capture incoming traffic and redirect it to local ports.
What you must do is to insert a specific rule before those rules that
overrides that action.
It’s likely that the gateway has also disabled forwarding of traffic to
endure that traffic doesn’t sidestep the gateway - since this is what you
want you will also have to override that setting.
Neither of these are trivial actions.
If you must do this, it can be done.
A simpler solution is to compartmentalise, so you have one qube
connected to sys-firewall for the LAN traffic, (restricted with the Qubes
firewall), and one connected to the VPN/Tor.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
From what you write, it seems like mortals should not really be doing what I want to do, as things currently stand in Qubes. The way I see it, Qubes is only protecting mere mortals from shooting themselves in their feet.
I’ll whisper into the wind a feature request (Qubes 4.2 or later): Simple menu in Qubes Settings to give exceptions to LAN IP addresses.
For now, my current working sshuttle solution will have to do. I dare not try to mess with gateway stuff in qubes - too much risk of messing things up.
It’s in line with the core Qubes ethic of compartmentalisation that there is an easy way to do this.
You have one qube for LAN access, and one for general internet use.
This can be done very simply, by attaching to netvm and use of native
Qubes firewall.
Of course, you say - I want to do this with one qube.
Not only does Qubes protect everyone from shooting themselves in the
foot, but it encourages users to think about how they are working
online.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Update: This works far better, as it will only route internet stuff and therefore not mess with existing SSH connections and give fast LAN file transfer speeds between the LAN machines.
