Linux Prevent Leaks with Linux & Firestarter (also Stop traffic when VPN Drops)

[JamesDean 10]

Some of the newer features of UFW haven't arrived with the version you are

using. And although the GUI version of UFW is nice the command-line version

is much more advanced.

 

In the following quick tutorial...

 

 

This wasa GREAT tutorial! Worked perfect, thanks!

[JamesDean 10]

 

 

 

Isn't there a way to export those settings so we can just import them?

 

 

 

Just open up a text editor and paste all his commands in after you type sudo, then change for your set up eth0, wlan0, network and mask, ips of the servers you want (from the ovpn file set up to resolve in advanced settings) etc... Copy into terminal one by one. Took me a few minutes.

[acacia 0]

.... I have a slightly different need. I want to only have this kind of protection when I'm running certain programs, e.g. P2P, and otherwise allow normal internet traffic to "leak" if the VPN goes down. Of course, I could just put these rules into a separate firewall profile and switch to it before I run my P2P software, but that's a manual step that is both annoying and dangerous (because you could forget). What would be ideal is a firewall profile that could run all the time, allowing normal internet traffic (with or without the VPN active) and only VPN traffic for specific programs. For programs that allow binding to a specific interface, interface rules would be enough, but some don't have this feature. I think ufw has the ability to filter based on certain apps but I'll need to learn more about how to set that up. So, in theory, what I'm after is possible. If anyone already has some experience with that, I would appreciate some advice. Likewise, if I come up with something on my own, I'll post my solution.

 

The solution I found is to simply ALLOW out going traffic through gufw button, when i do not care about leaking, and when using DENY the outgoing traffic when I want NO leaking.

[acacia 0]

Thank you worric!

 

it works with debian wheezy and gufw+ufw

 

At first i had problems reconnecting because i had no idea what the server's IP was. however:

1. I was confusing my public airvpn IP with the airvpn server's IP, its NOT the same.
2. Sever IP can be found in its specific server.ovpn file generated to connect. If the file is opened with text editor (gedit or pluma, for example) one can find "remote xx.xx.xx.xx." where the xx are the servers IP.
3. The IP is only available in server.ovpn files and NOT in continent.ovpn or country.ovpn files.

So when leaking is not a real problem, or I want to connect to  a continent.ovpn or country.ovpn server:  I ALLOW outgoing traffic through gufw,

and when i want to avoid leaking or am using a server.ovpn I DENY outgoing through gufw.

I am guessing/experiencing this is the way to do it right.

 

Thank you again.

[InactiveUser 188]

 

• The IP is only available in server.ovpn files and NOT in continent.ovpn or country.ovpn files.

In fact, you can get IPs in the continent/country .ovpn files!

In the config generator at https://airvpn.org/generator/ , choose your continent/country, check "Advanced Mode" and enable "Resolved hosts in .ovpn file".

You can now take all the IPs from the .ovpn file and add them all to your firewall configuration. After that, it should no longer be necessary for you to disable ufw for using the continent/country .ovpn files.

 

Please try it that way; if it doesn't work (or if I haven't fully understood your use case), ask again.

[acacia 0]

 

 

• The IP is only available in server.ovpn files and NOT in continent.ovpn or country.ovpn files.

In fact, you can get IPs in the continent/country .ovpn files!

In the config generator at https://airvpn.org/generator/ , choose your continent/country, check "Advanced Mode" and enable "Resolved hosts in .ovpn file".

You can now take all the IPs from the .ovpn file and add them all to your firewall configuration. After that, it should no longer be necessary for you to disable ufw for using the continent/country .ovpn files.

 

Please try it that way; if it doesn't work (or if I haven't fully understood your use case), ask again.

 

Thank you sheivoko, works perfectly.

[CriticalRabbit 6]

Okay, I'm getting mega frustrated with this, as I cannot get this to work!!

 

Here's my setup.

 

I'm using a PC with Debian and it is directly connected to the wifi hub via a eithernet cable.

 

The confusion:

 

1: Do I need to type this? I've no idea what this means and if I need to add this line of text? $ ufw allow out to 192.168.178.0/24?

 

