iptables gateway prerouting: can't acess specific ports through trans port?

Physical Isolation
1

I have a question about the whonix gateway iptables prerouting. It looks like this:

-A PREROUTING -i eth1 -p tcp -m tcp --dport 9186 -j REDIRECT --to-ports 9186
-A PREROUTING -i eth1 -p tcp -m tcp --dport 9187 -j REDIRECT --to-ports 9187
-A PREROUTING -i eth1 -p tcp -m tcp --dport 9188 -j REDIRECT --to-ports 9188
-A PREROUTING -i eth1 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189
-A PREROUTING -i eth1 -p udp -m udp --dport 53 -j REDIRECT --to-ports 5300
-A PREROUTING -i eth1 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040

What happens if an app using the trans port (no proxy support or broken proxy support) needs to access a web server using any of the predefined ports, like http://someserver:9189/index.html?

In this case don’t the REDIRECT rules above cause the request to go to the gateway’s local 9189 tor socks port instead of the tor trans port (9040)? And presumably fail since they expect a socks comm?

How do you work around that case? Try to uwt or proxychains aorund the app and give it its own tor socks port? And what if the wrappers don’t work?

This is semi-hypothetical but I’m curious about those rules. The redirects for 53 and 9040 are a given, but why don’t 9188, 9189, etc. match on the destination IP (-d 10.152.152.10) in addition to the port?

2

bubblewrap:

I have a question about the whonix gateway iptables prerouting. It
looks like this: -A PREROUTING -i eth1 -p tcp -m tcp --dport 9186 -j REDIRECT --to-ports 9186 -A PREROUTING -i eth1 -p tcp -m tcp --dport 9187 -j REDIRECT --to-ports 9187 -A PREROUTING -i eth1 -p tcp -m tcp --dport 9188 -j REDIRECT --to-ports 9188 -A PREROUTING -i eth1 -p tcp -m tcp --dport 9189 -j REDIRECT --to-ports 9189 -A PREROUTING -i eth1 -p udp -m udp --dport 53 -j REDIRECT --to-ports 5300 -A PREROUTING -i eth1 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040

What happens if an app using the trans port (no proxy support or
broken proxy support) needs to access a web server using any of the
predefined ports, like http://someserver:9189/index.html?

In this case don’t the REDIRECT rules above cause the request to go
to the gateway’s local 9189 tor socks port instead of the tor trans
port (9040)? And presumably fail since they expect a socks comm?

How do you work around that case? Try to uwt or proxychains aorund
the app and give it its own tor socks port? And what if the wrappers
don’t work?

It will just work. You’re confusing the levels.
http://practically-some-IP:9189/index.html is inside the connection. Not
being touched by iptables. It’s the remote IP/port, not the local one.

3

Hi Patrick. Great work on Whonix.

The trouble is that I can replicate the problem I am describing.

On the gateway, add the following rules:

iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 80
iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443

This is to emulate the issue with the existing rules (9188, 9199, etc.).

Then install Iceweasel (on the workstation) and set it no use no proxy so it uses the trans port (9040).

Try to access any site. It is blocked by iptables by the above rules.

Then change the rules using the following:

iptables -t nat -D PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 80
iptables -t nat -D PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443
iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp -d 10.152.152.10 --dport 80 -j REDIRECT --to-ports 80
iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp -d 10.152.152.10 --dport 443 -j REDIRECT --to-ports 443

Suddenly, web access in Iceweasel works again.

In essence with the new rules, the 80 and 443 rules REDIRECT does almost nothing but make an exception to the trans port REDIRECT rule. If you don’t match on the gateway IP (as added above), the rules intercept traffic bound for the trans port on those ports (and sends them to 10.152.152.10:80 and 10.152.152.10:443 instead of 10.152.152.10:9040).

4

It won’t work because Tor is not listening with a Tor SocksPort on these
local ports 80 and 443. If you add them, then reload Tor, it should work.

5

I tried now to add

SocksPort 10.152.152.10:80
SocksPort 10.152.152.10:443

and verify they were running, and add the necessary filter rules

iptables -I INPUT eth1 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -I INPUT eth1 -p tcp -m tcp --dport 443 -j ACCEPT

but the result is the same. The ports are accessible as socks ports when added in Iceweasel (SOCKS5 10.152.152.152:443), but trans port (no proxy) doesn’t work.

I was not aware of socks ports able to double as trans ports. Can they do that? Any extra configuration needed other than the above?

(and of course the rules below:)

iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 80
iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443
6

They don’t. Still need to use them as SocksPorts.

