Local network access no longer working

[msiep]

I upgraded to 1.4.2 recently to get it to work with Fedora 30, but now my previous setup to allow access to my local network is no longer working. What had worked before was:

(1) Add these lines to the end of /rw/config/qubes-firewall-user-script:

  #    Allow forwarding of connections through upstream network device
  #    if they're to 192.168.9.x
  iptables -I FORWARD -o eth0 -d 192.168.9.0/24 -j ACCEPT
  iptables -I FORWARD -i eth0 -s 192.168.9.0/24 -j ACCEPT

(2) Add the following the middle of /rw/config/rc.local, immediately before the "Start tunnel service" section...

  # Allow access to home network for backup, etc.
  ip route add 192.168.9.0/24 via 10.137.0.5 dev eth0

...where 10.137.0.5 is the gateway for my "sys-vpn" VPN ProxyVM.

Has something changed recently that makes this approach not work? Is there a new approach that will work?

[tasket]

If you installed Qubes-vpn-support into the template, then your ip route command might not run in the same order vs the vpn daemon (openvpn also makes changes via ip route). If this is the case, go into the template and disable the service with systemctl disable qubes-vpn-handler.

You should also do iptables -L -v and check that your FORWARD rules are shown at the top where they need to be.

And of course both rc.local and qubes-firewall-user-script need to their executable bit set with chmod +x.

[msiep]

Thank you. I didn't install it in the template. I've got it working now, but what seems to have fixed it was putting the iptables rules inside qubes-firewall-user-script, before the section marked:

# This section executed only if vpn-handler-egress service _not_ enabled:

I had previously tried following the instruction at the top of qubes-firewall-user-script...

##  Note: For customization, add rules to a filename in firewall.d
##  other than '90_tunnel-restrict.'

...by putting my iptables lines in a file in firewall.d (with same permissions as 90_tunnel-restrict), but after that I got the "Link is up" message but it seemed that DNS was not working.

[tasket]

Ah, I think that explains it. The 1.4.x versions use 'qubes-firewall.d/90_tunnel-restrict' script, not 'qubes-firewall-user-script'. So it looks like you have same/similar firewall script running twice (Qubes executes 'qubes-firewall-user-script' last).

I suggest deleting the commands in 'qubes-firewall-user-script' except for the two custom rules, and removing the added rules from '90_tunnel-restrict'. That should allow future updates to firewall rules to take place while retaining your own rules.

---

Cautionary note: Qubes' security model suggests that access to different network types (such as LAN vs VPN) be accessed via different proxy VMs instead of creating this type of routing exception. Devs have discussed this before and consensus was that VPN users wanting to access their LAN should connect their appVMs to a sys-firewall type VM (plain proxyVM) that leads straight to sys-net. The assumption here is that having any one appVM access both LAN and VPN simultaneously is a security risk, so normally a VPN user would be expected to put their VPN activities in one set of appVMs connected to sys-vpn, and put LAN activities in different appVMS that are connected to sys-firewall or other proxy connected to sys-net directly.

Qubes users typically know what their doing, and you probably have good reasons for setting networking up this way, but I thought I'd mention it anyway. :)

[msiep]

I started to try to do that, but found that both qubes-firewall-user-script and qubes-firewall.d/90_tunnel-restrict are links to proxy-filewall-restrict.

Thanks for the cautionary note. I appreciate it.

[tasket]

Assuming both links point to /rw/config, you could delete qubes-firewall-user-script or replace the link with an empty file. As it is, having qubes firewall execute the script twice is not a good idea.

[msiep]

I ended up converting qubes-firewall-user-script from a link to a regular file, and putting my custom rules in there, as you recommended. That has been working fine. Thank you!