Did pluggable transports stop working for you?

Applications running on the gateway aren’t Tor control protocol filtered. These have direct access. There’s not a lot such applications to my knowledge except nyx, onioncircuits and vanguards. Pluggable transports do not use Tor control protocol as far as I know. Even if they did, unrestricted access is OK as these applications are trusted and the workstation can’t learn about that (only white listed, filtered Tor control protozoic access).

Leaks from workstation to clearnet are very unlikely as long as we don’t enable IP forwarding. A computer connected over LAN direct connection to another computer doesn’t easily get clearnet internet access. (That 's what IP forwarding is for.) Even if gateway had full unrestricted clearnet access, that wouldn’t allow the workstation accessing any clearnet access. Restricting what gateway leaves the gateway is useful for accidental misconfiguration by users and to anonymize APT upgrade traffic.

resolver: None. No special package. Debian standard / default one. libc gethostbyname. My testing instructions above are sufficient. No special/extra DNS resolver package such as bind9 / unbound / dnsmasq required.

It’s a huge jump from “no DNS resolver” to “sophisticated DNS resolver”. Worth going for DNSCrypt? Fingerprintable at ISP level. Required in initial implementation? Also a ton harder to implement.


1 Like

Thanks for the explanation.

Sounds good.

Overkill. Not worth the trouble without a fitting use case.

What root servers does gethostbyname query? I recommend OpenNIC:

I don’t trust Google for many reasons including their collusion with oppressive governments if it means they can provide service there.

I guess it depends what root servers are not censored in China

1 Like

If run in VM it asks the virtualizer which then asks the host operating system which then uses the host’s /etc/resolv.conf which probably for most users the IP address of their home router which then uses their internet service provider (ISP) DNS server.

It would be very similar if not the same as using nslookup check.torproject.org on the host operating system.

1 Like

Still any issue here?

I followed the exact instructions in the wiki again for setting up snowflake (on a fresh Qubes 4.1 install) but it seems that it’s no longer working. Checking /var/run/tor/log I find:

[WARN] Pluggable Transport process terminated with status code 256 [1 duplicate hidden]

I have no idea what’s wrong here. Tried to disable apparmor with sudo systemctl stop apparmor.service but it didn’t help. And I do have all the necessary stuff in /etc/hosts for the DNS lookups.

@Patrick Can you take a look? Meek is getting deprecated so it’s very important to make sure snowflake is working.

Seems like the issue is with AppArmor after all. After following this step I was able to get it working:

As it stands the wiki should be edited: Configure (Private) (Obfuscated) Tor Bridges

It’s already included by default here:

Improve the Documentation / Edit the Whonix ™ Wiki