You forgot to add the accept rule.

  $iptables_cmd -A INPUT -i "$int_tif_item" -p tcp --dport "$SOCKS_PORT_CURL" -j ACCEPT
  $iptables_cmd -t nat -A PREROUTING -i "$int_if_item" -p tcp --dport "$SOCKS_PORT_CURL" -j REDIRECT --to-ports "$SOCKS_PORT_CURL"

If you want to add new SocksPorts, you need to emulate the following two commits.

Accessing a port on the gateway is different from accessing a remote port. Using Whonix-Gateway as a gateway won’t trigger these redirection rules. The workstation asks the gateway to forward the request. Not to access a specific port on the gateway.

Just now tested this. Added redirection for port 80 and 443. But did not add new Tor SocksPorts. Then used the non-uwt wrapped (!) version of curl and was still able to access 80/443 on remote web servers.

7

Thanks, but I did everything listed in those two commits and I had already added the filter rule. I could contact the socks port just fine with socks-aware app.

I’m afraid I don’t see how it could work on your end.

Let’s take the simplest case you just stated again.

Here is the output that I get with orig curl with default Whonix Gateway and Workstation, on Workstation:

user@host:~$ sudo /usr/bin/curl.anondist-orig https://www.whonix.org -q -o /dev/null -w "HTTP CODE: %{http_code}\n"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57208    0 57208    0     0  28787      0 --:--:--  0:00:01 --:--:-- 28776
HTTP CODE: 200

Looks good.

Now I go to the Gateway and add a redirect rule on the fly:

user@host:~$ sudo iptables -t nat -I PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443

Then back on Worktation, run same command as before:

user@host:~$ sudo /usr/bin/curl.anondist-orig https://www.whonix.org -q -o /dev/null -w "HTTP CODE: %{http_code}\n"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:02:06 --:--:--     0HTTP CODE: 000
curl: (7) Failed to connect to www.whonix.org port 443: Connection timed out

Stopped it in its tracks.

8

Don’t open it on the fly. Add it to the firewall. Then reload the
firewall. Otherwise it’s likely not in the right spot of the chain.

9

I did, and the result is the same as above.

I had already checked that “iptables -t nat -I” was inserting at the correct location. (checking output of “iptables-save” command)

I’m using Whonix installed from version 11 dist-upgraded up to recent.

Again the only way I can get it to not interfere is to add the match on the gateway address, e.g.:

sudo iptables -t nat -I PREROUTING -i eth1 -d 10.152.152.10 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443

(it also works on the equivalent entries in /usr/bin/whonix_firewall)

… though it could maybe be rewritten as something simpler (REDIRECT does nothing to the packet header if you match on 10.152.152.10).

10

If you have something simpler in mind, please write a pull request.

I was wondering about refactoring the firewall anyhow. Too many separate
socks ports firewall rules now. Either looping through all of them. Or
relaxing the firewall. There is probably no point in keeping all ports
on the internet interface (eth1) closed but to open the ones where Tor
or cpfpy is listening. Perhaps it would be simple to keep gateway eth1
completely reachable from the workstation.

Without blocking all incoming ports by default on eth1, Tor should be
directly reachable. I mean, there should be no need for any iptables
accept or redirect rules.

( For experimentation see:
Dev/Firewall Unload - Whonix [firewall unload breaks
transparent proxying] )

Before I do more extensive changes, I need to setup a corridor proxy for
better leak detection. Perhaps package corridor. I don’t know yet when I
get to this.

/cc @HulaHoop

11

Well, when I run firewall unload on the Gateway and try to reach a site over trans port on the Workstation, it doesn’t work. On the config I have in front of me, the trans port functionality clearly depends on the rule:

PREROUTING -i eth1 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040

To me that made sense to begin with because it’s the usual Tor config TransparentProxy · Wiki · Legacy / Trac · GitLab.

And afaik PREROUTING nat rules will preempt everything else the gateway does, so these rules would probably take priority regardless (unless there was more tunneling I’m not aware of being done on the Workstation side, but not on my system…).

I guess the only real suggestion I make is to add “-d 10.152.152.10” to the SOCKS PREROUTING rules. But afterward they can probably simplify (but doesn’t change anything more) to:

PREROUTING -i eth1 -d 10.152.152.10 -p tcp --dport 443 -j ACCEPT

(only for SOCKS, not DNS or trans port rules)

I’ll write it again in a request ticket then.

The other parts of the firewall made sense to me.

12

I created this issue ticket: ⚓ T462 Gateway PREROUTING rules for SOCKS ports may interfere with trans port traffic

I wrote it with the presumption that regardless of whether it affects Whonix 12 and everyone or just me for some reason, the suggested change would be logical to have.

13

Good ticket. Will answer there.

14

Simplification is good but caution is paramount. If the effects are not understood then its best to leave it alone.

+1 Packaging Corridor opens the way for many interesting directions for Whonix.