https://github.com/Whonix/anon-ws-disable-stacked-tor/commit/128e2312bf58a5c1cea3eecd74d1fa0a1a194b51

https://researchut.com/post/migrating-firewall-to-nftables/

nftables transition info:

In T533#13328, @Patrick wrote:

Note to self: try to disable and see if konsole and kwrite are still functional in timesync-fail-closed mode.

## TODO: temporary - https://phabricator.whonix.org/T533#10288
$iptables_cmd -A OUTPUT -m iprange --dst-range "127.0.0.1" -j ACCEPT

https://github.com/Whonix/whonix-ws-firewall/blob/master/usr/bin/whonix_firewall#L318

Note to self: try to disable and see if konsole and kwrite are still functional in timesync-fail-closed mode.

https://github.com/Whonix/whonixcheck/commit/5c8bf9be88f9951d2263b23aa82818935aa3f733

Please note that Qubes 4.0 will use nftables (if available):
https://github.com/QubesOS/qubes-issues/issues/974#issuecomment-251825457

In T533#11156, @Patrick wrote:

• add timesync-fail-closed considerations to ipv4_input_rules / https://github.com/Whonix/whonix-ws-firewall/blob/master/usr/bin/whonix_firewall#L196

First I thought allowing incoming traffic on Whonix-Workstation in timesync-fail-closed mode would be okay, since outgoing traffic would be blocked. On a second thought, it would not be useful if a hidden service was reachable but the backend server could not reply (still blocked in timesync-fail-closed mode). So...

• https://github.com/Whonix/whonix-gw-firewall/commit/00823a325d104e04d065fda8ae96992d1f90e184
• https://github.com/Whonix/whonix-ws-firewall/commit/df5183dcecd62dae9329571c5ab0e57916bd6eb4
• https://github.com/Whonix/qubes-whonix/commit/1c99edbbce1f375591f2e42aaf679ba7492b4dd8

That's a good idea.

What about retrying qubes-whonix-torified-updates-proxy-check.service on
connection failure?

The current workaround (to unbreak Whonix developers repository) allowing full outgoing access to 127.0.0.1 is as bad as not implementing this ticket. (One could run apt-get update which results in uwt apt-get update connecting to 127.0.0.1, where Tor would accept it.)

I think it's a wrong link.

In T486#11057, @Patrick wrote:

I don't know what to think of this which warns of conntrack... https://lists.torproject.org/pipermail/tor-talk/2016-December/042717.html

I don't know what to think of this which warns of conntrack... https://lists.torproject.org/pipermail/tor-talk/2016-December/042717.html

Blocking outgoing connections to 127.0.0.1 in timesync-fail-closed mode creates massive issues. For example konsole starts but then is unresponsive (frozen) due to the blocked localhost tcp packages. (And since we'll stay with kwrite.) A solution needs to be found.

https://github.com/Whonix/rads/commit/168642875e30d202613d4e0274972ce5d18e102d

https://github.com/Whonix/whonix-gw-firewall/commit/f2dfc5c43cfe28a2b84b4543ee2f8eed07e7b4bd

netfilter-persistent still has too many issues. And I doubt it will be ready for Whonix 14. In meanwhile whonix-firewall.service will do. Maybe some day.

https://github.com/Whonix/security-misc/commit/6cda8b1496795422d4c0bfcea2ea2bf29c32daa0