Search the Community

This guide shows how to set rules to prevent leaks in case of unexpected VPN disconnection and provides you with clear scripts ready to be used with basic modifications on Red Hat Enterprise Linux and RHEL rebuilds such as Oracle Linux, Scientific Linux, X/OS, CentOS etc. THANKS TO JESSEZ - ORIGINAL POST BY JESSEZ (minor editing & clean-up by Air staff) This method requires the ipset package: sudo yum install ipsetRHEL 6 and rebuilds (Oracle Linux, Scientific Linux and CentOS) do not have a kmod-ipset that I could find. The ip_set module has to be loaded manually as neither netfilter, iptables nor conntrack call the module themselves. As far as I know some Linux distros do have a kmod for ip_set so that would make usage of sysconfig/ipset.conf not necessary and also could cause a boot-time error (fatal nor not). The ip_set module has to be loaded and a script run to load the ip_set script (creates and contains the AirVPN server IP addresses) so that there is a table to be read by the time iptables_restore runs (otherwise iptables_restore throws the error that no ipset "airvpn" exists). So there are 3 files. The first and the second file can be found attached to this message. The last one is a system file that needs a modification. 1 /etc/sysconfig/ipset.conf This script tests whether the ip_set module is already loaded. If not it loads it into the kernel (modprobe). ipset.conf.txt 2 /etc/sysconfig/ipset-airvpn.sh This file creates and fills the ip_set table of AirVPN server addresses. I haven't listed the servers, so that no-one can just open the file and get the server IPs. Add the ones you want where the a.b.c.d 's are. Add or subtract lines as necessary. I think I added enough buffers so that all the servers should be able to go into the table (which lives in RAM while the system is up and is lost at shutdown/re-start). After running the script use: sudo ipset -L airvpn -to make sure all the servers you added to the script are there (It's easiest just to count the lines if you know how many servers you added in the first place), if not, change the part: hashsize 65536 to the next larger: hashsize 131072 (doing this obviously eats up RAM, so don't change it unless you need to) and note that the hashsize can start at 1024 and can only be a power of 2 (1024, 2048, 4096, ..., 131072...) If you're only using one or two servers and you need to save RAM, just change it down, re-run the script and issue the command sudo ipset -L airvpn again to check that all the desired servers are listed. Keep doubling the hashsize until they are. If anyone is wondering about the -exist option, it's there so that in case of accidental duplication of an IP address the script won't fail. iptables-airvpn_2013-01-19.txt 3 /etc/init.d/iptables This is the system file, so be careful; add 2 new lines that become line 55 and line 56: # Load /etc/sysconfig/ipset-airvpn.sh to make the airvpn table sh /etc/sysconfig/ipset-airvpn.sh Ok, that should be it, iptables and the "airvpn" ipset table should now survive a reboot with no errors. Test by rebooting, and trying Internet access of any and /or several kind(s) before starting a VPN connection when the desktop is up. If it's working you will have no Internet before starting a VPN connection, and you will be able to connect to any of the servers you added to ipset-airvpn.sh without OpenVPN throwing an error (probably: write UDPv4 []: Operation not permitted (code=1)). Note: rename the attached files according to the names given above. Put the files in the appropriate folders as listed above. Regards, jz

EDITED ON 21 Aug 12 EDITED ON 24 Nov 12: added important note for some Linux users, see bottom of message EDITED ON 02 Jun 15: please refer to https://airvpn.org/faq/software_lock for a more advanced set of rules WARNING: this guide assumes that you have no IPv6 connectivity. If you have, you should block outgoing IPv6 packets while connected to the VPN with "ip6tables". Please see https://airvpn.org/faq/software_lock Hello! You can use iptables, a very powerful packet filtering and NAT program (probably one of the most powerful, if not the most powerful of all). iptables is already included in all official Ubuntu distros and most Linux distros, anyway if you don't have it just install it with aptitude. Adding the following simple rules will prevent leaks in case of [accidental] VPN disconnection. In this example, it is assumed that your network interface is eth+ (change it as appropriate; for example, you might have wlan0 for a WiFi connection). a.b.c.d is the entry-IP address of the Air server you connect to. You can find out the address simply looking at the line "remote" of your air.ovpn configuration file. In case of doubts, just ask us. Some of the following rules might be redundant if you have already chains. Assumptions: you are in a 192.168.0.0/16 network and your router is a DHCP server. You have a a physical network interface named eth*. The tun adapter is tun* and the loopback interface is lo. iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #allow loopback access iptables -A OUTPUT -d 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server iptables -A INPUT -s 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server iptables -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT #make sure that you can communicate within your own network iptables -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i eth+ -o tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth+ -j ACCEPT # make sure that eth+ and tun+ can communicate iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE # in the POSTROUTING chain of the NAT table, map the tun+ interface outgoing packet IP address, cease examining rules and let the header be modified, so that we don't have to worry about ports or any other issue - please check this rule with care if you have already a NAT table in your chain iptables -A OUTPUT -o eth+ ! -d a.b.c.d -j DROP # if destination for outgoing packet on eth+ is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects When you add the above rules, take care about pre-existing rules, if you have already some tables, and always perform a test to verify that the subsequent behavior is what you expect: when you disconnect from the VPN, all outgoing traffic should be blocked, except for a reconnection to an Air server. In order to block specific programs only, some more sophisticated usage of iptables is needed, and you will also need to know which ports those programs use. See "man iptables" for all the features and how to make the above rules persistent or not according to your needs. Warning: the following applies ONLY for Linux users who don't have resolvconf installed and don't use up & down OpenVPN directives with update-resolv-conf script In this case, your system has no way to process the DNS push from our servers. Therefore your system will just tunnel the DNS queries with destination the DNS IP address specified in the "nameserver" lines of the /etc/resolv.conf file. But if your first nameserver is your router IP, the queries will be sent to your router which in turn will send them out unencrypted. Solution is straightforward: edit the /etc/resolv.conf file and add the following line at the top (just an example, of course you can use any of your favorite DNS, as long as it is NOT your router): nameserver 10.4.0.1 # in order to use AirVPN DNS nameserver 31.220.5.106 # in order to use OpenNIC DNS only if AirVPN DNS is unavailable Kind regards Original thread post: https://airvpn.org/topic/1713-win-mac-bsd-block-traffic-when-vpn-disconnects/page-2?do=findComment&comment=2010

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