VPN instructions for 4.2

User Support
83

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.

84

Good find, I missed that, that is why I am not telling you about my find, this code requires audit.

85

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
86

Audit is already happening, you do it, I do it, just do it.

87

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.

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
89

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.

90

You’re right, that’s a bug.
Reported here:

91

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.

92

@apparatus you removed ipv4 rule check by replacing it with ipv6 check, adding one new serious bug

93

Or not, seems correct, ignore.

94

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?

95

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.

96

Thanks, I tried to ping and there seem to be no errors. Everything goes through normally. TCP over Tor seems also to work.

97

Is TCP over clearnet working as well?
If not then maybe your ISP is blocking your VPN.

98

Yes, TCP over clearnet works fine. Its just that the vpn disconnects randomly and other times it stays for a longer period.

99

I am still using just the nftable branch of 1cho1ce.

So do I understand correctly that I should clone this repo:

Swich to and install the nftable branch and then apply this patch?:

Or how should I install this ?

100

You understood correctly.

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

102

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.