Firewall VM with Custom Rules behind a VPN = No Internet

[some.user7882]

Hi All,

Apologies for the delay in seeing your responses. Please see my comments below.

The tested websites are:
www.google.com
www.qubes-os.org

@unman

If you examine the qubes-firewall table in the fw below the proxy,
you’ll see that a single domain name can generate more than 1 IP
address in the rule.

Correct. I remember reading this, and @Rooftop’s comments, in the Qubes Firewall documentation. That would make perfect sense if not for the following fact:

The sites in question are still accessible via Firewall VM when the VPN-VM is not present in the chain.
This suggests to me that the access is crippled when introducing VPN-VM into the chain and not merely by fact that URLs are converted to IPs when rules are applied.

@unman

To add to the complexity, many websites load data from many domains, so
simply whitelisting one may not allow the website to load (properly).

Right. I have noticed this with some streaming websites.

@unman

What is the content of nft list table qubes-firewall

Running the above in the VPN VM returns the following:

table ip qubes-firewall {
	chain forward {
		type filter hook forward priority filter; policy drop;
		ct state established,related accept
		iifname != "vif*" accept
		ip saddr <Firewall.VM.ip.address> jump qbs-<Firewall-VM-ip-address>
	}

	chain qbs-<Firewall-VM-ip-address> {
		reject with icmp type admin-prohibited
	}
}

Note that this does not reflect the output of the qvm-firewall command in the FIrewallVM:
qvm-firewall <Firewall VM> list
0 accept www.google.com - - - - - -
1 accept www.qubes-os.org - - - - - -
2 accept - - - dns - - -
3 accept - icmp - - - - -
4 drop - - - - - - -

If I remove VPN-VM from the chain and connect Firewall VM directly to WIFI VM, I get this when running the nft command in the WIFI VM:

table ip qubes-firewall {
	chain forward {
		type filter hook forward priority filter; policy drop;
		ct state established,related accept
		iifname != "vif*" accept
		ip saddr Firewall.VM.ip.address> jump qbs-<Firewall-VM-ip-address>
	}

	chain qbs-<Firewall-VM-ip-address> {
		ip daddr { 172.217.23.4 } accept
		ip daddr { 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153 } accept
		ip daddr { Default.Route/DNS.IP } tcp dport 53 accept
		ip daddr { Default.Route/DNS.IP } udp dport 53 accept
		ip protocol icmp accept
		reject with icmp type admin-prohibited
		reject with icmp type admin-prohibited
	}
}

This matches the output of the qvm-firewall command in the FIrewallVM listed above

@unman

If you load the vpn client manually with --verb 6 (for openvpn), do you
see significant traffic when attempting to open the web site?

First test:
I performed this test and noticed an ongoing “ping” every 8s when looking at the journalctl qubes-vpn-handler log.
I then proceeded to configure the Firewall VM to allow all outgoing traffic.
I loaded the websites above on a web browser and was able to observe alterations in the traffic pattern log indicating that data was being exchanged. The websites loaded.

Second test:
I then proceeded to configure the Firewall VM as shown by qvm-firewall <Firewall VM> list above.
I again looked at the log and noticed the ongoing “ping” every 8s.
Finally, I attempted to load the websites. I noticed no change in the traffic pattern while the web browser attempted to load the websites. The browser eventually returned the page not found message. The traffic pattern remained unaltered throughout this process.

@Rooftop

For this situation you need a web proxy

Thanks fort the suggestion, though this sounds like adding yet another network service provider to the list. I would much rather figure out the issue at hand and avoid that, if possible, since I already have my reservations about trusting a VPN provider in the first place. Thanks again

SU