Socks IPs are Disregarded if using Preconfigured Gateway Ports / Qubes Subnet Segregation

entr0py · April 3, 2016, 7:21pm

Not sure if this is a Qubes issue, Whonix issue, or an issue with my networking ignorance…

Setup is Whonix 12 on Qubes as follows:

Whonix-Gateway1 (10.137.1.A)
is netVM for
Whonix-Workstation1 (10.137.2.P)

Whonix-Gateway2 (10.137.1.B)
is netVM for
Whonix-Workstation2 (10.137.3.Q)

Both Gateways have VPN_FIREWALL enabled.
LOCAL_NETs are 127.0.0.0/24 and 10.137.2.0/24 (or 10.137.3.0/24 respectively).

TB running on WS2 with default proxy settings (127.0.0.1:9050) works as expected.

Same TB (on WS2) connected to GW1 (10.137.2.1:9050) also works! This was surprising to me. Is this the intended design?

GW1 and GW2 are on the same subnet (10.137.1.x) so they should be visible to each other, except for this:

any VM-to-VM traffic, among the VMs connected to the same Net/Proxy VM is blocked by default.
(from http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html)

WS2 is not communicating directly with GW1 because if GW2 has VPN disabled or Tor stopped, then TB does not connect. Not sure why VPN or Tor would need to be online for GW2 to send traffic to GW1? All very confusing…
This is not TB-specific. Also tested with random app on WS2 routing over proxychains to GW1.

Patrick · April 4, 2016, 6:32pm

Can you reproduce this while removing Whonix from the equation?

entr0py · April 5, 2016, 3:51pm

I created a setup analogous to Qubes-Whonix setup above using Fedora machines but not really enlightening. No firewalls, no torsocks. Pointing Firefox to a proxyVM on a different subnet just sends packets out to the internet looking for the proxy IP as expected.

What’s strange is this next test using the following VMs:

Whonix-Gateway1 (10.137.1.A, 10.137.2.1)
Whonix-Gateway2 (10.137.1.B, 10.137.3.1)
Fedora-Workstation (10.137.2.R)

Whonix-Gateway1 is net/proxyVM for Fedora-Workstation.
Firefox in Fedora-Workstation is set to manual proxy settings (10.137.2.1:9050). check.torproject.org returns TorExit X.
Firefox in Fedora-Workstation is set to system proxy settings. check.torproject.org returns TorExit Y. This is expected because TransPort will use a different circuit than SocksPort.
Firefox is now set to connect to Gateway2 manual proxy settings (10.137.3.1:9050) while VM is still connected to Gateway1. check.torproject.org returns TorExit X! It is possible to get same TorExit node by coincidence. So tried again after some time. Same result.

This result was confirmed by watching arm traffic in both gateways. The Firefox traffic is being routed through Gateway1 even when proxy settings are set to Gateway2’s IP address. So one mystery is solved at least - there is no cross traffic between subnets.

But why is Whonix-Gateway accepting traffic destined for a non Gateway IP?

entr0py · April 5, 2016, 4:11pm

One more iteration with <random proxy IP>:9050 in Firefox routes over same SocksPort. It seems Gateway is only listening for Port and doesn’t care about the IP.

Patrick · April 5, 2016, 4:25pm

Because the default gateway (sudo route) is still the gateway. And whonix-gw-firewall only looks for destination ports.

Slightly related and additional explanation:
Gateway PREROUTING rules for SOCKS ports may interfere with trans port traffic
https://phabricator.whonix.org/T462

(Related, because as long as Qubes does not implement the optional static IP addresses feature, it is difficult to implement forwarding traffic designed for the gateway IP only.)

entr0py · April 5, 2016, 4:42pm

Thanks. Thread category / subject changed.