Moving from 4.1 to 4.2 gives trouble to dante socks server

User Support General
1

In Qubes 4.1 I am easily able to run the dante socks5 proxy on Fedora 38, which has a package for dante (called dante-server). I run dante on a VM that is set up to provide network. Then, on a client VM, I can run Firefox, Thunderbird, ssh, etc. The client VM is configured to use my dante VM as its NetVM. The dante VM is configured to use sys-firewall as its NetVM.

This lets me filter my outbound network connections from the client VM using DNS names that are resolved at runtime, so I can restrict connections to load balanced services. I can also filter by fixed IPs. It works really well; streaming video/audio chat, IMAP, SMTP, SSH all work perfectly, as long as I include the proper DNS entries or IP addresses into the /etc/sockd.conf file on the dante VM. This even works for UDP based services (video frequently uses UDP). I can make sure that my email only accesses allowed servers. I can make sure that only MS Teams is available and not WebEx, or vice versa.

This has been 100% solid for me for about a year and a half.

What I do on Qubes 4.1 is:

  • create my dante VM as a Qube that provides network
  • in its /rw/config/rc.local I add these two lines:
echo 0 > /proc/sys/net/ipv4/ip_forward
systemctl start sockd
  • in its /rw/config/qubes-firewall-user-script I add this:
CLIENT_VM_IP="XX.XX.XX.XX"

iptables -I INPUT 1 -p tcp -s $CLIENT_VM_IP --dport 1080  -j ACCEPT
iptables -I INPUT 1 -p tcp -s $CLIENT_VM_IP --dport 1080  -j ACCEPT


iptables -I INPUT 1 -p udp -s $CLIENT_VM_IP --dport 1080 -j ACCEPT
iptables -I INPUT 1 -p udp -s $CLIENT_VM_IP --dport 1080 -j ACCEPT


iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
ip6tables -I FORWARD -o eth0 -j DROP
ip6tables -I FORWARD -i eth0 -j DROP

Then, in my client VM:
In programs (like Firefox, Thunderbird, or my ssh config file), I set them up to use a socks5
proxy at the IP address of the dante VM and port 1080.

The dante VM shows up as the default gateway on the client VM.

From the client VM, I can connect to port 1080 on the dante VM using netcat or telnet for testing, or using any socks-capable client like FireFox, Thunderbird or ssh (via netcat) during actual usage.

But in Qubes 4.2 this doesn’t work.

Firefox tells me that it cannot connect to the socks server.

My dante VM now has lots of extra rules visible in the output of nft list ruleset (which I’m sad to say I don’t understand).

I did this test:

  • If I run nft flush ruleset on the dante VM, and then I run the following on the dante VM:
CLIENT_VM_IP="XX.XX.XX.XX"
iptables -I INPUT 1 -p tcp -s $CLIENT_VM_IP --dport 12345  -j ACCEPT

nc -l 12345
  • then I can SOMETIMES connect from my client VM by running this on the client VM:
DANTE_VM="YY.YY.YY.YY"
nc $DANTE_VM 12345

But not always. :upside_down_face:

Also, I’ve noticed that if I start the dante VM and the client VM together, then the dante VM has a VIF interface that is configured UP with the same IP as eth0, but if I reboot the client VM, then the VIF interface on the dante VM goes down and stays unconfigured, and then I can no longer reach the dante VM from my client VM.

I even tried installing a Fedora 38 template on my Qubes 4.2 box to see if the problem was with the newer Fedora releases in Qubes 4.2, but the behavior was still the same.

I tried monkeying with adding and removing services like “qubes-network” and “qubes-firewall” and “network-manager” but it did not help.

2

IPTABLES was replaced by NFTABLES in Qubes 4.2.
Maybe thats the problem, so you maybe needs to covert the IPTABLES rules to NFTABLES ones for Qubes 4.2?
See additionally Moving from iptables to nftables - nftables wiki

3

Both my old Fedora 38 in the old Qubes 4.1, and Fedora 38 in Qubes 4.2 have iptables installed via the package named iptables-nft which generates nft rules using the familiar old iptables commands.

So in Qubes 4.1, Fedora 38 when I was issuing iptables commands, it was actually generating nft rules which are viewable using nft list ruleset.

4

Hmm, ok, it was only my first idea. So it must be something other problem.
There are some entries on github regarding to problems with switch from iptables to nftables (like iptables →nftables · Issue #5031 · QubesOS/qubes-issues · GitHub).
Maybe @unman can help, if he read that here.

5

Yes, thank you, I’ve browsed through lots of the issues over the past year because I was reluctant to upgrade to 4.2 just because of this reason.

It turns out that my problem is just really simple though. I just want to open a port on a VM that acts as a NetVM for another client VM. If that could work without a problem, then I would be all set.

6

I found this exact issue covered here before:
“Local network in qubes”

7

I think you just want to open a port :slight_smile:
There are “QubesOS ways”:tm: to do this, via qvm-connect-tcp and policies, without working your way around with iptables and/or nft. The workarounds will always be a problem when upgrading.

8

Thank you, but that would not work for UDP (which I need for proxying video), and I have tried it for TCP in the past, but I found it slower than using straight network connections.

9

So in the other old thread on this forum which I had resurrected, unman told me that the right syntax is:
nft insert rule qubes custom-input tcp dport XX accept

This puts my rule into the custom-input chain in the qubes ip table.

On the other hand, using the old compatibility iptables interface (like I had been) puts my rule in the INPUT chain in the qubes ip table, which I guess is bypassed with the new qubes nft rules.

This situation is almost covered in the docs here: Firewall — Qubes OS Documentation but I ignored it because the example has a full-on firewall qube between the client and server qubes which I don’t have.