VPN: Include default iptables rule for tun0 or at least optional

Reading this thread an old idea, which I actually put on hold some time ago, came back into my mind.
During this time I planned to "harden" my VPN connection, that means block any traffic that is not going through the vpn tunnel (especially in case the vpn tunnel is disconnected unintentionally).

My wish was, to set up iptables rules with starting the vpn connection by VPNmanager and flush these rules only when the vpn is disconnected (intentionally) by VPNmanager.
In this case the real IP would never be exposed, even if the vpn tunnel gets lost by whatever reason.

zomboided: Do you think, such kind of "general" iptables rules thing would make sense and could be integrated into your great addon?

Best regards,
Lars

hollol, I was thinking the same thing, but I'm not far enough along with that thinking and my understanding of how to manipulate the tables to know if this is possible. If you want to do some testing yourself, then see below, we might have a mechanism to do this...

infinity85, I've just upload version 2.2.4 which adds support for up/down scripts. I've only tested up scripts on Windows and it'll be a while before I get to test this on my LibreELEC boxes. If you want to create an 'up.sh' in your UserDefined directory, then reset the .ovpn files, then it should detect that you want to use an up script and update your user defined .ovpn files to include the right parameter to cause the script to run after the connection has been established. I think within this script you're wanting to put the iptable modifications you mentioned previously in this thread.

On Windows, the down script is not run. I think this is because of how I'm killing the task. On Linux, I use a more appropriate method of terminating the task which *may* allow the down script to run. As I said, I need to test on my LibreELEC box to know if this is the case.

There's a small amount of doc here Home · Zomboided/service.vpn.manager Wiki · GitHub but it pretty much covers what you know/I've just told you.

If this does work, then I might look to roll it out to all VPN providers, but to be honest I have no idea how many of them don't do some amount of firewalling/blocking for you. I might just be a handful that let everything in like you're seeing with Pure.

Quote from infinity85

I've tested it (honestly not completely understood how to use it):

To have some kind of reproducibility I went the usual way and used your provided *.ovpn scripts, i.e. "PureVPN" instead of "User-Default".

• At first chose a PureVPN server without up.sh. Got this error message:
  
  Code

  Error connecting to VPN, unrecognised option.
  Disable block-outside-dns in debug menu, reset ovpn files and retry.
  Or check log and review ovpn file in use.

  OpenVPN.log shows that in line 20 (ifconfig-nowarnscript-security) is an unrecognized option or missing parameter:
  Line 20: "ifconfig-nowarnscript-security 2"

• I was able to connect to VPN after deleting this line.
• Okay, so I went over to try the new up.sh method. I created the up.sh with the mentioned rules
• Tried reconnecting again:
  
  Code

  Options Error: --up script fails with '/storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh': Permission denied

• Apparently it has to be done chmod +x, so I did: chmod +x /storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh
• This solved the error, but led to another one:
  error in openVPN.log:
  
  
  Code

  Warning: External program may not be called unless '--script-security 2' or higher is enabled
  Warning: Failed running command (--up/--down): external program fork failed
  exiting due to fatal error

• so I added "script-security 2" to the ovpn file. Then this error showed up:
  
  
  Code

  /storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh tun0 1500 1558 136.0.5.201 255.255.255.224 init
  Warning: Failed running command (--up/--down): external program fork failed
  exiting due to fatal error

• I gave up after this

According to your wiki, the rules would be set 'after' establishing the connection. If that is true, then wouldn't that be a kind of risky solution?

Display More

Your script should run in isolation...you should be able to type up.sh and it execute. If you can't then this is a large part of the problem you're having. For Pure, there does seem to be some issues I'll need to look at. script-security 2 should be added with the up option but I can look and see why it's not happening.

As for a risky solution....maybe if you were being port scanned at DoS levels of activity. This is the way that openvpn expects to be used from what I can tell though so I'm not going to worry about this.

EDIT : Just noticed I did write the script-security 2 line, but the previous line (the one you deleted didn't have a line end). You can fix this by finding the template.txt file in the PureVPN directory in the addon directory and adding a return at the end of the last line. Then go delete the .ovpns and you'll be back to your final step which is your script failing. I've fixed this now, but will hold off rolling out another release until I've done some more testing myself.

Quote from infinity85

You're right, I had forgotten the headline "#!/bin/sh", now the up.sh is like this:

Bash

#!/bin/sh
iptables -F
iptables -A INPUT -i tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i tun0 -j DROP

And it does work indeed now. The rules are set after successful connection. But I took a look into OpenVPN.log and saw these to last lines (although VPN tunnel works):

Code

ERROR: Linux router add command failed: external program exited with error status: 2
Initialization Sequence completed

Anyway...after ignoring it, I played around a bit:

• Disconnecting the VPN does not flush the rules. They stay if I do "iptables -nvL". So flushing would be the purpose of a down.sh? If yes, then down.sh should be made the way that it only deletes the rules, which were introduced by up.sh upon connection attempt.
• Then I reverted the chmod +x up.sh, to see if it would work without this command.
• Result (without chmod +x up.sh) is this error again:
  
  Code

  Options Error: --up script fails with '/storage/.kodi/userdata/addon_data/service.vpn.manager/UserDefined/up.sh': Permission denied

So the script needs to be marked as executable. I'm no linux guy... is that possible to be done automatically without user interaction?

Yes, that's the purpose of down.sh. You can put whatever you want in either script. I've not tested whether down.sh runs - it doesn't on Windows (my test environment) as I was killing the task too hard. I think it might work on Linux. If you introduce down, you'll need to reset the ovpn files again or you can add in the command yourself.

The route command can fail if a route is already set, which would be my guess as to what's happening. You can check the iptable before and after to see if you're happy with the contents. If you are, don't worry about it. If you think the routing is wrong, then try and work out what your modifications are doing to break it (assuming the VPN provider isn't pushing crap at you on connection)

chmod changes the permissions of a file. It you don't give it permission to run, then it won't, that's the way Linux works. Set it to the correct permission and leave it alone. You shouldn't need to do it more than once.