I decided to update to 4.2 from 4.1 today using in-place upgrade and after completing it, i don’t have any internet access on my qubes.
sys-net has a set ip and I’m able to ping with it and connect to websites. If I use one of my personal qubes are connect it with sys-firewall as the NetVM i get a dns error, if I use NetVM as sys-net for a personal qube it doesn’t work either. Sys-net net has Ethernet and network controller attached to it.
Can you make a ping from sys-firewall ?
I get Destination Host unreachable
Can you share the output of the following commands from sys-firewall:
sudo nft list ruleset
ip a
ip r
nft list ruleset
sudo nft list ruleset
# Warning: table ip nat is managed by iptables-nft, do not touch!
table ip nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
counter packets 0 bytes 0 jump PR-QBS
counter packets 0 bytes 0 jump PR-QBS-SERVICES
fib daddr type local counter packets 0 bytes 0 jump DOCKER
}
chain OUTPUT {
type nat hook output priority -100; policy accept;
ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade
oifname "vif*" counter packets 0 bytes 0 accept
oifname "lo" counter packets 2 bytes 104 accept
counter packets 163 bytes 12576 masquerade
}
chain PR-QBS {
ip daddr 10.139.1.1 udp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.1
ip daddr 10.139.1.1 tcp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.1
ip daddr 10.139.1.2 udp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.2
ip daddr 10.139.1.2 tcp dport 53 counter packets 0 bytes 0 dnat to 10.139.1.2
}
chain PR-QBS-SERVICES {
}
chain DOCKER {
iifname "docker0" counter packets 0 bytes 0 return
}
}
table ip raw {
chain QBS-PREROUTING {
}
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
counter packets 242 bytes 25096 jump QBS-PREROUTING
}
}
table ip mangle {
chain QBS-POSTROUTING {
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
counter packets 482 bytes 43424 jump QBS-POSTROUTING
}
}
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
chain INPUT {
type filter hook input priority filter; policy drop;
ct state invalid counter packets 0 bytes 0 drop
iifname "vif*" udp dport 68 counter packets 0 bytes 0 drop
ct state related,established counter packets 240 bytes 24992 accept
iifname "vif*" meta l4proto icmp counter packets 0 bytes 0 accept
iifname "lo" counter packets 2 bytes 104 accept
iifname "vif*" counter packets 0 bytes 0 reject with icmp type host-prohibited
counter packets 0 bytes 0 drop
}
chain FORWARD {
type filter hook forward priority filter; policy drop;
counter packets 0 bytes 0 jump DOCKER-USER
counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1
oifname "docker0" ct state related,established counter packets 0 bytes 0 accept
oifname "docker0" counter packets 0 bytes 0 jump DOCKER
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept
iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
ct state invalid counter packets 0 bytes 0 drop
ct state related,established counter packets 0 bytes 0 accept
counter packets 0 bytes 0 jump QBS-FORWARD
iifname "vif*" oifname "vif*" counter packets 0 bytes 0 drop
iifname "vif*" counter packets 0 bytes 0 accept
counter packets 0 bytes 0 drop
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
chain QBS-FORWARD {
}
chain DOCKER {
}
chain DOCKER-ISOLATION-STAGE-1 {
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
counter packets 0 bytes 0 return
}
chain DOCKER-ISOLATION-STAGE-2 {
oifname "docker0" counter packets 0 bytes 0 drop
counter packets 0 bytes 0 return
}
chain DOCKER-USER {
counter packets 0 bytes 0 return
}
}
table ip6 raw {
chain QBS-PREROUTING {
}
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
counter packets 4 bytes 264 jump QBS-PREROUTING
}
}
table ip6 mangle {
chain QBS-POSTROUTING {
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
counter packets 21 bytes 1312 jump QBS-POSTROUTING
}
}
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy drop;
iifname "lo" counter packets 4 bytes 264 accept
}
chain FORWARD {
type filter hook forward priority filter; policy drop;
counter packets 0 bytes 0 jump QBS-FORWARD
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
chain QBS-FORWARD {
}
}
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.138.16.229 jump qbs-10-138-16-229
}
chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifname != "vif*" ip saddr { 10.137.0.1, 10.137.0.3, 10.137.0.16, 10.137.0.18, 10.138.16.229 } drop
}
chain postrouting {
type filter hook postrouting priority raw; policy accept;
oifname != "vif*" ip daddr { 10.137.0.1, 10.137.0.3, 10.137.0.16, 10.137.0.18, 10.138.16.229 } drop
}
chain qbs-10-138-16-229 {
accept
reject with icmp admin-prohibited
}
}
table ip6 qubes-firewall {
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname != "vif*" accept
}
chain prerouting {
type filter hook prerouting priority raw; policy accept;
}
chain postrouting {
type filter hook postrouting priority raw; policy accept;
}
}
ip a
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:16:3e:5e:6c:00 brd ff:ff:ff:ff:ff:ff
inet 10.138.34.10/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe5e:6c00/64 scope link
valid_lft forever preferred_lft forever
3: vif14.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:b8:7b:57:91 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
ip r
ip r
default via 10.138.27.104 dev eth0 onlink
10.138.27.104 dev eth0 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
The nftables rules don’t seem right at all. You have a lot of old stuff and you don’t even have the new Qubes 4.2 tables and chains.
What is the current system version?
cat /etc/os-release
What are the current repos used for Qubes?
cat /etc/yum.repos.d/qubes-r4.repo
The version release comes back as 4.2.0 and the second cat command comes back as No such file or directory. The package source is empty and also the kernel in global config is 6.1.62-1.fc37
Can you run the commands in sys-firewall? Sorry, I should have been clearer.
That was my bad and here is the ouput:
user@sys-firewall:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
user@sys-firewall:~$ cat /etc/yum.repos.d/qubes-r4.repo
cat: /etc/yum.repos.d/qubes-r4.repo: No such file or directory
I see that you’re using Debian here. Have you tried switching sys-firewall to Fedora to see if you can get sys-firewall to work with ping for example?
Well I don’t have fedora installed as a template and i won’t be able to download it lol, originally I was using fedora for a while then switched over to Debian
That’s fine, we’ll try to find the problem in Debian.
Can you run the following commands in sys-firewall and share the output?
sudo journalctl -b | grep -i firewall
cat /etc/apt/sources.list.d/qubes-r4.list
I get a whole page of these errors
Jan 15 17:07:43 sys-firewall systemd[1]: Started ollama.service - Ollama Service.
Jan 15 17:07:43 sys-firewall systemd[1]: ollama.service: Main process exited, code=exited, status=203/EXEC
Jan 15 17:07:43 sys-firewall systemd[1]: ollama.service: Failed with result 'exit-code'.
Jan 15 17:07:47 sys-firewall systemd[1]: ollama.service: Scheduled restart job, restart counter is at 3208.
Then
cat /etc/apt/sources.list.d/qubes-r4.list
# Main qubes updates repository
deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] https://deb.qubes-os.org/r4.2/vm bookworm main
# deb-src https://deb.qubes-os.org/r4.2/vm bookworm main
# Qubes updates candidates repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] https://deb.qubes-os.org/r4.2/vm bookworm-testing main
# deb-src https://deb.qubes-os.org/r4.2/vm bookworm-testing main
# Qubes security updates testing repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] https://deb.qubes-os.org/r4.2/vm bookworm-securitytesting main
# deb-src https://deb.qubes-os.org/r4.2/vm bookworm-securitytesting main
# Qubes experimental/unstable repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] https://deb.qubes-os.org/r4.2/vm bookworm-unstable main
# deb-src https://deb.qubes-os.org/r4.2/vm bookworm-unstable main
# Qubes Tor updates repositories
# Main qubes updates repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm main
# deb-src tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm main
# Qubes updates candidates repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm-testing main
# deb-src tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm-testing main
# Qubes security updates testing repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm-securitytesting main
# deb-src tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm-securitytesting main
# Qubes experimental/unstable repository
# deb [arch=amd64 signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg] tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm-unstable main
# deb-src tor+http://deb.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.2/vm bookworm-unstable main
I forgot that the qube itself contains “firewall”, my bad.
Check the following service instead:
sudo journalctl -u qubes-iptables -b
Your repos are correct, so you should be using the new nftables rules. That’s weird.
I am seeing something similar…but only if I use my sys-net qube that I built based on a minimal template.
It can see the rest of the world fine (can ping google), but nothing using it (either sys-firewall or dom0 for updates or any other qube connected without the firewall) can ping anything.
Switching back to sys-net as distributed (not based on a minimal qube) allows things to work again.
My minimal sys-net is based on a salt recipe that works fine on 4.1 (I am using it right now in fact, on the desktop which I haven’t upgraded yet).
Edit to add: my laptop, which I upgraded to 4.2, was a clean install; this is happening there.
user@sys-firewall:~$ sudo journalctl -u qubes-iptables -b
Jan 15 14:14:03 sys-firewall systemd[1]: Starting qubes-iptables.service - Qubes base firewall settings...
Jan 15 14:14:04 sys-firewall qubes-iptables[887]: iptables: Applying firewall rules: OK
Jan 15 14:14:04 sys-firewall qubes-iptables[887]: ip6tables: Applying firewall rules: OK
Jan 15 14:14:04 sys-firewall systemd[1]: Finished qubes-iptables.service - Qubes base firewall settings.
It reports iptables instead of nft, which is not normal.
Can you use the nft command in your terminal?
Also, can you run this command?
dpkg -l | grep -i qubes
It’s almost like i have a merge between 4.1 and 4.2, lol it’s all 4.1 that would explain the issues im guessing
dpkg -l | grep -i qubes
ii libqubes-rpc-filecopy2 4.1.19+deb12u1 amd64 Qubes file copy protocol library
ii libqubesdb 4.1.17-1+deb12u1 amd64 QubesDB libs.
ii libvchan-xen 4.1.13-1+deb12u1 amd64 Qubes Xen core libraries
ii pulseaudio-qubes 4.1.32-1+deb12u1 amd64 Audio support for Qubes VM
ii python3-qubesdb 4.1.17-1+deb12u1 amd64 QubesDB python bindings.
ii python3-qubesimgconverter 4.1.19+deb12u1 amd64 Python package qubesimgconverter
ii qubes-core-agent 4.1.46-1+deb12u1 amd64 Qubes core agent
ii qubes-core-agent-dom0-updates 4.1.46-1+deb12u1 amd64 Scripts required to handle dom0 updates.
ii qubes-core-agent-nautilus 4.1.46-1+deb12u1 amd64 Qubes integration for Nautilus
ii qubes-core-agent-network-manager 4.1.46-1+deb12u1 amd64 NetworkManager integration for Qubes VM
ii qubes-core-agent-networking 4.1.46-1+deb12u1 amd64 Networking support for Qubes VM
ii qubes-core-agent-passwordless-root 4.1.46-1+deb12u1 amd64 Passwordless root access from normal user
ii qubes-core-qrexec 4.1.24-1+deb12u1 amd64 Qubes qrexec agent
ii qubes-gpg-split 2.0.70-1+deb12u1 amd64 The Qubes service for secure gpg separation
ii qubes-gui-agent 4.1.32-1+deb12u1 amd64 Makes X11 windows available to qubes dom0
ii qubes-img-converter 1.2.16-1+deb12u1 amd64 Qubes service for converting untrusted images into trusted ones.
ii qubes-input-proxy-sender 1.0.34-1+deb12u1 amd64 Provides Simple input events proxy
ii qubes-kernel-vm-support 4.1.19+deb12u1 amd64 Qubes VM kernel and initramfs modules
ii qubes-mgmt-salt-vm-connector 4.1.16-1+deb12u1 all Interface for managing VM from dom0
ii qubes-pdf-converter 2.1.19-1+deb12u1 amd64 The Qubes service for converting untrusted PDF files into trusted ones
ii qubes-repo-templates 4.1.2-1+deb12u1 amd64 Repository definition for Qubes OS VM template packages.
ii qubes-usb-proxy 1.1.5+deb12u1 amd64 USBIP wrapper to run it over Qubes RPC connection
ii qubes-utils 4.1.19+deb12u1 amd64 Qubes Linux utilities
ii qubes-vm-dependencies 4.1.24-1+deb12u1 amd64 Meta package with packages required in Qubes VM
ii qubes-vm-recommended 4.1.24-1+deb12u1 amd64 Meta package with packages recommended in Qubes VM
ii qubesdb 4.1.17-1+deb12u1 amd64 QubesDB management tools and daemon.
ii qubesdb-vm 4.1.17-1+deb12u1 amd64 QubesDB VM service.
ii xserver-xorg-input-qubes 4.1.32-1+deb12u1 amd64 X input driver for injecting events from qubes-gui-agent
ii xserver-xorg-qubes-common 4.1.32-1+deb12u1 amd64 Common functions for qubes xserver driver
ii xserver-xorg-video-dummyqbs 4.1.32-1+deb12u1 amd64 Dummy X video driver for qubes-gui-agent
Yes, all your packages are still on 4.1, so that might explain your problem.
From what I understand, sys-net is still working when you do pings and resolve domains, right? If that’s the case, you can set it as the update proxy for both dom0 and templates in Global Settings and try to restart the in-place upgrade from the beginning.
yes im currently using a web browser on my sys-net to type this haha. I think i will try that option to set it up as a proxy, but considering i did put sys-net as the NetVM for VMs and it wouldnt browse im not sure will have to test