Search the Community

Hey guys, I followed the instructions and when attempting to connect I get to Initalization Sequence Completed and then.. Nothing. It just hangs it seems like. Anyone have any suggestions? I did an alt+C to cancel at the end to restore internet access. Mon Jun 17 12:04:40 2013 OpenVPN 2.2.1 x86_64-linux-gnu [sSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [iPv6 payload 20110424-2 (2.2RC2)] built on Feb 27 2013Mon Jun 17 12:04:40 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executablesMon Jun 17 12:04:40 2013 WARNING: file 'user.key' is group or others accessibleMon Jun 17 12:04:40 2013 LZO compression initializedMon Jun 17 12:04:40 2013 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]Mon Jun 17 12:04:40 2013 Socket Buffers: R=[229376->131072] S=[229376->131072]Mon Jun 17 12:04:40 2013 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]Mon Jun 17 12:04:40 2013 Local Options hash (VER=V4): '22188c5b'Mon Jun 17 12:04:40 2013 Expected Remote Options hash (VER=V4): 'a8f55717'Mon Jun 17 12:04:40 2013 UDPv4 link local: [undef]Mon Jun 17 12:04:40 2013 UDPv4 link remote: [AF_INET]149.255.33.154:443Mon Jun 17 12:04:40 2013 TLS: Initial packet from [AF_INET]149.255.33.154:443, sid=73901bca b6551ec2Mon Jun 17 12:04:40 2013 VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org_CA/emailAddress=info@airvpn.orgMon Jun 17 12:04:40 2013 VERIFY OK: nsCertType=SERVERMon Jun 17 12:04:40 2013 VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=server/emailAddress=info@airvpn.orgMon Jun 17 12:04:41 2013 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit keyMon Jun 17 12:04:41 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authenticationMon Jun 17 12:04:41 2013 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit keyMon Jun 17 12:04:41 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authenticationMon Jun 17 12:04:41 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSAMon Jun 17 12:04:41 2013 [server] Peer Connection Initiated with [AF_INET]149.255.33.154:443Mon Jun 17 12:04:43 2013 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)Mon Jun 17 12:04:43 2013 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.4.0.1,comp-lzo no,route 10.4.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.4.39.62 10.4.39.61'Mon Jun 17 12:04:43 2013 OPTIONS IMPORT: timers and/or timeouts modifiedMon Jun 17 12:04:43 2013 OPTIONS IMPORT: LZO parms modifiedMon Jun 17 12:04:43 2013 OPTIONS IMPORT: --ifconfig/up options modifiedMon Jun 17 12:04:43 2013 OPTIONS IMPORT: route options modifiedMon Jun 17 12:04:43 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modifiedMon Jun 17 12:04:43 2013 ROUTE default_gateway=192.168.3.30Mon Jun 17 12:04:43 2013 TUN/TAP device tun0 openedMon Jun 17 12:04:43 2013 TUN/TAP TX queue length set to 100Mon Jun 17 12:04:43 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0Mon Jun 17 12:04:43 2013 /sbin/ifconfig tun0 10.4.39.62 pointopoint 10.4.39.61 mtu 1500Mon Jun 17 12:04:43 2013 /sbin/route add -net 149.255.33.154 netmask 255.255.255.255 gw 192.168.3.30Mon Jun 17 12:04:43 2013 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.4.39.61Mon Jun 17 12:04:43 2013 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.4.39.61Mon Jun 17 12:04:43 2013 /sbin/route add -net 10.4.0.1 netmask 255.255.255.255 gw 10.4.39.61Mon Jun 17 12:04:43 2013 Initialization Sequence Completed^CMon Jun 17 12:05:10 2013 event_wait : Interrupted system call (code=4)

Hi, Just wanted to share a solution which (for me) continued from this post , which explained in great detail how to set up your OpenVPN with linux. After having followed the steps exactly, I was unable to click on the "Save" button to save my VPN configuration/import because the "save" button was just grey. No matter what I tried, the button just stayed grey. Having researched this topic on Google, I found many posts where other Linux users had the same problem and in some instances reported this as a bug. Like here for example. Well, as it turns out the answer is so simple, that I could kick myself for having not thought of such a simple solution earlier. The answer is right here on AirVPN. Normally when saving a configuration, you probably just save it from AirVPN onto your laptop or computer, right? Well, there is one single thing that you need to do prior to clicking the Generate button. Place a "tick" in the "Advanced Mode box. Then pick "Linux and others", and most importantly under Advanced pick "Separe keys/certs from .ovpn file". You then get seperate files: ca.crt, user.crt, user.key, and the .ovpn file. Then click the "Import" button button in your Network > VPN config section and import the .ovpn file. It automatically populates all the other fields with your other certificates and keys. And your "Save" button is now clickable.

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