Yes, there seems to be an issue with IPv6 DNS.
I guess instead of:
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${qubes_dns_ip6[$i]}
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${qubes_dns_ip6[$i]}
else
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${qubes_dns_ip6[0]}
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${qubes_dns_ip6[0]}
it should be:
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${vpn_dns_ip6[$i]}
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${vpn_dns_ip6[$i]}
else
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${vpn_dns_ip6[0]}
nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${vpn_dns_ip6[0]}
And if no Qubes OS virtual IPv6 DNS servers are used then the IPv6 DNS from VPN provider wonât be used and qubes will use their own IPv6 DNS servers. I saw a pull request from 1choice to add virtual IPv6 DNS support to Qubes OS so I guess that was related to this change. But anyway this was an issue in original Qubes-vpn-support as well since it didnât handle IPv6 DNS at all.
And if no DNS is provided by VPN server then requests to virtual DNS IPs will leak from qubes. But this was an issue in original Qubes-vpn-support as well.
Good find, I missed that, that is why I am not telling you about my find, this code requires audit.
Well, you did your own audit and found a bug, but you wonât tell anyone about it so it could be fixed.
@barto did a quick audit and found an issue and reported it so now it could be fixed.
I see no reason why you choose to conceal the bug. What kind of audit do you expect for this code? From some known security audit organization?
As I see it the users should check the code to the best of their abilities and report the issue if they found it so it could be fixed.
1 Like
Audit is already happening, you do it, I do it, just do it.
The point is that my skills are not enough to find the vulnerability that youâre talking about.
What if someone else besides you will find the same vulnerability that youâre talking about and instead of reporting it will just say the same thing as you âyes, there is a vulnerability but I wonât tell you what it isâ and the issue will still persist. Itâs unproductive.
solene
June 26, 2024, 4:45pm
88
If everyone was acting like this, we would never patch software upstream and a few people would compile from sources with local patch of issues they found. This would be unbearable.
1 Like
LOL why you flagged my posts about vulnerability, you think it was a joke? Time to lough now:
The vulnerabilit - 1choice added forwarding rule from vpn to any vm and now anyone from vpn server can connect any vm, he also decided not use interface name in the rule and replaced it with 9, making it less invisible.
Youâre right, thatâs a bug.
Reported here:
tasket:master
â 1cho1ce:replace-iptables-with-nftables
There are a few errors in the PR with allowing traffic from VPN to qubes and typ⌠os related to IPv6.
This was discussed here:
https://forum.qubes-os.org/t/vpn-instructions-for-4-2/20738/78
<details>
<summary>Here is a patch:</summary>
```
diff --git a/files-main/proxy-firewall-restrict b/files-main/proxy-firewall-restrict
index a3aba10..8142ad2 100644
--- a/files-main/proxy-firewall-restrict
+++ b/files-main/proxy-firewall-restrict
@@ -22,11 +22,9 @@ nft chain ip6 qubes forward '{ policy drop; }'
nft insert rule ip6 qubes custom-forward oifgroup 1 drop
nft insert rule ip6 qubes custom-forward iifgroup 1 drop
-# Accept forward traffic between dowstream (vif+, group 2) and VPN interface (group 9)
+# Accept forward traffic from dowstream (vif+, group 2) to VPN interface (group 9)
nft insert rule ip qubes custom-forward iifgroup 2 oifgroup 9 accept
-nft insert rule ip qubes custom-forward iifgroup 9 oifgroup 2 accept
nft insert rule ip6 qubes custom-forward iifgroup 2 oifgroup 9 accept
-nft insert rule ip6 qubes custom-forward iifgroup 9 oifgroup 2 accept
# Block INPUT from tunnel(s):
nft chain ip qubes input '{ policy drop; }'
diff --git a/files-main/qubes-vpn-ns b/files-main/qubes-vpn-ns
index 62510d4..d510954 100644
--- a/files-main/qubes-vpn-ns
+++ b/files-main/qubes-vpn-ns
@@ -85,11 +85,11 @@ up)
if [[ ${#vpn_dns_ip6[@]} != 0 ]] && [[ ${#qubes_dns_ip6[@]} != 0 ]]; then
for i in $(seq 0 $((${#qubes_dns_ip6[@]} - 1))); do
if [[ $i < ${#vpn_dns_ip6[@]} ]] ; then
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${qubes_dns_ip6[$i]}
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${qubes_dns_ip6[$i]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${vpn_dns_ip6[$i]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${vpn_dns_ip6[$i]}
else
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${qubes_dns_ip6[0]}
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${qubes_dns_ip6[0]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${vpn_dns_ip6[0]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${vpn_dns_ip6[0]}
fi
done
fi
diff --git a/files-main/qubes-vpn-setup b/files-main/qubes-vpn-setup
index 995ae33..f9b3512 100755
--- a/files-main/qubes-vpn-setup
+++ b/files-main/qubes-vpn-setup
@@ -53,7 +53,7 @@ firewall_link() {
case "$1" in
--check-firewall)
for i in 1 2 3; do
- if (nft -j -s list chain ip qubes custom-forward && nft -j -s list chain ip qubes custom-forward) | python3 -c "
+ if (nft -j -s list chain ip qubes custom-forward && nft -j -s list chain ip6 qubes custom-forward) | python3 -c "
import sys, json;
def main():
rule_out_ipv4_exists = False
```
</details>
You can apply the patch using this command:
```
~/Qubes-vpn-support$ git apply /path/to/patch
```
Additional notes:
If no Qubes OS virtual IPv6 DNS servers are used then the IPv6 DNS from VPN provider wonât be used and qubes will use their own IPv6 DNS servers. I saw a pull request from 1choice to add virtual IPv6 DNS support to Qubes OS so I guess that was related to this change.
If no DNS is provided by VPN server then requests to virtual DNS IPs will leak from qubes. I guess it's better to use some default DNS like 9.9.9.9 in case no DNS will be provided by VPN.
Also note that the default firewall rules in qubes are blocking incoming connections so this will only affect qubes with custom firewall rules that allow incoming connections.
@apparatus you removed ipv4 rule check by replacing it with ipv6 check, adding one new serious bug
Or not, seems correct, ignore.
Hey, Iâm using the guide by @1choice .
Recently the connection to the vpn has begun to disconnect and connect in 2-3 min intervals, sometimes even less. Other times it stays for 1-2 hours until it starts to disconnect. Reinstalling does not help, the servers of the vpn show that theyâre functioning properly.
The netvm of the vpn vm is sys-firewall. Iâm using a disp kicksecure minimal template for the vpn. A month ago everything worked without any interruptions. Traffic through sys-firewall shows no interruptions and sys-whonix is also working without any problems.
Does someone have the same issue or know of a solution to this problem?
Maybe itâs some issue with your ISP or VPN provider.
Try to ping the VPN server IP address from sys-firewall when itâll start to disconnect.
Or you can try to connect to your VPN using TCP over Tor for a test to see if your ISP has some issue with routing to your VPN server.
Thanks, I tried to ping and there seem to be no errors. Everything goes through normally. TCP over Tor seems also to work.
Is TCP over clearnet working as well?
If not then maybe your ISP is blocking your VPN.
Yes, TCP over clearnet works fine. Its just that the vpn disconnects randomly and other times it stays for a longer period.
Mirai
September 26, 2024, 11:19pm
99
I am still using just the nftable branch of 1cho1ce.
So do I understand correctly that I should clone this repo:
VPN configuration in Qubes OS
Swich to and install the nftable branch and then apply this patch?:
tasket:master
â 1cho1ce:replace-iptables-with-nftables
There are a few errors in the PR with allowing traffic from VPN to qubes and typ⌠os related to IPv6.
This was discussed here:
https://forum.qubes-os.org/t/vpn-instructions-for-4-2/20738/78
<details>
<summary>Here is a patch:</summary>
```
diff --git a/files-main/proxy-firewall-restrict b/files-main/proxy-firewall-restrict
index a3aba10..8142ad2 100644
--- a/files-main/proxy-firewall-restrict
+++ b/files-main/proxy-firewall-restrict
@@ -22,11 +22,9 @@ nft chain ip6 qubes forward '{ policy drop; }'
nft insert rule ip6 qubes custom-forward oifgroup 1 drop
nft insert rule ip6 qubes custom-forward iifgroup 1 drop
-# Accept forward traffic between dowstream (vif+, group 2) and VPN interface (group 9)
+# Accept forward traffic from dowstream (vif+, group 2) to VPN interface (group 9)
nft insert rule ip qubes custom-forward iifgroup 2 oifgroup 9 accept
-nft insert rule ip qubes custom-forward iifgroup 9 oifgroup 2 accept
nft insert rule ip6 qubes custom-forward iifgroup 2 oifgroup 9 accept
-nft insert rule ip6 qubes custom-forward iifgroup 9 oifgroup 2 accept
# Block INPUT from tunnel(s):
nft chain ip qubes input '{ policy drop; }'
diff --git a/files-main/qubes-vpn-ns b/files-main/qubes-vpn-ns
index 62510d4..d510954 100644
--- a/files-main/qubes-vpn-ns
+++ b/files-main/qubes-vpn-ns
@@ -85,11 +85,11 @@ up)
if [[ ${#vpn_dns_ip6[@]} != 0 ]] && [[ ${#qubes_dns_ip6[@]} != 0 ]]; then
for i in $(seq 0 $((${#qubes_dns_ip6[@]} - 1))); do
if [[ $i < ${#vpn_dns_ip6[@]} ]] ; then
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${qubes_dns_ip6[$i]}
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${qubes_dns_ip6[$i]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${vpn_dns_ip6[$i]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${vpn_dns_ip6[$i]}
else
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${qubes_dns_ip6[0]}
- nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${qubes_dns_ip6[0]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} tcp dport 53 dnat to ${vpn_dns_ip6[0]}
+ nft add rule ip6 qubes dnat-dns iifgroup 2 ip6 daddr ${qubes_dns_ip6[$i]} udp dport 53 dnat to ${vpn_dns_ip6[0]}
fi
done
fi
diff --git a/files-main/qubes-vpn-setup b/files-main/qubes-vpn-setup
index 995ae33..f9b3512 100755
--- a/files-main/qubes-vpn-setup
+++ b/files-main/qubes-vpn-setup
@@ -53,7 +53,7 @@ firewall_link() {
case "$1" in
--check-firewall)
for i in 1 2 3; do
- if (nft -j -s list chain ip qubes custom-forward && nft -j -s list chain ip qubes custom-forward) | python3 -c "
+ if (nft -j -s list chain ip qubes custom-forward && nft -j -s list chain ip6 qubes custom-forward) | python3 -c "
import sys, json;
def main():
rule_out_ipv4_exists = False
```
</details>
You can apply the patch using this command:
```
~/Qubes-vpn-support$ git apply /path/to/patch
```
Additional notes:
If no Qubes OS virtual IPv6 DNS servers are used then the IPv6 DNS from VPN provider wonât be used and qubes will use their own IPv6 DNS servers. I saw a pull request from 1choice to add virtual IPv6 DNS support to Qubes OS so I guess that was related to this change.
If no DNS is provided by VPN server then requests to virtual DNS IPs will leak from qubes. I guess it's better to use some default DNS like 9.9.9.9 in case no DNS will be provided by VPN.
Or how should I install this ?
You understood correctly.
Mirai
September 27, 2024, 8:02pm
101
How critical is it to install the patch? Have been using it without it for almost a yearâŚ
Regularly checked for leaks (ipleak.net and dnsleaktest.com ) and nothing every leaked (hopefully).
I am using mullvad and proton with the default wireguard configuration. No idea how ipv6 ins handled here
Itâs not critical. If the qubes connected to the sys-vpn have the default firewall rules (no open ports) then it wouldnât affect you.