Page MenuHomePhabricator

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

Description

Hello again,

This follows from a discussion in:
https://forums.whonix.org/t/iptables-gateway-prerouting-cant-acess-specific-ports-through-trans-port/1850

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

Details

Impact
Normal

Event Timeline

bubblewap created this task.Jan 5 2016, 1:11 AM
bubblewap updated the task description. (Show Details)
bubblewap added a project: whonix-gw-firewall.
bubblewap set Impact to Needs Triage.
bubblewap added a subscriber: bubblewap.
Patrick triaged this task as Normal priority.Jan 5 2016, 1:28 AM
Patrick added a project: Whonix 13.
Patrick changed Impact from Needs Triage to Normal.
Patrick added subscribers: HulaHoop, marmarek, nrgaway.
Patrick updated the task description. (Show Details)Jan 5 2016, 1:33 AM

Not all that simple to fix.

This would break TorBirdy. Just now tested.

The version currently installed from Debian still uses the old Whonix-Gateway IP from previous versions.

( https://github.com/ioerror/torbirdy/commit/b44db6e23773fea1d079acb88980b34f1733844f )

Perhaps similar cases.

Also, in Qubes, the IP of Qubes-Whonix-Gateway is not static. (Qubes does not yet support static IP addresses.)

So applications able to connect with wrong socks proxy settings is currently a handy feature.

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

bubblewap added a comment.EditedJan 5 2016, 2:40 AM

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 added a comment.EditedJan 5 2016, 3:12 AM

Hmm, I think you can disregard the last ("Alternatively, ...") part of my comment. I looked at your script files https://github.com/Whonix/qubes-whonix/blob/master/usr/lib/qubes-whonix/replace-ips and so it seems you replace the IPs in all the config files. Sorry. [suggestion only works if the app config is static]

I thought you might've kept static configurations and sent it all to the gateway through routing (because the PREROUTING rules I'd noticed end up working no matter the IP in many cases, and I've exploited this myself [in something other than this ticket]).

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 added a comment.EditedJan 5 2016, 1:48 PM

Qubes-Whonix-Gateway/Workstation IP's 'only' change after boot. Fortunately, they don't change while the system is running. So the current /usr/bin/whonix_firewall script is dynamic enough.

The replace-ips script is not something I like. I would like to abolish it. Probably not possible until Qubes supports static IPs. (Qubes feature request, optional static IP addresses)

Qubes IP range (already defined in the firewall script) should be 10.137.0.0-10.137.255.255, right? @marmarek

Qubes IP range (already defined in the firewall script) should be `10.137.0.0-10.137.255.255`, right? @marmarek

Yes.

>   Qubes IP range (already defined in the firewall script) should be `10.137.0.0-10.137.255.255`, right? @marmarek
Yes.

No... DispVMs has 10.138.x.x. So it should be
10.137.0.0-10.138.255.255.

Patrick edited projects, added Whonix 14; removed Whonix 13.Jan 8 2016, 6:20 PM
entr0py added a subscriber: entr0py.Jun 4 2016, 5:05 AM
Patrick changed the task status from Open to Review.Oct 12 2016, 8:08 PM
Patrick closed this task as Resolved.Mar 7 2018, 2:01 AM
Patrick claimed this task.