wiki: Tunnels/Connecting_to_a_VPN ... VPN_FIREWALL=0 - broken.

From Template:Firewall_Settings:
``> sudo nano /etc/whonix_firewall.d/50_user.conf

Content duplicated at both Connecting_to_a_VPN_before_Tor and Using_Tunnels_with_Whonix:
> 2. Add the following settings. ... > ###########################
> ## VPN-Firewall Settings ## > ###########################

``- de-dup content by making it into a wiki template section as Template:Firewall_Settings is?

Having made a 50_user.conf file as per wiki / text contents, with the following (active content) changed / lines:

… result … no -gateway network / tor at reboot.

Move file up a level temporarily, reboot, network / tor functional again.

isn’t being adhered to, despite wiki article’s comments indicating 0 = disable vpn firewall. i.e. Same default as if not set / file not present.

``- feels like a bug.

``- left unchanged from wiki text. Since VPN_FIREWALL=0 set, settings weren’t expected to be adhered to / impact anything.

; LOCAL_NET="" - is the wiki text with a comment (;) character in front.

Could the wiki text be updated to indicate that ‘;’ is/n’t (also?) a valid commenting character?
e.g. '```## ; may also|not be used as a comment indicator’`

In any case, perhaps something after the
line above is being processed when it shouldn’t be. Either code is not checking for VPN_FIREWALL=0 at each setting, or lines post VPN_FIREWALL=0 are not being turfed unless/until a VPN_FIREWALL=1 entry is encountered.

How I got here: Having come across the code in reading through the wiki, I popped the file in (‘neutered’) in preparation for attempting vpn at some later time. I expected VPN_FIREWALL=0 to render all to defaults per wiki coded comments, as though the file were not present at all.

(Being somewhat familiar with OpenVPN), I do expect VPN_INTERFACE=tun0 will be accurate, so left it alone. The need to change VPN_SERVERS would be intuitively obvious to change when I got to the point of going back in to turn VPN on. I commented out (with ‘;’) LOCAL_NET … knowing I would have to figure out entries correct for my particular environment when I got that far. Not being certain that the example line would be 100% accurate then, I just commented the line out.

VPN_FIREWALL=0 - breaks networking / doesn’t do the expected (at least per wiki comments).

Arguably, someone making such a change and rebooting would be able to correlate cause and effect, reverse, and reboot - however, if one made more than one change before rebooting, they could spend a great deal of time playing hunt the wumpus before cottoning on to the specific cause and effective impact. With the net (and thus ability to peruse the wiki) down at the time. And, if they thought to reboot to effect the change, upon reversal.

Thus, additional suggestion: add to the wiki how to effect/reverse the change without rebooting (in the wiki affected articles).

``- firewall restart of #whonix_firewall (as per Dev/Build_Documentation/0.3.0 didn’t do it.

Not duplication. That’s currently being rewritten.

⚓ T125 Tunnel, VPN, proxy, SSH documentation needs to be restructured

You won’t find Connecting to a VPN before Tor in documentation yet.
Combining Tunnels with Tor will be moved to


Should add: With the (thought to be neutral) file in place, route was

default UG 0 0 0 eth1

``- I think. Definitely .15 and eth1. (Rebooting cleared /tmp where I had piped the output, so I’m going from memory.)

In any case, with .15 and eth1, was obviously wonky / never gonna work.

Instead of the normal:

default UG 0 0 0 eth0

; is not a valid configuration file comment. Many others aren’t either. Firewall config is a bash fragment. I don’t think it makes sense to point out all the invalid commenting characters. Aren’t there too many of them?

## ; works.

It already says…