2: I've tried this line (e.g. ufw allow out to 192.168.178.0/24?) and then the following ufw allow out to 46.19.137.144 port 443 proto udp and ufw allow out on tun0 and I cannot connect the VPN. What am I doing wrong here?

[InactiveUser 188]

ufw allow out to 192.168.178.0/24

the rule allows you to connect to LAN addresses 192.168.178.1 to 192.168.178.254. Make sure that this is the correct address range for your LAN (check "ifconfig" if you're not sure).

Such a rule should not be necessary for VPN connectivity. If you need access to other LAN machines (e.g. the router's webinterface), you may add the rule.

 

ufw allow out to 46.19.137.144 port 443 proto udp

This rule's syntax is correct, it would let you use the VPN server at 46.19.137.144, 443/UDP.

The problem is, there's no such server! I've checked "AirVPN_All-servers_UDP-443.ovpn", there's no such entry IP. AirVPN exit IPs are different from AirVPN entry IPs!

 

As an example, if you want to use the "Cephei" server and have downloaded its configuration file "AirVPN_CA-Cephei_UDP-443.ovpn", it will contain the line:

remote 184.75.214.162 443

This is the entry IP for Cephei, the one you need to allow access to in your firewall.

 

ufw default deny outgoing

ufw default deny incoming

ufw allow out to 184.75.214.162 port 443 proto udp

ufw allow out on tun0

 

This rule set should allow you to use VPN server Cephei on 443/UDP.

 

If this did not resolve your problem, please be more verbose than "cannot connect". Go step by step to see where the problem lies:

 

Ping the correct entry server IP with firewall disabled ("ufw disable"). If you get a response, enable the firewall ("ufw enable") and ping again:

- If you don't get a response, fix the firewall rules.

- If you get a response, proceed. Connect with openvpn, if it doesn't connect, look at openvpn's log entries. It might be a good idea to use openvpn on the command line (instead of connecting with GUI network managers) to see the connection log.

[CriticalRabbit 6]

Hi,

 

Thank you for replying.

 

I did as you suggested and added the four rules (see below) but I still cannot connect to the VPN; it just remains on 'authenticating'. I did note, however, thatwhen I add the rule “ufw allow out on tun0” I get two entriues in gufw; I get “Anywhere ALLOW OUT Anywhere on tun0 (out) and I get “Anywhere (v6) ALLOW OUT Anywhere (v6) on tun0 (out). Do you think this is my problem?

 

e.g.

ufw default deny outgoing
ufw default deny incoming
ufw allow out to 184.75.214.162 port 443 proto udp
ufw allow out on tun0

[Believer_01 0]

Hello guys,

I will try the setup for ufw but I have one question:

In the posts are mentioned some IP of the servers mostly used, then I can I know the IP of the servers I use, to add a rule for them?
Thanks.

[Staff 10014]

Hello guys,

I will try the setup for ufw but I have one question:

In the posts are mentioned some IP of the servers mostly used, then I can I know the IP of the servers I use, to add a rule for them?

Thanks.

 

Hello!

 

You need to resolve server_name.airvpn.org

 

You can see the server names in our real time monitor https://airvpn.org/status

 

For example, to see the entry-IP address of Acrux:

 

 

$ nslookup acrux.airvpn.org
Server:        10.4.0.1
Address:    10.4.0.1#53

Non-authoritative answer:
Name:    acrux.airvpn.org
Address: 37.48.81.12

 

or even

 

 

$ dig @8.8.8.8 acrux.airvpn.org +short
37.48.81.12

 

Kind regards

[stupidcats 14]

Hi,

 

Thank you for replying.

 

I did as you suggested and added the four rules (see below) but I still cannot connect to the VPN; it just remains on 'authenticating'. I did note, however, that when I add the rule “ufw allow out on tun0” I get two entriues in gufw; I get “Anywhere ALLOW OUT Anywhere on tun0 (out) and I get “Anywhere (v6) ALLOW OUT Anywhere (v6) on tun0 (out). Do you think this is my problem?

 

e.g.

ufw default deny outgoing

ufw default deny incoming

ufw allow out to 184.75.214.162 port 443 proto udp

ufw allow out on tun0

 

I'm having the same problem as you. Did you find out how to fix it?

[CriticalRabbit 6]

Not yet, I'm awaiting a reply on another thread regarding this same issue. Hopefully there will be a fix with the vpn client. I'll update this once I find a fix though.

[fe719bf5 1]

I did as you suggested and added the four rules (see below) but I still cannot connect to the VPN; it just remains on 'authenticating'. I did note, however, that when I add the rule “ufw allow out on tun0” I get two entriues in gufw; I get “Anywhere ALLOW OUT Anywhere on tun0 (out) and I get “Anywhere (v6) ALLOW OUT Anywhere (v6) on tun0 (out). Do you think this is my problem?

 

I am using gufw and its FAQ states:

 

3. Some rules are added by themselves?

Well, the behaviour is such that when you change or import a profile, or when you edit a rule, Gufw readds that rule, then ufw readds for IPv4 and IPv6.

 

So it might just be that behaviour.

 

 

Why would I need to add the IPs of every single Server I connect to?

 

Couldn't I just deny incoming, deny outgoing and allow OUT any to any on tun0? This seems to  work on my end, if I'm not missing something crucial here....

 

Using gufw I connect to VPN in the default ufw-profile (deny incoming, allow outgoing, no specific rules; called "Home" in gufw) then switch to a custom profile I created with the above rule(s).

Then when I disconnect from VPN at least browsing and ping dont work anymore...

[iwih2gk 94]

If you are going to use UFW along with the client, I have found it extremely easy to enable UFW AFTER the client connects.  That way one simple rule.  ONLY tun0 period!!  This confines dns, dropped connection, and for me a BIGGIE --- > it isolates my device from the other devices on the LAN (not router).  The Eddie client network lock is OFF since its not needed in this configuration.  This configuration also allows me to select ANY server or protocol in the client preferences and then when connected I bring up UFW.  Simple to run!!

Something else for you to verify.  Are you using the network lock feature?  On my 14.04 linux system with the network lock feature on, I was still able to connect EVEN with the ufw tun0 only rule enabled.  I never did trace why but I confirmed it several times.  As soon as I turned off the network lock I could NOT connect with UFW enabled prior to running the client for a tunnel connection.

The 2.6 client is absolutely great for me.  I say connect with it and THEN bring up UFW with tun0 only.  You'll like how your system runs that way!!

[stupidcats 14]

Not yet, I'm awaiting a reply on another thread regarding this same issue. Hopefully there will be a fix with the vpn client. I'll update this once I find a fix though.

 

Do you've any news on this? Did you find out how to make this work?

 

I absolutely 100% need to make this work... The other day my VPN connection droped and I showed my real IP!!! I've needed to pick a different username for that site, which is really really bad, since I had already proven myself..

 

Why doesn't AirVPN create an option in "Eddie" to avoid all this confusion? Just something that we could check that'll make our internet unable to function without accessing throw the VPN..

 

@iwih2gk 

 

UFW works as intended IF I enable it after connecting to AirVPN. If I enable UFW before, however, I can't connect to the VPN. I'm having the same problem as CriticalRAbbit and I've no idea what the problem is!! Though truth be told, I'm an absolute noob when it comes to this.

 

I still think AIrVPN should provide us with an easier way to avoid connection drops.

[Staff 10014]

 

Why doesn't AirVPN create an option in "Eddie" to avoid all this confusion? Just something that we could check that'll make our internet unable to function without accessing throw the VPN..

 

Hello!

 

Since Eddie 2.5beta this option is implemented and its name is "Network Lock". It is implemented with plug-ins. In Linux, the available plug-in needs iptables, so all Linux systems which have iptables can use it. Eddie 2.6 is a stable version (no more beta) but the "Network Lock" option is still marked as "experimental", however no problems at all have been detected so far with iptables plug-in.

 

See also:

https://airvpn.org/topic/12175-network-lock

 

As usual, we recommend to follow "News and announcements" forum to remain up-to-date with constant AirVPN development in all fields. https://airvpn.org/forum/9-news-and-announcement

 

Updates are also published through "AirVPN" accounts in Twitter and Facebook.

 

Kind regards

[stupidcats 14]

@Staff

 

YES!! I knew there was a new feature on Eddie 2.6 named "Network Lock" and I knew what it was supposed to do, but I thought one needed to add rules, as one does in UFW.. I found that complicated.

 

I tried now the mode "auto" and it does as supposed! I've a suggestion however: 

 

- When the session is terminated, I think the network should be active by default, in case it happens when one is not counting on it.

 

This is perfect! Absolutely perfect! Thank you so much!! AirVPN 1 year subscription in-coming! Consider yourself kissed @Staff

[Staff 10014]

@Staff

 

YES!! I knew there was a new feature on Eddie 2.6 named "Network Lock" and I knew what it was supposed to do, but I thought one needed to add rules, as one does in UFW.. I found that complicated.

 

I tried now the mode "auto" and it does as supposed! I've a suggestion however: 

 

Hi,

 

we're glad to know it.

 

 

- When the session is terminated, I think the network should be active by default, in case it happens when one is not counting on it.

 

This is questionable... for security reasons Network Lock should remain active until the Eddie user explicitly turns it off or shuts down the client, because if a session is terminated abnormally but Eddie, for any reason that we have not foreseen, should not detect the anomaly, releasing the lock would be dangerous.

 

 

This is perfect! Absolutely perfect! Thank you so much!! AirVPN 1 year subscription in-coming! Consider yourself kissed @Staff

 

Thank you!

 

Kind regards

[Ultraman730 1]

Here is my low-tech solution to give warning when VPN drops:

 

Run your openvpn command from a bash script such as this one:

# !/bin/bash
sudo openvpn /path-to-ovpn-config-file/some-server.ovpn
eog  /path-to-some-image-file/filename.jpg
 

First you give the command to run openvpn, and this is followed by a command to open some graphic file using some graphic viewer such as eog (or substitute your favorite graphic viewer).

 

The logic is simple.  Since the eog command will not execute until the sudo openvpn /etc/etc command exits, when your connection is dropped, the chosen graphic will pop up in your face.  It is telling you that your VPN connection has dropped.

 

I am using Linux Mint (Ubuntu based), but this ought to work on any Linux distro.  Probably will also work with windows batch file as well, though no guarantee.

 

 

 

 

 

 

 

[Revhead 0]

So . . . I set up these firewall rules as per Randombit's instructions in post #47.

When I came home my PC (Kubuntu 14.04) had lost connectivity.

It showed it as connected to AirVPN but there was nothing coming in or out.

To get connectivity back I had to turn off the firewall, re-connect then turn it back on again.

Is this the way it is supposed to work?

 

I guess it is . . .

 

PS. Since upgrading to the latest version of Tixati V2.12, I occasionally have to turn off the firewall after adding new torrents otherwise it can't find any peers.

Tixati is reports "attempting to bind port" then throws up the error "unconfirmed incoming port" and is unable to receive incoming DHT packets.

If I turn off the firewall this DHT starts successfully. Obviously this is a problem with the firewall but this wasn't happening with earlier versions of Tixati. Has anyone else encountered this problem?

 

PPS. Changed the port number and it seems to be okay now. Don't understand why?

[grampa 0]

I followed the rules by rendombit https://airvpn.org/topic/5586-prevent-leaks-with-linux-firestarter-also-stop-traffic-when-vpn-drops/?p=14095 and everything works fine except I get this errors in journalctl:

 

NetworkManager[392]: <error> [1435491779.355596] [rdisc/nm-lndp-rdisc.c:68] send_rs(): (wlp6s0): cannot send router solicitation: -1.
NetworkManager[392]: <error> [1435491783.355069] [rdisc/nm-lndp-rdisc.c:68] send_rs(): (wlp6s0): cannot send router solicitation: -1.
NetworkManager[392]: <error> [1435491787.353743] [rdisc/nm-lndp-rdisc.c:68] send_rs(): (wlp6s0): cannot send router solicitation: -1.

When I add "ufw default allow outgoing" errors are gone. Is there any fix for that? I'm using Antergos (Gnome 3.16).

 

 

 

Edit: DHCP solved the problem

[don1234 0]

Personally I'm using gufw for linux, and it works very well.

 

However, it's important to remember that gufw is just a graphical frontend for ufw, and ufw, in turn, is just a friendlier system for manipulating IPTABLES (which is again a system for manipulating netfilter directly in the running kernel).

 

Gufw is perhaps over simplified, which is why I find it not really that great for anything else than providing an overview of your rules and turning the firewall on an off.

With regards to firestarter, I have tried it once, but I didn't really have any good experience with it, since, as you guys have already posted, it seems rather poorly coded and does some odd things when manipulating IPTABLES.

 

What I found invaluable about ufw is its ability to specify rules based on interface and its simplictity even though its quite powerful. This was my main motivation for using it over other solutions like Firestarter, and Shorewall was too complicated for my taste.

 

My rule approach goes like this:

Allow connections OUT to AirVPN servers I use the most (for connecting/reconnecting to the AirVPN service, entry IP's, marked RED on the screenshot)

Allow connections OUT FROM the tun0 interface TO anywhere (when I'm connected, this is the interface used to communicate to the Internet, marked GREEN on the screenshot)

Allow connections (UDP/TCP) IN TO the tun0 interface to a specific port (to enable AirVPN's port forwarding feature, marked BLUE on the screeshot)

Allow connections IN FROM the 192.168.1.0/24 network TO the eth0 interface (enable home networking. Notice how it's on a different interface, YELLOW)

Allow connections OUT FROM the eth0 interface TO the 192.168.1.0/24 network (enable home networking, also on the eth0 interface, YELLOW)

 

Block ALL other traffic (by choosing DENY/DENY in gufw)

 

When the VPN drops (and the tun0 interface is disabled), the only connections allowed OUT from the computer are to the AirVPN server IP's (to reconnect) and the local 192.168.1.0/24 network (to still function in the LAN). And the only connections allowed TO the computer are from the local network as well. No leaks.

 

Now, the gufw GUI doesn't allow for specifying the interface (remember, it's over simplified), so to do that, it's necessary to use ufw directly. Gufw can, however, display the rules when created by ufw.

For example:

 

"sudo allow out on tun0 from any to any" - is quite straightforward, and of course creates the rule that allows for communication TO the Internet when connected to AirVPN.

 

"sudo allow in on tun0 from any to any port xxxxx" - enables the port forwarding feature by allowing packets to the specified port on the tun0 interface to pass through.

 

Tips:

- the order of the rules is very important - mimic mine on the screenshot attached

- to add rules in a specific order from the command line, use "insert x": "sudo insert 3 allow in on tun0 from any to any port xxxxx" - inserts the rule at the 3rd position and moves rules below it downward, includin the previous rule nr 3.

- when adding rules via the commandline, press F5 in gufw to force a refresh and view the newly added rule

- the UFW manual is well worth reading, although you may not need any more information than offered in this post

- with this approach, you're blocking multicasting addresses possibly forwarded by your router. Just a thing to have in mind in case you need it; it is of couse easily remedied by creating a new rule allowing the address(es).

 

Let me know how this works for ya

 

Hello,

 

I've set up the firewall like worric and it seems to work. I don't have any connection while connected to airvpn. My issue is that I can still connect to any server not just the three servers that I put in the firewall rules.

 

Any help would be great.

[InactiveUser 188]

don1234, a manual iptables/ufw setup only makes sense for people who don't use AirVPN's "Eddie" client software:
The lock symbol in the upper right corner indicates that you're using Eddie's network lock feature. The network lock will temporarily replace your iptables ruleset, which is why your ufw rules won't have any effect while Eddie is running with network lock enabled.

I think you have two options:

• stop using ufw altogether
• keep using ufw with "Default Deny" Incoming & Outgoing

The latter would offer some additional protection for the times that the Eddie is not running / has not been started yet. There shouldn't be any complications as long you don't reload / re-enable ufw while Eddie is running. Just understand that once Eddie's network lock takes over, none of your ufw rules matter.

You can read more about Eddie's network lock here.

 

By the way, it looks like you're using Linux Mint Cinnamon - pressing the "print" key on your keyboard should put a screenshot in your "Pictures" folder! Alternatively, there's gnome-screenshot (which I'm pretty sure comes pre-installed) or shutter which offers more functionality.

[don1234 0]

Great... Thanks for the explanation.

 

Thanks for the Linux tip. Wanted to try it out so I'm still real new to it.