Port forwards

Im trying to set up a few things that need ports forwarded (zeronet, openbazaar), using qubes documentation (1). I forwarded in netvm > firewallvm > gatewayvm with no luck so far. Am I going to have to forward from gateway between workstation for this to work?

Great work so far!! Thanks everyone!

(1) Redirecting…

Welcome! :smiley:

Question #1:

For Qubes + Whonix, are you using the old Dual-HVM platform or the new ProxyVM + AppVM platform?

[hr]

Question #2:

Port forwarding through your local clearnet indicates that you do not want to run that traffic over Tor, correct?

Otherwise, if wanting to use Tor, doesn’t the application’s traffic route through Tor normally and then use the app-specific ports at the Tor exit node (and not your local clearnet ports)?

[hr]

If wanting to run over clearnet (not Tor), then maybe using a non-Whonix standard Linux AppVM would be easier to get setup with clearnet port forwarding.

If wanting to run over Tor, then maybe double check the above notion of needing to port forward locally? Maybe you don’t need to for Tor?

I personally haven’t gone through the Qubes port forwarding instructions yet.

But the Whonix-Gateway does cut off clearnet connections with its firewall, which can be bypassed, if totally necessary (but not recommended).

Maybe us looking at a link to your application’s install steps would help further diagnose.

Is this perhaps what you want?

Or rather this?

@WhonixQubes: are hidden services tested to work yet?

[quote=“WhonixQubes, post:2, topic:870”]Welcome! :smiley:

Question #1:

For Qubes + Whonix, are you using the old Dual-HVM platform or the new ProxyVM + AppVM platform?[/quote]

I should have remembered to mention that. New proxyvm/appvm combo.

[quote=“WhonixQubes, post:2, topic:870”]Question #2:

Port forwarding through your local clearnet indicates that you do not want to run that traffic over Tor, correct?

Otherwise, if wanting to use Tor, doesn’t the application’s traffic route through Tor normally and then use the app-specific ports at the Tor exit node (and not your local clearnet ports)?

[hr]

If wanting to run over clearnet (not Tor), then maybe using a non-Whonix standard Linux AppVM would be easier to get setup with clearnet port forwarding.

If wanting to run over Tor, then maybe double check the above notion of needing to port forward locally? Maybe you don’t need to for Tor?

I personally haven’t gone through the Qubes port forwarding instructions yet.

But the Whonix-Gateway does cut off clearnet connections with its firewall, which can be bypassed, if totally necessary (but not recommended).

Maybe us looking at a link to your application’s install steps would help further diagnose.[/quote]

Im not sure entirely understand, but I wil ldo my best to answer whitout sounding like an asshat.

My intent is to access mailpile, openbazaar and zeronet (decentralized site hosting, something like freenet) while staying behind tor while all of tem are based on localhost:port setups. So far all ive done is run them locally in workstationvm and try to access them through the tor browser after forwarding ports in netvm and fwvm to point to gatewayvm.

I imagine workstation uses 9050 to connect to the gateway, so could I proxy from say 15441 to 9050 and be done with it?

[quote=“Patrick, post:3, topic:870”]Is this perhaps what you want?

Or rather this?

Im not sure I understand but are you suggesting using a hidden service to be able to access the services of the applications?

To access those services locally using Tor Browser, see:

So your (non-ideal) options boil down to use Tor Browser + glitch or using iceweasel.

No port forwarding required for that.

[hr]

If you want remote, third parties being able to access those services while you stay anonymous, then this applies:

I will read through that to find somethign optimal. Thank you very much.

@Patrick: Yes, I was able to successfully setup a test hidden service for myself a little while ago on the new Qubes + Whonix platform.

I think this depends upon how the apps work…

Either:

  • requires open server ports for unsolicited packets
  • works through responsive NAT filtering that does not accept unsolicited packets

If the apps act like servers that need open ports for unsolicited packets, then I don’t think this works with Tor, except via Hidden Services which requires .onion addressing support.

If the apps use responsive NAT filtering to accept incoming packets, then…

I’d imagine that port forwarding is not required, because Tor traffic already flows this way without port forwarding.