You can skip comments (starting with #)

whonix-gateway config parsing code is quite simple in Whonix 12:

And even simpler in Whonix 13:

Dev/Build_Documentation/0.3.0 is only kept for historical purposes.

If you mess up firewall config, and after boot, then firewall will fail, networking will not come up. if-pre-up.d will fail.
( )
This is a security feature. Don’t mess up firewall config. You should have noticed that error during the step “reload firewall”.

That might also explain route.

Can you add this in the following style please?

If you want to undo these settings, please press expand on the right.

(Then use wiki markup for expand buttons. You can see an example usage for example here: Configure (Private) (Obfuscated) Tor Bridges)

(just get rid of all config changes - delete the 50_user config files - reload firewall)

[quote=“Patrick, post:4, topic:1741”]
; is not a valid configuration file comment. Many others aren’t either. Firewall config is a bash fragment. I don’t think it makes sense to point out all the invalid commenting characters. Aren’t there too many of them?[/quote]

In many bash places, ; is. A quick check in my system shows openvpn, smb. A not uncommon convention is something like # for config elements, ; for site specific elements. I don’t think suggesting a line of:
``## Note: ; is not a valid comment starting character in this file.
is unreasonable. You are, of course, free to reject the suggestion.


Fair enough, but searching brought the article up. I take your point, but how is the new / quick reader to know what to pay attention to and what not.

In the mean time, perhaps a blurb in the wiki so that such searches bring up correct information would be useful.

[quote]whonix-gateway config parsing code is quite simple in Whonix 12:

And even simpler in Whonix 13:[/quote]

Not sure what you’re point me to at these links. Commenting examples? Or noting the entries the code permits?

I think you are missing the point / bug report I intended:
File says:

## Make sure Tor always connects through the VPN.
## Enable: 1
## Disable: 0
## DISABELD BY DEFAULT, because it requires a VPN provider.

Which is to say, whether the file is present (with VPN_FIREWALL=0 set), or not present - the same behavior should result. It didn’t. Which, at the least, is unexpected, per the comments in the file.

I don’t disagree that self-inflicted user messing up pf the file - deserves whatever happens.
(e.g. my prefixing a line with ; instead of #.)

My point is the user following the instructions present got unexpected (and unreasonable - broken network, and broken ability to research solution) result.

i.e. As per initial report, something isn’t being ignored as one would expect - I was suggesting that perhaps there is something to look at here. Full stop.

I’m not saying adding a line along the lines of:

Unless you have implemented a VPN, leave VPN_FIREWALL entirely commented out, or remove the file.

Else … you WILL break your network in the mean time.

isn’t a complete and appropriate solution. I wouldn’t know - never mind VPN_FIREWALL=0 being present is working as expected or not.

Will try to do both, and report back. (a) behaviour change with # instead of ; (b) behaviour change with all lines commented out.

Yes, I can do that.

I saw examples of expand use, so I should be able to cut and paste.

Except … so how does one, having changed the file, kick it in the knee to reread it?

service whonix_firewall restart


[quote=“rAntOCauDgb, post:7, topic:1741”]Except … so how does one, having changed the file, kick it in the knee to reread it?

service whonix_firewall restart


Sorry, I now see it’s # whonix_firewall , per Connecting_to_a_VPN_before_Tor#How_to_add_the_VPN_in_Whonix-Gateway

Confirmed: Changing ; to # leaves ifconfig / route / ip route the same as if the file were not present.



that is.

Presuming ; is being taken as a bash line separator, this leaves "LOCAL_NET=“” impactful.

Which feels like undesirable behaviour. i.e. The user using the wiki lines, and forgetting to change it for their particular environment, should be left with unchanged behaviour.

Arguable VPN_FIREWALL=0, not VPN_FIREWALL=1, should be in the article, on that basis. Granted, the whole point of the article is to implement VPN. (Guess this is the ‘do not harm by default’ principle. Chicken and egg here, in this case.)

More telling, /usr/bin/whonix_firewall contains:

[ -n “$LOCAL_NET” ] || LOCAL_NET=“”

which is the same as the wiki article. So that a behaviour change occurred is … unexpected. (?)

Further, /usr/bin/whonix_firewall contains:

if [ “$VPN_FIREWALL” = “1” ]; then
for NET in $LOCAL_NET; do
$iptables_cmd -A OUTPUT -d “$NET” -j ACCEPT

So (a), VPN_FIREWALL=0 means this code would not have been executed.

And even if it was, (b) the result would be:

iptables -A OUTPUT -d ; -j ACCEPT

iptables v1.4.21: option “-d” requires an argument
Try `iptables -h’ or ‘iptables --help’ for more information.
-j: command not found

``- of no impact.

That there was an impact is … unhappiness.

Correction: Using ; instead of # results in:

root@host:/etc/whonix_firewall.d# set -v -x
root@host:/etc/whonix_firewall.d# whonix_firewall

  • whonix_firewall
    Invalid config file: /etc/whonix_firewall.d/50_user.conf
    bash_n_exit_code: 2
    /etc/whonix_firewall.d/50_user.conf: line 24: syntax error near unexpected token ;' /etc/whonix_firewall.d/50_user.conf: line 24:; LOCAL_NET=“”'

So the impact of the ; is a bail in the script.

Rebooting, leaving the ; in place, duplicates the initial report. A route of

Destination Gateway Genmask Flags Metric Ref Use Iface
default UG 1024 0 0 eth1

Granted: buyer beware, user self-inflicted, theirs to deal with.

However, a firewall restart of “# whonix_firewall” with the ; changed back to a # leaves that route in place. Only a reboot fixes things. Unhappiness.

Unsure as to what, if any, coding defences could be put in place here. Even if doing so were reasonable - and I’m not convinced it is. User broke it, up to user to fix it. (Too many ways a script could be user-inflicted broken, and they keep building better idiots such as myself.)

At the least, however, I can so comment in the wiki changes.

Assuming ‘# whonix_firewall’ is the correct incantation, that running it didn’t fix things is obviously unexpected (at least per the documentation / wiki).

Still feels like there’s a bug here, though. With VPN_FIREWALL=0, that section of the code doesn’t get executed. (But if the script bails, it bails, nothing one can do about it but live with the result, find and fix and reboot.)

Where exactly does the wiki ever say VPN_FIREWALL=0?

Search results for "VPN_FIREWALL" - Whonix

It’s always VPN_FIREWALL=1.

What do you think what VPN_FIREWALL=1 does?

I don’t get what you mean by “many bash places”. Your local shell does not matter. The language the tool written in matters. openvpn/smb aren’t written in sh or bash.

Can do.

I think you’re misunderstanding what I meant by that comment.

The wiki page notes that VPN_FIREWALL=0 disables talking through the VPN.
(2 lines above the VPN_FIREWALL=1 line. [Thus, the wiki essentially says/mentions VPN_FIREWALL=0.]

So, one of my comments was, there is a school of thought that defaults (even in documentation), should ‘do no harm’. So it is arguable that the wiki page use VPN_FIREWALL=0, with a note to say “change if you install VPN”. (However, as also commented, the point of the page is enabling VPN, so … agreed, those principles [do no harm / what are we describing] are diametrically opposed.)

I also noted I used VPN_FIREWALL=0 to get the file in place, neutered, as sort of a visual reminder to make appropriate changes when I got that far, but have not yet gotten as far as installing it (VPN).

I’ve lost track of where / why you’re asking “Where exactly does the wiki ever say VPN_FIREWALL=0?” - remind me.

I also noted (at one point) that the presence of VPN_FIREWALL=0 in the file, vs the lack of the file entirely, should effect equivalent behaviour. (* Which it does, in the end.)

``- this comment[1] was made while working through what / how my initially posted file was breaking things (or a bug to be reported). The end of that comment was … ‘;’ broke things in ways unanticipatable, and once replaced with ‘#’ the expected behaviour applies, and thus that comment[1] no longer applied.

[quote=“Patrick, post:11, topic:1741”]many bash places, ; is. A quick check in my system shows openvpn, smb.

I don’t get what you mean by “many bash places”. Your local shell does not matter. The language the tool written in matters. openvpn/smb aren’t written in sh or bash.[/quote]

Mmmm … not entirely. Not so much the tool, as the environment.

And in this case, the environment is Linux. Or, ‘configuration files’. The user neither knows nor cares what the tool is written in, whether it is a script or a binary config file user or caller, they’re following instructions to modify a config file.

[And Linux gets enough complaints of don’t make me relearn everything with each new tool.]

So … what seems to have been tending to happen (in Linux) is multiple configuration file consumers gravitating towards a common set of commenting / configuration file usage.

Having worked through things now, as in prior messages - I quite agree, the whonix_firewall environment does not permit the use of ; for comments / you have no choice.

However, for the user, which tool, and it’s environment, doesn’t matter - it’s a configuration file. (And configuration files tend to have certain conventions - although agreed, not as many things as we would like adhere to them. Arguably - too bad anyone ever used ; for commenting in the first place. But we are where we are.)

Thus the request of noting that ; doesn’t work, as noted - as a more polite way of kicking the user in the head than “Don’t Do That - Stupid!” :smile:

If I did it, others will, and when whonix_firewall goes bad … it goes very bad.

So, I thank you for agreeing to put a warning in: hopefully it will save someone else the (self-inflicted) internetless head scratching that I went through.

Adding a comment of … “Don’t forget to re-run whonix_firewall, and/or reboot if you change this file.” won’t hurt either. (Since fixing my botched file and reruning whonix_firewall wouldn’t have fixed the damage booting from the damaged file did - only rebooting fixes it.)

That would result in iptables exiting non-zero, which would be caught by Whonix firewall error handler. Firewall would fail.

I don’t understand. Please post a github pull request. Just press edit on and make the modification you suggest. Then I might understand better.

It works as expected. With variable VPN_FIREWALL=0 or unset…

The following is executed. That’s the default. (Because the default is VPN_FIREWALL not being set to 1.)

$iptables_cmd -t nat -A OUTPUT -m iprange --dst-range "$NET" -j RETURN

Works as expected.

(NON_TOR_GATEWAY is only for non-VPN.)

Also the following…

Works as expected. The above code runs always, unless VPN_FIREWALL=1.

(NON_TOR_GATEWAY is only for non-VPN.)

Also the following…

Works as expected. That code is only executed if VPN_FIREWALL=1.

(LOCAL_NET is only for VPN.)