very strange problem that i ran into today and i do not know how to investigate. let’s focus on a curl to explain:
with my AppVM based on a fedora-41-xfce template, I can do a a curl without problem, everything works as expected
curl checkip.dyndns.com
<html><head><title>Current IP Check</title></head><body>Current IP Address: 51.75.83.24</body></html>
when changing the template to my debian-12-xfce template, here is the problem:
user@internet-vm:~$ curl -vvvvvvv http://checkip.dyndns.com
* Could not resolve host: checkip.dyndns.com
* Closing connection 0
curl: (6) Could not resolve host: checkip.dyndns.com
user@internet-vm:~$ dig +short checkip.dyndns.com
132.226.8.169
158.101.44.242
193.122.6.168
132.226.247.73
193.122.130.0
user@internet-vm:~$ curl -vvvvvvv http://checkip.dyndns.com
* Could not resolve host: checkip.dyndns.com
* Closing connection 0
curl: (6) Could not resolve host: checkip.dyndns.com
user@internet-vm:~$ curl -vvvvvvv 158.101.44.242
* Trying 158.101.44.242:80...
* Connected to 158.101.44.242 (158.101.44.242) port 80 (#0)
> GET / HTTP/1.1
> Host: 158.101.44.242
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 30 Jun 2025 17:14:01 GMT
< Content-Type: text/html
< Content-Length: 104
< Connection: keep-alive
< Cache-Control: no-cache
< Pragma: no-cache
< X-Request-ID: 016e2eb5ac5d051b5232244bad44047b
<
<html><head><title>Current IP Check</title></head><body>Current IP Address: 51.75.83.24</body></html>
* Connection #0 to host 158.101.44.242 left intact
basically:
DNS resolution works
curl through direct IP address works
curl with dns name does not.
It’s definitely related to the template as when I switch back to the fedora template, it works immediately (same resolv.conf…). how could i investigate such mystery?
VERY INTERESTING
after digging a bit more, it seems curl on my debian is using ipv6 for the dns request (but why? ). when forcing curl -4 it does work like a charm with working dns resolution
so i need to dig why my ipv6 is not routed and it’s probably not the debian template at fault.
but i’m interested to understand better: why curl would do on debian an udp6 dns resolution when /etc/resolv.conf is IPV4 format?
and when disabling ipv6, curl is still calling udp6 dns resolution. is qvm-features ipv4-only-qube ipv6 '' the right way to disable ipv6 (from Networking | Qubes OS)?
What’s equally interesting is that on two systems I’ve tested, creating
a new qube and testing with Fedora-41-xfce and debian-12-xfce does not show the behavior you report.
Can you create a vanilla qube and test that.
Can you reinstall the debian-12-xfce template and test with that.
These will help to hone in on where the issue may lie.
Also, you have not said what the netvm of your test qube is - that may
be relevant.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
thank you @solene@unman for your first answers, very appreciated.
disabling ipv6 with qvm-features --unset qube-name ipv6 does not show any impact
disabling in the debian AppVM at the kernel level ipv6 (through sysctl config in template) does not show any impact
i used a fresh debian-12-xfce template: still same behaviour
i changed the netvm to direct sys-firewall and it suddenly works.
immediate conclusion is that the netvm is at stake, which I do not understand (as it works with fedora based and not debian, there is something very strange here).
the netvm is a custom tunnel vpn one and it does rewrite some nft rules. i probably need to investigate here
table ip vpn {
chain prerouting {
type nat hook prerouting priority mangle; policy accept;
iifname "vif*" meta mark set 0x00000001
}
}
and there is this routing rule:
# ip rule show
0: from all lookup local
32765: from all fwmark 0x1 lookup 10
32766: from all lookup main
32767: from all lookup default
and this associated routing:
# ip route show table 10
default dev tun0 scope link
in this config, curl works with fedora-41-xfce but not with debian-12-xfce because of lack of dns resolution - except if I force curl -4 (view above).
i spent time to change/adapt/remove existing chains, and one change made curl works on both systems: i removed the above nftables prerouting marking rule and replaced it by an ip rule:
ip rule show
0: from all lookup local
32762: from all iif vif* [detached] lookup 10
32763: from all iif vif24.0 lookup 10
32764: from all iif vif23.0 lookup 10
32765: from all fwmark 0x1 lookup 10
32766: from all lookup main
32767: from all lookup default
now it works (on netvm vif 24.0 is associated to one system , vif23.0 to the other). i’m not satisfied with the current status because:
i do not understand why it works versus why it does not work with the marking
i would prefer to make it work with nft marking
i do not really know how and where to dig more to to make it clearer. In addition, i forgot to write that dnat-dns chain is removed on netvm (better to highlight it as problem is somehow related to dns).
). when forcing 