Qubes R4.2.1 | Qubes-vpn-support | No connect VPN

Good afternoon, please help me!
Internet does not work in qube OpenVPN

Qubes R4.2.1
Debian-12

config with vpn-client.conf:
where added: redirect-gateway def1, DNS from OpenDNS

We used the updated Qubes-vpn-support script from @1cho1ce
(on early versions of Qubes everything was fine until nftables appeared)

git clone GitHub - 1cho1ce/Qubes-vpn-support: VPN configuration in Qubes OS
cd Qubes-vpn-support
git checkout replace-iptables-with-nftables

Chain 1:
sys-net - sys-firewall - sys-vpn - work | No Internet in sys-vpn, work
Chain 2:
sys-net - sys-firewall - sys-vpn - sys-whonix - work | No Internet in sys-vpn, work - connect!

I checked 1 chain via ping 8.8.8.8 (no packets) or Firefix opening a site in each cube, I can’t understand the reason, maybe in DNS
When running sys-vpn I get sys-vpn: Link is UP

nftables in sys-vpn:

sudo nft list ruleset
table ip qubes {
set downstream {
type ipv4_addr
elements = { 10.137.0.11 }
}

set allowed {
type ifname . ipv4_addr
elements = { “vif41.0” . 10.137.0.11 }
}

chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifgroup 2 goto antispoof
ip saddr @ downstream counter packets 0 bytes 0 drop
}

chain antispoof {
iifname . ip saddr @ allowed accept
counter packets 0 bytes 0 drop
}

chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifgroup 2 accept
oif “lo” accept
masquerade
}

chain input {
type filter hook input priority filter; policy drop;
jump custom-input
ct state invalid counter packets 0 bytes 0 drop
iifgroup 2 udp dport 68 counter packets 0 bytes 0 drop
ct state established,related accept
iifgroup 2 meta l4proto icmp accept
iif “lo” accept
iifgroup 2 counter packets 0 bytes 0 reject with icmp host-prohibited
counter packets 1 bytes 576
}

chain forward {
type filter hook forward priority filter; policy drop;
jump custom-forward
ct state invalid counter packets 0 bytes 0 drop
ct state established,related accept
oifgroup 2 counter packets 0 bytes 0 drop
}

chain custom-input {
}

chain custom-forward {
iifgroup 9 oifgroup 2 accept
iifgroup 2 oifgroup 9 accept
iifgroup 1 drop
oifgroup 1 drop
}

chain output {
type filter hook output priority filter; policy drop;
oifgroup 1 meta skgid 993 accept
oif “lo” accept
meta l4proto icmp meta skgid 993 accept
}

chain dnat-dns {
type nat hook prerouting priority dstnat; policy accept;
iifgroup 2 ip daddr 10.139.1.1 tcp dport 53 dnat to 208.67.220.220
iifgroup 2 ip daddr 10.139.1.1 udp dport 53 dnat to 208.67.220.220
iifgroup 2 ip daddr 10.139.1.2 tcp dport 53 dnat to 208.67.220.220
iifgroup 2 ip daddr 10.139.1.2 udp dport 53 dnat to 208.67.220.220
}
}
table ip6 qubes {
set downstream {
type ipv6_addr
}

set allowed {
type ifname . ipv6_addr
}

chain antispoof {
iifname . ip6 saddr @ allowed accept
counter packets 0 bytes 0 drop
}

chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifgroup 2 goto antispoof
ip6 saddr @ downstream counter packets 0 bytes 0 drop
}

chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oifgroup 2 accept
oif “lo” accept
masquerade
}

chain _icmpv6 {
meta l4proto != ipv6-icmp counter packets 0 bytes 0 reject with icmpv6 admin-prohibited
icmpv6 type { nd-router-advert, nd-redirect } counter packets 0 bytes 0 drop
accept
}

chain input {
type filter hook input priority filter; policy drop;
jump custom-input
ct state invalid counter packets 0 bytes 0 drop
ct state established,related accept
iifgroup 2 goto _icmpv6
iif “lo” accept
ip6 saddr XXXX::/64 udp dport 546 accept
meta l4proto ipv6-icmp accept
counter packets 0 bytes 0
}

chain forward {
type filter hook forward priority filter; policy drop;
jump custom-forward
ct state invalid counter packets 0 bytes 0 drop
ct state established,related accept
oifgroup 2 counter packets 0 bytes 0 drop
}

chain custom-input {
}

chain custom-forward {
iifgroup 9 oifgroup 2 accept
iifgroup 2 oifgroup 9 accept
iifgroup 1 drop
oifgroup 1 drop
}

chain output {
type filter hook output priority filter; policy drop;
oifgroup 1 meta skgid 993 accept
oif “lo” accept
meta l4proto icmp meta skgid 993 accept
}

