Gateway PREROUTING rules for SOCKS ports may interfere with trans port traffic

phabricator-migrator · February 19, 2024, 5:46pm

Information

ID: 462
PHID: PHID-TASK-76fnafckq22lzsyms2tx
Author: bubblewap
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

Hello again,

This follows from a discussion in:

The nat PREROUTING rules of Whonix Gateway firewall for all SOCKS ports should probably match on the gateway IP address in addition to the port.

The current rules resolve to (gotten from iptables-save):

PREROUTING -i eth1 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189

They should probably be:

PREROUTING -i eth1 -d 10.152.152.10 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189

They can probably be further simplified to:

PREROUTING -i eth1 -d 10.152.152.10 -p tcp -m tcp --dport 9189 -j ACCEPT

(but this is not well tested)

On my system, if the rules do not match on the gateway IP address, the rules interfere with Trans port communication for packets going out (via trans port 9040) with the same destination port as any of the socks ports, effectively blocking them.

Based on the previous discussion, it is not clear that this poses an issue for everyone, or in what cases it applies exactly, but on my system (Whonix 11 dist-upgraded), the problem is always reproducible. Adding a socks port and rules for port 443 using existing Whonix rules on the gateway - this results in “curl.anondist-orig https://www.whonix.org” no longer working on the workstation. Adding “-d 10.152.152.10” works and I believe would be logical to have in any case.

Note the DNS and Trans port PREROUTING rules must remain the way they are, those ones are ok, it’s only the socks ports rules that may have an issue.

https://github.com/Whonix/whonix-gw-firewall/blob/c26d7395e1d0a6d03ffca320109869bdb5b383a7/usr/bin/whonix_firewall#L436-L509

Comments

Patrick

2016-01-05 00:47:21 UTC

bubblewap

2016-01-05 01:58:53 UTC

I had no idea you had to deal with dynamic IPs, but I’ve had a completely unrelated system where I ran into a similar issue.

The solution there was to convert the firewall script to an iptables-save script that can be loaded atomically with iptables-restore, and reload the firewall script after network goes up and IPs come in (with extra bash to get the interface IP).

(I’m not 100% on the safety of atomic iptables-restore operation - should be researched just to be safe - but on that system it was a non issue)

Alternatively, depending on how the apps are configured in Qubes Whonix Workstation (I don’t know!) this could be a non-issue. If the apps are configured to connect to 10.152.152.10 and 192.168.0.10 on qubes, then instead of the last rule conversion I suggested:
PREROUTING -i eth1 -d 10.152.152.10 -p tcp -m tcp --dport 9189 -j ACCEPT
you could just go back to the redirect:
PREROUTING -i eth1 -d 10.152.152.10 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189
and it might “just work” (10.152.152.10 will become the qubes IP on the packet). But it depends on how the apps are configured in qubes whonix workstation (I don’t know!).

(and of course you double up one or more of those rules for 192.168.0.10)

bubblewap

2016-01-05 02:22:39 UTC

bubblewap

2016-01-05 05:10:00 UTC

Given the previous I can think of no other ideas and your initial suggestion was the simplest:

Maybe we could accept destination 192.168.0.10, 10.152.152.10, the Qubes range (?), and ignore the rest?

You could probably capture the whole private IP address space since Tor shouldn’t route it (?), but less is more so yours is better.

In any case if you know the static qubes range in advance (10.777.777.0/24), I think this would work (assuming this port needs all the IPs):
PREROUTING -i eth1 -d 192.168.0.10 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189
PREROUTING -i eth1 -d 10.152.152.10,10.777.777.0/24 -p tcp -m tcp --dport 9189 -j ACCEPT
If I understood the configuration correctly, only 192.168.0.10 needs the REDIRECT jump. 10.152.152.10 should be ACCEPT unless there are configurations not accounted for; either’s probably fine. For ranges it’s probably better to use ACCEPT (so unconcerned IPs get filtered out by the host instead of redirected).

If you can’t know the qubes range and you can’t get or action on the dynamic IP, then as a last resort:
PREROUTING -i eth1 -d 192.168.0.10 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189
PREROUTING -i eth1 -d 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 -p tcp -m tcp --dport 9189 -j ACCEPT
Take with grain of salt because I’m tired.

Patrick

2016-04-05 16:13:22 UTC

marmarek

2016-01-05 12:57:42 UTC

marmarek

2016-01-05 12:58:48 UTC

Patrick

2016-01-05 13:43:43 UTC

Patrick

2016-10-12 18:08:02 UTC

Patrick

2016-10-12 22:48:58 UTC