how to unset firewall array

I want to be able to close all firewall ports that are used by default for whonix and open just a select few, and this of course has to be done solely on /usr/local/etc/torrc.d/50_user.conf.

This is targeted to single use Workstations that should only have access to the internet if a socksport is specified to the application.

I tried on the gateway:
and browsed for how to unset array. It works on the cli if I test with arrays, but not with whonix firewall, maybe it is the way the firewall is parsed?

It is a problem with how the firewall is parsed.

source_config_folder function is called before the defaults is assigned.

The correct function order is:

main() {
   variables_defaults ## defaults first
   source_config_folder ## user conf later


If this is not done, user can not reset the firewall with INTERNAL_OPEN_PORTS=""
then the next firewall ports that he user wants open are specified below that line:


can this be done?

1 Like

If you are afraid someone will close all their internal firewall ports, then I suggest a new variable INTERNAL_CLOSE_ALL=[0|1].
So people will be recommended to use that instead of INTERNAL_OPEN_PORT="" that will reset everything because there is no plug sign.

1 Like

No external port is open by default. So I don’t see a need to use it with external open ports, but maybe good to add for compatibility.

But anyway, maybe it is important to inform in the firewall message that an option to close all ports was set, even if that option is overriden by the next option that includes some ports.
Or not, because that option should only be set on /usr/local/etc/whonix_firewall.d/50_user.conf, so it is easier to debug.

1 Like

Reminds me… On variable initialization generally…

whonix-gateway-firewall currently only using this style:

   ## Socks Ports for per application circuits.

I liked that style because nobody was asking how to remove any such ports ever and because then each port could be easily commented.

It’s run in function variables_defaults. But function source_config_folder runs before that. Therefore you cannot unset it in config but no worries you can do it another way. On top of it there is:

   if [ ! "$WORKSTATION_ALLOW_SOCKSIFIED" = "1" ]; then
      return 0

So in the gateway firewall config just set:


In result, no INTERNAL_OPEN_PORTS will be set at all. Then it would be up to the user to configure INTERNAL_OPEN_PORTS or not use any of these ports.

How does that sound?

WORKSTATION_ALLOW_SOCKSIFIED=0 already has the same purpose, good?

Then we’d have to check if that variable is unset versus set to "" (empty). Would also be an interesting. Contributions welcome.

If WORKSTATION_ALLOW_SOCKSIFIED=0 is set for sure would be good to have an info message for that.

Disable Transparent Proxying?

Sounds good, exactly that what I want. I was searching in the wrong place.

Seeing the code, I don’t think it is possible to check it was set to empty because the scripts are sourced in source_config_folder, so at the end, the calling script will only know the result of the array that could be non empty if the person set it first to be empty then only assigned certain ports.

[quote=“Patrick, post:4, topic:15604”]

[quote=“nyxnor, post:1, topic:15604”]
This is targeted to single use Workstations that should only have access to the internet if a socksport is specified to the application.

I think this is a better solution.

Yest. I think this applies also, not alone, but in combination with WORKSTATION_ALLOW_SOCKSIFIED=0.

Example: I want only socks ports that have a specified set of isolation flags, so not using 9050 because it doesn’t have one. This would enforce me to set the correct socks port per application, not configuring 9050 for everything because it is just easy to remember.

Edit: another example is an application that defaults to SocksPort 9050, but I only want applications to work with the ports with isolation flags that I want to be used.

1 Like

This does not allow me to set my close all socks ports and only allow my custom ports.


      ## Allow socksified applications.
      if [ "$WORKSTATION_ALLOW_SOCKSIFIED" = "1" ]; then
         for socks_port in $INTERNAL_OPEN_PORTS; do
            true "socks_port: $socks_port"
            $iptables_cmd -A INPUT -i "$int_tif_item" -p tcp --dport "$socks_port" -j ACCEPT


because no socks port is allowed by this method, which I can’t deny I a good behavior from the expectation I have from the name of the variable, to not allow any socks port.

This brings me back to my first post.

  1. change the functions order, defaults should be called before user config, as it happens for user to override system config on other packages
  3. set only the ports you want on INTERNAL_OPEN_PORTS
  4. adrelanos: plus disable transparent tcp and dns with WORKSTATION_TRANSPARENT_TCP=0 and WORKSTATION_TRANSPARENT_DNS=0

Change the script to source defaults before user config and include this in the user config:

# either option works to unset internal open ports:
# unset is the most explicit and easy way to notice
# also easy to notice
# or setting the below to not use the plus sign before the equal.
# it may be too simple that you don't even notice the missing
# plus sign so I recommend not using it and prefer one of the
# above methods instead


So the question is, can I PR to change script sourcing order for defaults first and then user config so the above can work?

1 Like

Yes, please.

Could you please check as per How to refactor the firewall script while being sure there are no iptables changes that the actual firewall rules are unchanged after the change?

1 Like


1 Like
1 Like

There’s merge conflict.

But manually done now. The order of functions is now:


Also firewall_mode_detection seems to make more sense after variables_defaults and source_config_folder.

1 Like

probably because of two consecutive PRs without one first merging upstream, so I couldn’t rebase that.

1 Like

Yes. No big deal in this case. In the future, would it be good to assume that the previous PR will be merged?

Added some minor commits on top. Would be good if you could have a look if these make sense.

Ok, I just have the habit of branching from upstream/master, but I can do origin/last-pr-branch.

Saw it, makes sense.

1 Like