This would work on Qubes OS 4.2.
This wouldn’t work on Qubes OS 4.2.
Not sure what do you mean.
well that’s weird… It works, I don’t connect the old vpn qube to the internet, but sudo nft list ruleset gives me results …
Using the tasket main branch will put the old iptables rules converted to nftables rules in nftables but the rules themself won’t work for Qubes OS 4.2.
Here is the output of my old vpn qube from 4.1 ( I have changed nothing)
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
}
chain OUTPUT {
type nat hook output priority -100; policy accept;
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname "vif*" counter packets 0 bytes 0 accept
oifname "lo" counter packets 9 bytes 500 accept
counter packets 0 bytes 0 masquerade
}
chain PR-QBS {
}
chain PR-QBS-SERVICES {
}
}
table ip raw {
chain QBS-PREROUTING {
}
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
counter packets 18 bytes 1212 jump QBS-PREROUTING
}
}
table ip mangle {
chain QBS-POSTROUTING {
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
counter packets 18 bytes 1212 jump QBS-POSTROUTING
}
}
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 9 bytes 712 accept
iifname "vif*" meta l4proto icmp counter packets 0 bytes 0 accept
iifname "lo" counter packets 9 bytes 500 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;
iifname "eth0" counter packets 0 bytes 0 drop
oifname "eth0" counter packets 0 bytes 0 drop
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 drop;
oifname "eth0" skgid 979 counter packets 0 bytes 0 accept
oifname "lo" counter packets 14 bytes 932 accept
meta l4proto icmp skgid 979 counter packets 0 bytes 0 accept
}
chain QBS-FORWARD {
}
}
table ip6 raw {
chain QBS-PREROUTING {
}
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
counter packets 2 bytes 132 jump QBS-PREROUTING
}
}
table ip6 mangle {
chain QBS-POSTROUTING {
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
counter packets 2 bytes 132 jump QBS-POSTROUTING
}
}
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy drop;
iifname "lo" counter packets 2 bytes 132 accept
ct state established counter packets 0 bytes 0 accept
}
chain FORWARD {
type filter hook forward priority filter; policy drop;
iifname "eth0" counter packets 0 bytes 0 drop
oifname "eth0" counter packets 0 bytes 0 drop
counter packets 0 bytes 0 jump QBS-FORWARD
}
chain OUTPUT {
type filter hook output priority filter; policy drop;
oifname "eth0" skgid 979 counter packets 0 bytes 0 accept
oifname "lo" counter packets 2 bytes 132 accept
meta l4proto icmp skgid 979 counter packets 0 bytes 0 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
}
chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifname != "vif*" ip saddr { XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX } drop
}
chain postrouting {
type filter hook postrouting priority raw; policy accept;
oifname != "vif*" ip daddr { XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX, XXX.XXX.XXX.XXX } drop
}
}
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;
}
}
Ok got it. The rules get set but don’t work properly
Yes.
As Qubes OS 4.2 uses nftables, why would the command listing rules fail?
I meant that tasket vpn script without the patch won’t work in Qubes OS 4.2. I wasn’t clear enough.
Using fedora-38-xfce i use setenforce 0 after #!/bin/sh in /rw/config/rc.local but establishing a connection takes about 2 minutes.
Anyone else has this issue? Nothing that catches my eye in the journal.
Did you write setenforce at the beginning of rc.local script?
Indeed. Line 2. Between #!/bin/sh and the rest of the script.
Do you see anything related in the journalctl? maybe some timeout in VPN service?
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?
Personally I’m using debian templates and I didn’t try using it in fedora template.
1 Like
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
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.
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.