chain dnat-dns {
type nat hook prerouting priority dstnat; policy accept;
}
}
table ip qubes-firewall {
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname != “vif*” accept
ip saddr 10.137.0.11 jump qbs-10-137-0-11
}

chain prerouting {
type filter hook prerouting priority raw; policy accept;
iifname != “vif*” ip saddr 10.137.0.11 drop
}

chain postrouting {
type filter hook postrouting priority raw; policy accept;
oifname != “vif*” ip daddr 10.137.0.11 drop
}

chain qbs-10-137-0-11 {
accept
reject with icmp admin-prohibited
}
}
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;
}
}
table inet qubes-nat-accel {
flowtable qubes-accel {
hook ingress priority filter
devices = { eth0, lo, vif41.0 }
}

chain qubes-accel {
type filter hook forward priority filter + 5; policy accept;
meta l4proto { tcp, udp } iifgroup 2 oifgroup 1 flow add @ qubes-accel
counter packets 4471 bytes 2697580
}
}

If sudo openvpn ‘config’, then it works
I think the problem is in DNS or nftables

Please help me, it’s already 3 days of bad experience, thank you!
Please do not suggest WireGuard or any other method other than the Qubes-vpn-support script

Maybe DNS is not working and ICMP is blocked by the VPN server?
Try this in work qube for chain 1:

curl https://1.1.1.1

Did you run it in sys-vpn and test the connection in sys-vpn?
What DNS do you have there in /etc/resolv.conf when you start openvpn manually?
Are you able to ping 8.8.8.8? Or did you just check whether Firefox will open the site or not?

Thank you for your time

  1. I try for 1 chain qube work:

curl https://1.1.1.1
sys-net - sys-firewall - sys-vpn - work
response: Failed to connect to 1.1.1.1 port 443 after 134237 ms: Couldn’t connect to server

  1. Yes, I start it in sys-vpn, checking the VPN, the connection was successful (Initialization Sequence Completed).

Create qube, start sudo openvpn config to check paths in /etc/resolv.conf:

nameserver 10.139.1.1
nameserver 10.139.1.2

I performed ping 8.8.8.8 and launched Firefox - all sites open, VPN is working
This works without installing Qubes-vpn-support

Having installed the script in sys-vpn, access to other qubes stop working and sites inside qubes sys-vpn do not open and there is no ping

Do you have any errors in the service log?

sudo systemctl status qubes-vpn-handler.service

Still no idea why chain 2 works and chain 1 don’t.

No errors found in sys-vpn

sudo systemctl status qubes-vpn-handler.service

qubes-vpn-handler.service - VPN Client for Qubes proxyVM
Loaded: loaded (/lib/systemd/system/qubes-vpn-handler.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/qubes-vpn-handler.service.d
└─00_example.conf
Process: 796 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup --check-firewall (code=exited, status=0/SUCCESS)
Process: 805 ExecStartPre=/usr/lib/qubes/qubes-vpn-setup --pre-start (code=exited, status=0/SUCCESS)
Process: 815 ExecStartPost=/usr/lib/qubes/qubes-vpn-setup --post-start (code=exited, status=0/SUCCESS)

Error in Firefox qube sys-vpn open site:

Hmm. We’re having trouble finding that site.

If you entered the right address, you can:

Try again later
Check your network connection
Check that Firefox has permission to access the web (you might be connected but behind a firewall)

Ping 8.8.8.8 no packets in sys-vpn

Should Ping go through the SYS-VPN during the script and open inside the sys-vpn qube sites in Firefox?

Check the service log in journalctl:

sudo journalctl -u qubes-vpn-handler.service

Specifically openvpn connection log.

Ping and curl/firefox should work in sys-vpn qube.

Everything seems stable

[server] Peer Connection Initiated with [AF_INET]

There is no ping, as well as sites in sys-vpn, but a peculiarity was discovered if you create a qube from whonix-workstation there is no Internet. Сreate a qube from fedora or debian, everything works.

Does workstation from whonix cut all traffic except Tor?
Сhecked sudo openvpn without the Qubes-vpn-support script and directed it to qube from the whonix-workstation machine - it doesn’t work

Сreate a chain:

sys-net - sys-firewall - sys-vpn - sys-wireguard - qube-whonix-workstation / there is a connection!

Unclear, because wireguard uses non-TOR traffic

Can you post the whole log?
You can remove IP or other sensitive info from it.

Whonix workstations can only work when connected to Whonix gateway qube.

Just popping in to say that Qubes-vpn-support only supports Qubes 4.0 and 4.1; currently it can’t work on 4.2. I haven’t had time to rework it for the new firewall/routing interface, as my extra time has gone into wyng-backup.

You may want to look at some of the 3rd party modifications that make it nftables compatible, such as this one. Note that I have not yet reviewed this code.