And forwarding ports from NetVM --> FirewallVM --> Whonix-Gateway --> would be forwarding from the clearnet – not Tor internet.

Since you want to route anonymously via Tor, port forwarding out through clearnet internet doesn’t seem to be right – where you don’t want these services contacting your apps via clearnet networking.

I could be wrong. I haven’t setup these types of apps over Tor before.

Hidden services / Whonix indeed generally don’t need any port forwardings.

Neither servers behind hidden services, servers with .onion addresses, nor clients accessing hidden services require .onion addressing support. What clients need to be able to connect to hidden services .onions is connecting to a Tor proxy. That’s it. No special support in the application needed just for that.

[quote=“Patrick, post:9, topic:870”][quote author=WhonixQubes link=topic=959.msg6984#msg6984 date=1423985111]
If the apps act like servers that need open ports for unsolicited packets, then I don’t think this works with Tor, except via Hidden Services which requires .onion addressing support.
[/quote]
Neither servers behind hidden services, servers with .onion addresses, nor clients accessing hidden services require .onion addressing support. What clients need to be able to connect to hidden services .onions is connecting to a Tor proxy. That’s it. No special support in the application needed just for that.[/quote]

Right, beyond the user application, Tor routing handles the .onion addressing and routes it via rendezvous points, etc.

But, for example, wouldn’t BitTorrent clients need to issue their requests to the Tor proxy in the form of .onion addresses, instead of raw IP addressses, in order to reach Hidden Services? Therefore needing to be aware of TLDs (.com, .net, .onion, etc)?

I’m not sure if BitTorrent clients are TLD aware or not in their P2P networking protocols, but thought it could be an issue if needing to incorporate traditional server functionality over Tor via Hidden Services.

BitTorrent clients which want to reach hidden services needs to use a Tor proxy. Nothing else.

If they know how to resolve DNS, then this would also work for hidden services (if they use a Tor proxy). Because Tor resolved hidden services to virtual IPs. (Test this in Whonix: nslookup some.hidden.service.onion) I think they do support DNS. Judging by the torrent torification instructions I have read in past. And if they did not support DNS, then users could consider to use Tor’s /etc/tor/torrc MapAddress feature.

Tanks for all the replys. I tried diging thru the links to find some optimal method, so far nothing. I wanted to ask, if anyone had any ideas on preventing figerprinting for localhost connections (which led to them to disable it). Would hosting them as a hidden service on the local machine and then connecting over the browser be a good projet? If noting else, running another version of the browser without tor installed just to minimize attak surface?

You’d replace one attack surface with another.

I’d use a separate VM just for hosting that server and only configure that Tor Browser to allow local connections. When it’s your server and know what its doing, I wouldn’t worry about the fingerprinting stuff. The question is who can view that information leak. If it’s only your own server, there is nothing to worry. If you know what you are doing, you can even use iceweasel for that. And other VMs for other stuff.

Another option could be connecting to the server from another VM inside the “Whonix” internal network.

In addition, I’d recommend destroying and recreating your anonymous VMs on a regular basis, exporting/importing key data and configurations you want to retain to the new VMs, in order to help mitigate the consequences of your VMs being exploited.

Also, be sure to name the VMs something generic, and do not put anything personal in the VM names.

@Patrick,
That sound like I have a new thing to work on now, thanks! One thing that does worry me zeronet is based on bittorrent/dht, would hosting the HS and connecting compromise anonymity?

@Whonixqubes,
Definitly, Im really waiting for the workstationvm to be usable as a dispvm. All names are vague.

[quote=“igijo, post:15, topic:870”]@Whonixqubes,
Definitly, Im really waiting for the workstationvm to be usable as a dispvm. All names are vague.[/quote]

Yes.

You also might be interested to know that I’m working on an developing a new app this year that should hopefully meaningfully improve a number of important things with Qubes + Whonix.

Amnesic usage of Qubes + Whonix is one of the key goals.

Stay tuned! :smiley:

ZeroNet probably won’t work in Whonix 13. You need to wait for Whonix 14. Will be documented here:

It will be as (un)safe as using a Tor hidden service. (Onion Services - Whonix)