No connectivity in GW

After setting your NetVM to sys-net, Whonix was fine?

Then it could be the following Qubes upstream bug:

The fix for it is currently only available in the Qubes testing repository. You might want to get that update or wait until it flows to stable.

It wasn’t all I did, I both UnWhonix’d the Gateway, AND set the NetVM to sys-net.
Now I’m trying to see which change exactly made it work, but it’s not so easy, sometimes when I restart Gateway it reverts back to the old configuration files…

EDIT: it’s now working with NetVM set to sys-net and a flushed iptables, but I get a warning Could not check for software udpates (apt-get has same error in the TemplateVM as well ).
How can it be it’s working for others but not for me in this case?

That is a bug. Reference:

It is fixed in Qubes R3.2rc2 and qubes-whonix 5.7-1 (currently only in Whonix jessie-proposed-updates and testers repository).

Thanks Patrick.
Any idea why it works for everyone else but me?
I could try eliminating the iptables rules for the buggy line, but it still bugs me why it happens only to me…

No. Could perhaps be hardware related.

Thank you a lot for your patience and persistence!

The upcoming version of Qubes-Whonix stable maintenance release will be much more robust against race conditions. When it is out, please try it. (Might be a few days.)

Qubes-Whonix 13.0.0.1.2 TemplateVMs - Testers Wanted!

I installed the same Qubes in a different machine, but behind the same router, and had the same problem. Does it mean the router could be causing this somehow? When I clear the iptables rules it works, so this is odd.

Maybe. I once heard such a report that it was all the router’s fault but that reporter did not go into details.

Should I just flush the iptables and allow everything considering I’m behind a router (with NAT)?
Which rules should I include?

No.

I’d like to debug this further, but I have to use a usb wifi adapter. I couldn’t find any instructions on how to use a usb wifi in Qubes - do you have any links to help with that?

Thanks

No, never tried that myself. Please try the Qubes help (probably mailing list).

Found something that could help.

OK. When I used a different modem it connected.
This is bewildering, I don’t have any such problems with VritualBox Whonix.
What could possibly be causing this?

That is very strange indeed.

No idea. Can only speculate.

A simple modem? Or a more sophisticated device with many (firewall)
settings or router?

Perhaps any firewall settings blocking some outgoing ports? Perhaps deep
package inspection (DPI) or other stuff such as intrusion prevention
system (IDS IPS) that is detecting a false positive and blocking it?

It’s a modem-router. I can’t see any DPI or IDS IPS options in the router’s interface. For clarification I didn’t use the same ISP when tested Qubes with another modem (modem+ISP were different, not only modem).

EDIT: I’d venture to say it has to do with the country where I live in, which is notorious for surveillance by the government, if Tor standalone failed to work on the same Qubes OS too.

I tried something else. This time I set the Socks5Proxy directive to make it connect through a proxy in an attempt to circumvent any possible DPI on the ISP’s side, yet it’s still not working.
I tested the same directive in a non-Qubes-Whonix Tor and it worked fine.

Socks does not necessarily beat DPI. What would be interesting would be
connecting though a socks proxy service that is both encrypted (such as
Tor, JonDo) that is already working on the host.

Tor would lead to Tor over Tor, but perhaps JonDo https proxy in another
VM would work? As per:

Combining Whonix ™ with JonDonym

Hi Patrick,

I was of the impression Socks is an encrypted tunnel.
In any case, I tried Tor over JonDo, and it took some time, but it worked, and I’m even more puzzled than before…

  • the local connection from ws to gw (any socks) is unencrypted
  • once Tor accepted the socks connection and forwards it to the Tor network it will be encrypted with 3 layers (onion layers)
  • however, Tor traffic is not that difficult to detect. Encrypted does not mean hard to block by DPI. That requires traffic obfuscation. (documented here: Configure (Private) (Obfuscated) Tor Bridges)
  • other and “regular” socks proxies are unencrypted (more info: Whonix versus Proxies)

Possiblities:

  • a) some DPI is blocking Tor but not JonDo (much less popular), not so likely

  • b) port blocking

  • Tor in the Debian VM happened to pick ports for entry guards that are not blocked

  • Tor in Whonix-Gateway VM happened to pick ports for entry guards that are blocked

  • JonDo uses ports not blocked

  • and when tunneling Tor through JonDo, it does no longer matter that the ports of your entry guards are blocked by your router (which might be happening)

To strengthen the b) hypothesis, I propose the following.

I added to torrc ReachableAddresses accept *:9001 and it bootstrapped fine, and circuits were shown in arm, but it took at least an hour to get browsing in the WS. On the other hand, iirc sometimes after I got Qubes-Whonix-GW to bootstrap, either by flushing iptables rules, or by bypassing going through the network normally, it worked normally for a while right after. I never have issues connecting to Tor in non-Qubes-Whonix, so how can it be only a port change made a difference?