First question that comes to mind is: do you have DNS resolution in that vm? i.e., opening a terminal and typing “host www.lastpass.com” returns some (IPv4) addresses?
lastpass uses load balancers, so their IP addresses are likely to change regularly.
Using the DNS resolution in the firewall is not great in this situation as the IPs are resolved upon qube starts, so if the IP behind the domain changes, the rule is obsolete.
Yeah, lastpass definitely has changed their IPs a few times. Running qvm-firewall --reload <vm> in theory should reload the table, and usually it has helped in the past
Still trying to track down my issue here and what caused it. I changed a couple things
which will check if YOUR_QUBE_NAME is running, and if yes, it reloads its firewall rules.
It’s not very resource-intensive, so you can run it every 2-3 minutes… or 5. I don’t know how often the lastpass IP changes and how often you use it.
In my lastpass VM, when I type in host lastpass.com, I get
;; communications error to 10.139.1.1#53: timed out
;; communications error to 10.139.1.1#53: timed out
;; communications error to 10.139.1.2#53: timed out
;; no servers could be reached
The result of cat /etc/resolve.conf in any of my VMs is
nameserver 10.139.1.1
nameserver 10.139.1.2
Arts, crafts and sciences uplift the world of being and are conducive to its exaltation
When I use another VM thats connected to my sys-firewall, i.e.
[sys-net] <-- [sys-firewall] <-- [qubes-forum]
When I do host lastpass.com I get
[user@qubes-forum ~]$ host lastpass.com
lastpass.com has address 184.25.196.20
lastpass.com mail is handled by 5 mxa-00771101.gslb.pphosted.com.
lastpass.com mail is handled by 5 mxb-00771101.gslb.pphosted.com.
Then in sys-firewall-lastpass when I do sudo nft list table ip qubes-firewall
I get
[user@sys-firewall-lastpass ~]$ sudo nft list table ip qubes-firewall
table ip qubes-firewall {
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname != "vif*" accept
ip saddr 10.137.0.14 jump qbs-10-137-0-14
}
chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifname != "vif*" ip saddr 10.137.0.14 drop
}
chain postrouting {
type filter hook postrouting priority raw; policy accept;
oifname != "vif*" ip daddr 10.137.0.14 drop
}
chain qbs-10-137-0-14 {
accept
reject with icmp admin-prohibited
}
}
These rules must be on the qube itself, not on the firewall qube.
Doing it this way will apply the rules to the netvm of the sys-firewall-lastpass qube, which is probably not what you want to do.
The rules are separated by app qube, so if you restrict certain IPs through the app qube firewall, the other qubes will still keep their original rules that allow all traffic. If you lose Internet access on other qubes, then something else is wrong.
doing qvm-firewall --reload lastpass in dom0 terminal does nothing
When I run host lastpass.com in the lastpass vm terminal, I get
Enabling the allow full access for 1 min option in the lastpass VM does not help. Shutting down both lastpass and sys-firewall-lastpass, enabling allow full access for like 10 min and then starting both again does not help either
But in the UI for that, those rules were greyed out since the “Allow all outgoing traffic” option was selected
After doing qvm-firewall sys-firewall-lastpass reset and then booting the lastpass + netvm pair, I still had the same issue
But then after shutting down all VMs, including another app vm + sys-firewall-[that app vm] pair with firewall rules, now it works and I can get an IP address from lastpass.com
Do you think those rules could be triggering a bug that was blocking port 53? I’ll see if this continues working
I guess that was it?
