VPN instructions for 4.2

User Support
73

That’s exactly what I was looking for, but didn’t find anything.
During those 2 minutes I cannot even ping eg. 1.1.1.1, there seems to be no network connection.

I toyed a bit around and found out, when I disable “provides_network” the qube acts as expected and establishes an openvpn connection immediately.
Are you guys using debian(-minimal) or why am I the only one with this problem?

74

Personally I’m using debian templates and I didn’t try using it in fedora template.

1 Like
75

Kudos @1choice! This is exactly what I have been looking for!! Thank you for putting this together.

I was thinking about two clarifying questions

1) Would you suggest any changes to the provider’s .ovpn config to improve privacy and security?

For example the default sample here:

Has an extra “redirect-gateway def1” should I add it as well?

2) Would limiting ongoing connection on sys-vpn only to the VPN provider using qvm-firewall enhance the security of this setup?

Any other idea’s on how to absolutely prevent leaks ?

Thank you

76

Thanks for the patches to get VPNs working under 4.2 like they did under 4.1

I noticed that the Github site does not include the needed replacement files if you follow the Quick Setup Guide, resulting in a non working VPN. I only got it working after I saw this message and realized that there were more steps. Perhaps the Quick Setup Guide could include the steps above.

It all worked out in the end, so again, thanks.

77

Please help me Qubes R4.2.1 | Qubes-vpn-support | No connect VPN

79

You can report it in the pull request:

Saying that it has vulnerability but not telling where is it is unhelpful since there are people that use it and leaving them vulnerable is not good.

81

It’s as helpful as you saying that Qubes OS has 0-day vulnerability but you won’t say where it is.
I’ve looked at the patch and I couldn’t notice any obvious vulnerability. But I’m not a programmer myself so I could miss something obvious to you.

82

At a quick glance I see a (potential) IPv6 DNS leak in that pull request #71.

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