Testers wanted! New FIN ACK / RST ACK Leak Test

I am using the gateway with graphics enabled but it gives this message. I understand the syntax of running nano instead of kwrite, but kwrite is my only realistic choice since I will be cutting and pasting sections of text which I don’t know if possible with nano. I used kwrite during torbrowser apparmor testing and it worked great that tieme, but I don’t know what broke since to not allow this editor to run.

Patrick please also tell me in detail which parts I need to experiment with in the config file once I get editor working.

tI don’t know why but you cannot run kdesudo as root. You have tot run it as user, and then you can edit files owned by root.

tI don't know why but you cannot run kdesudo as root

…or any graphical application. It seems peculiar to KDE. In the host (Xfce4), I can run gedit directly as root. Yet, It is recommended to run graphic apps with kdesudo (or gksu for gnome like environments).

Yes. This is an general usability issue in any distribution I used so far. You have to open a terminal as user “just start Konsole”, then use kdesudo (not sudo), then a graphical editor, then eventually a filename. Not sure if there is a bug report about this.

Close Konsole (if any is open) -> Start Konsole ->
kdesudo kwrite /usr/bin/whonix_firewall

Do not “sudo su” or so beforehand.

Thank you for being patient and walking me through this. I managed to edit and perform the steps exactly as noted and unfortunately there is a leak in tcpdump. I am open for suggestions on what I should do next.

I still didn’t get to it. But I made good progress in splitting Whonix into smaller packages.

My suggestion for deactivating transparent proxying should work as a stopgap in meanwhile.

And there is still plenty of help welcome in the KVM thread:

Thanks for keeping this on your radar. Meanwhile I’ll do this workaround. Regrettably I was busy and hadn’t checked the forum for some time, but I’m back again :slight_smile:

EDITED TO ADD:
Leak test still shows positive even when Transparent Proxy with DNS disabled. I made sure firewall was reloaded. Timesync does fail after this with the following message:

Network Time Synchronization failed!!! SDWDATE_STATUS: RUNNING TIMESANITYCHECK_STATUS: Success Please report this bug!

See logfile: tail -f -n 20 /var/log/sdwdate.log
See status files: cd /var/run/sdwdate && dir
Try again: Start menu → Applications → System → Whonix Timesync
or in Terminal: timesync
Last resort: manually set the clock! (In UTC!):
sudo su
date -s “17 FEB 2012 24:00:00” && hwclock -w

Disable Transparent TCP as well.

Timesync does fail after this with the following message:
Are you sure this is related? Reproducible? I just tested. Without any transparent proxying, no tcp/dns, timesync still works.

[quote=“Patrick, post:28, topic:229”][quote author=HulaHoop link=topic=243.msg2169#msg2169 date=1401498483]
Leak test still shows positive even when Transparent Proxy with DNS disabled. I made sure firewall was reloaded.
[/quote]
Disable Transparent TCP as well.

Are you sure this is related? Reproducible? I just tested. Without any transparent proxying, no tcp/dns, timesync still works.[/quote]

Sorry for not being clear, By Transparent Proxy I meant TCP as well was disabled. For me I managed to reproduce this again as I noted the same actions of timesync the last time I had Tor configured like so.

On Whonix-Gateway, you’ve added

WORKSTATION_TRANSPARENT_TCP=0 WORKSTATION_TRANSPARENT_DNS=0

to

then did

?

What does whonixcheck say on Whonix-Workstation? Does it notice, that Tor’s TransPort is unreachable?

No I followed the instructions outlined here instead. Stream Isolation

Nano tells me the file that this 50_user file you mention is a new file rather than an existing one that I would edit. Should I follow these new directions instead and report back? Did you change something that needs me to perform a system update first before trying out?

Nano tells me the file that this 50_user file you mention is a new file rather than an existing one that I would edit. Should I follow these new directions instead and report back?
Yes.

By the way… /etc/whonix_firewall.d/30_default says:

[code]## Please use “/etc/whonix_firewall.d/50_user” for your custom configuration,

which will override the defaults found here. When Whonix is updated, this

file may be overwritten.[/code]

So it doesn’t really matter. Same effect. Just when creating a new file, you won’t run into an interactive dpkg conflict resolution dialog (Configuration Files - Kicksecure) when 30_default gets changed through an update. The full story of 30_default vs 50_user etc. is documented here:
Configuration Files - Kicksecure
Maybe you have a better idea how to best explain and document this.

Did you change something that needs me to perform a system update first before trying out?
No.

There are leaks even with the new instructions. As for Timesync I still get the same error message when it fails.

Did you succeed deactivating Transparent Proxying? Does whonixcheck on Whonix-Workstation notice, that Tor’s TransPort is no longer reachable?

whhonixcheck never gave such a warning. Is there another way to verify that it is deactivated?

Are you sure you applied these firewall settings on Whonix-Gateway?

whhonixcheck never gave such a warning.
Before that it makes little sense to continue testing, since transparent proxying is not really disabled then.

This is what whonixcheck will say by the way.

[INFO] [whonixcheck] TransPort Test: Testing Tor's TransPort... [ERROR] [whonixcheck] TransPort Test Result: Tor's TransPort was not reachable. (curl return code: [6] - [Couldn't resolve host. The given remote host was not resolved.]) (If you disabled Tor's TransPort, please disable this check, see whonixcheck /etc/whonix.d/30_whonixcheck_default configuration file.)

Is there another way to verify that it is deactivated?

Yes.

No transparent proxying means in other words “no connections without proxy settings or uwt”.

Two new small documentation chapters have just been added to check this:

And if this doesn’t work…

Alternative method to disable transparent proxying.

On Whonix-Gateway. Add to /etc/tor/torrc

TransPort 0 DnsPort 0

Then reload Tor.

I verified and both are turned off without needing to do anything else, but whonixcheck does not issue any warnings:

Password: root@host:/home/user# nslookup check.torproject.org ; echo $? ;; connection timed out; no servers could be reached

1
root@host:/home/user# curl.whonix-orig 38.229.72.22 ; echo $?
curl: (7) couldn’t connect to host
7

Can you post whonixcheck’s output (scrub ips) please?

And leak can still be detected even when we verified now, that transparent proxying is disabled?