Search the Community

i'm currently using airVPN and i'm getting a DNS leak as per ipleak.net . i've tried the netherlands and german servers. I tried ipleak using IPVanish and no leaks. It's worth mentioning i forwarded 1 port on air VPN to allow transmission torrent client to use thta port. I'm on pi OS on a raspberry pi 5. is there some guide a novice could follow for setting static IP and DNS on pi OS?

I thought I'd share some links I've found to check for DNS leaks: http://www.dnsleaktest.com http://ipleak.net/ If you see your real IP or another IP (other than the one that you are connected to by VPN) then you have a DNS leak. You should fix it by setting static IP and DNS server settings on your network adapter. I've written a step-by-step guide for people unfamiliar with network and IP settings. Instructions on how to make your IP settings static for Windows 7: You might be asked to elevate system priviledges or authenticate as Admin while you perform these steps, just allow it all. Click on the network icon on the taskbar (the lower right screen near the clock) -> Click on "Network and sharing center" -> Click on "Change adapter settings" on the menu to the left. You need to know your router's network settings before you continue: Right click on your network adapter (Local area connection if you're connected by a LAN cable or Wireless network connection if WiFi) and choose "Status" -> Click on "Details...". There you should notice your "IPv4 Address", "IPv4 Subnet Mask", "IPv4 Default Gateway" and "IPv4 DNS Server". Click "Close" and again "Close". Right click on your network adapter and choose "Properties" -> Click on "Internet Protocol Version 4" (don't un-check it) and click "Properties". Select the "Use the following IP address" button. IP address: When you noticed your "IPv4 Address" in the "Details" screen earler, it might have looked like this: 192.168.0.1 or 192.168.1.1. This was an IP address assigned by the DHCP pool on your router and happens automatically. You might think to put in the same IP address as you saw in the "Details" window but if you do that, the IP address might be assigned to another computer while your computer is turned off. You should choose an IP address that's much higher than your current IP address so it will be unlikely that another computer will get the same IP address from the DHCP pool. When you put in the "IP address" on the "Properties" screen, you should put in the same first three numbers (e.g. 192.168.0.) and then the last number should be a random number between 100 and 250. It doesn't really matter what number you choose, you are just choosing a number that should be unused on your local LAN. If you get an error about an "IP address conflict", you should choose another last number in the IP address. Subnet mask: Copy the "IPv4 Subnet Mask" from earlier. Default gateway: Copy the "IPv4 Default Gateway" from earlier. This is the IP address of your router. Preferred DNS server: Put in "10.4.0.1". This is AirVPN's DNS server. Alternate DNS server: Put in "10.5.0.1". AirVPN's DNS server. What you have done here is tell Windows to only use AirVPN's DNS servers instead of your routers (or ISP's) DNS servers. If you are not connected to an AirVPN server, you cannot go to the internet unless you put in your normal DNS server settings that you should have noticed in the "Details" screen before (IPv4 DNS Server above). You can also put AirVPN's website IP address in your "Hosts" file. This means that you can get to Airvpn.org to download a config without constantly changing your DNS server settings. Here's how you do it: Open notepad.exe as Admin (Right click -> Run as Administrator). Go to File -> Open. You need to navigate to this folder: "C:\Windows\System32\drivers\etc" and it might involve changing folder settings ("Organize" -> "Folder and search options") to show hidden files (View -> Show hidden files). The folder might appear to be empty but change the document type from "Text Document" to "All files" and then open the file called "hosts". Put in this lines at the bottom: 95.211.138.143 airvpn.org Then save the file as "hosts" and overwrite the old one. If you didn't run notepad.exe as Admin then you can't save the file. Hopefully this guide will help people. If there are any questions, just ask!

Topic may be deleted.

I have had a problem with BBC iPlayer. When I was in France at the beginning of Sept I was blocked when using Airvpn, On returning to the UK on Sept 4, with the same server activated on my iPad, I could connect. However, that could be because you had fixed the issue as you posted Sept 5th. However, I did other tests with the iPlayer which I have just re-checked. I am in the UK. My iPad is connected to Europe, and my iMac to Switzerland. However I can reach iPlayer and play programmes on both devices. Why is BBC not blocking me? I have cleared all the bbc cookies from my browser. Can they see through the VPN to identify me as a UK based system? I have checked ipleak.net and that site does not detect a leak and I have used Eddie and Visocity. Do I have a cause for concern? Thanks

Can anyone comment on this report done on vpn leak tests and tell me if these issues have now been fixed on Eddie Mac OS X client please. Or in fact if it ever was a genuine problem. also any IVPN users who have anything to say about that vpn service seeing as they sponsored it. Sorry im not sure on the date it was done so this topic might already be on this forum somewhere but a search here didn't bring any result. heres the link to the report https://vpntesting.info

Greetings, Long Story short; I have a Netgate APU with pfSense configured with one "Clear" Network, i.e. no VPN connection, and one VPN Network connected to AirVPN. The clear network has the WiFi AP on it, and most of the time, my laptop (Fedora 25) is connected to the Clear network, but is connected to another VPN provider separately. However, running DNS leak test (dnsleaktest.org, whoer.net etc) sometimes shows the AirVPN DNS on the Clear network, both then devices are connected to a seperate VPN on the clear network, and when they are not. Is this an AirVPN issue, or some sort of lacking pfSense configuration? Would this perhaps be a questions better suited for the pfSense forum? Thanks for any help.

I was testing my security using this site: https://ipleak.net/ While the IP and DNS is secure, and even torrents. It still got through with the WebRTC check. Is there any way to stop this leak?

Hello, This is probably a config issue from a network noob. I believe my browser traffic is going through AirVPN because I cannot get to any site without the client active. But pings, tracert and some updates (COMODO firewall) show traffic without it up. I am using the TAP9 adapter. Does this mean I have a leak? Part 2 I also play video games through Steam - I don't think I need a vpn - can I buy pass it? If so - how? Thanks, Mr. V

Hello, Prior to having trouble I was using an older version of Comodo Firewall that had a GUI similar to the one in this post: https://airvpn.org/topic/3405-windows-comodo-prevent-leaks/ (sorry I don't recall the exact version). The firewall was working fine and prevented any form of leaks when AirVPN was disconnected for whatever reason. Upon doing a clean install of Comodo Firewall two days ago and reconfiguring the global rules as described in the tutorial above traffic coming from my computer when the VPN connections is down is no longer blocked based on ipleak.net. Im assuming there is something that changed in the new version of Comodo Firewall because I followed the same procedure as I had in the past. This blog post: https://www.bestvpn.com/blog/10218/build-your-own-vpn-kill-switch-in-windows-comodo/ also mentioned problems regarding their implementation of preventing leaks upon using the new version of Comodo Firewall, so I don't believe I am following the tutorial provided by AirVPN incorrectly. If anyone else could test AirVPNs initial tutorial with the newest version of Comodo Firewall it would be appreciated just so I know it's not me that is doing something wrong. If that is the case I can take screenshots of what I've done to try to fix my issue. As of now I have been using the Network Lock feature in the GUI and it seems to be working fine which I will stick to if I can't get Comodo to work. Thanks.

Hey guys, Can anybody help or explain why i'm getting DNS leaks even with Network Lock enabled? It's intermittent but using ipleak.net i can see it is occurring. Not sure what information i can provide to help anyone answering. I'm currently using a wired connection and running Windows 7(64bit). Any help would be greatly appreciated.

Hello! The idea of bringing this up is a result of many questions lately, that some devices or clients override OS settings and query their own DNS servers without the users permission. I would like to suggest a small enhancement, which will potentially prevent all user mistakes in the future, and will allow an even better VPN experience with less configuration. The idea is to have 2 additional options in the config generator section of the Client Area, where the user would be able to "opt-in" in case he wants the feature. One is something like "Force all applications use Air's VPN server", in which case you will have to add something like this: iptables -t nat -A PREROUTING -s 10.4.12.34 -p udp --dport 53 -j DNAT --to 10.4.0.1 iptables -t nat -A PREROUTING -s 10.4.12.34 -p tcp --dport 53 -j DNAT --to 10.4.0.1 The internal IP of the client is known to you, here is just examples of how I assume it should look on the server side. The second option in the Client Area, can be called something like "Prevent all potential DNS leaks, I will configure Air's DNS manually" Then, a rule like this can come in place: iptables -A OUTPUT -p udp -s 10.4.12.34 -d 10.0.0.0/8 --dport 53 -j ACCEPT iptables -A OUTPUT -p tcp -s 10.4.12.34 -d 10.0.0.0/8 --dport 53 -j ACCEPT iptables -A OUTPUT -p udp -s 10.4.12.34 --dport 53 -j DROP iptables -A OUTPUT -p tcp -s 10.4.12.34 --dport 53 -j DROP All the examples are made up, I am sure that a more elegant way of achieving this can take place, such as a special subnet for all users of each group. Today these methods are used in corporate VPNs mainly to enforce whitelisting/blacklisting of URLs, but I don't see a reason why we can't do the same here. Please share your comments zhang888

I tried the guide to plugging leaks from the "how to" section. It has taken a long time to get the various components to compile on Fedora. Now I ran the s/w I can't access the outside world, except for the local subnetwork. Here is the output of iptagles -L -v. Can someone spot the mistake? To test, I tried adding 8.8.8.8 (a DNS) to try to ping it. That doesn't work. Neither can I ping my router which is on 192.168.1.1. My NAS is 192.168.1.111. I can't ping that either. The s/w is running on Fedora 20 in a virtual box. This has IP 192.168.88.136 (static). The computer it is running on has IP 192.168.88.1 (through VMWare). I can ping 192.168.88.1 OK. Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo any anywhere anywhere 0 0 DROP tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW 0 0 ACCEPT all -- any any 192.168.1.111 192.168.88.136 0 0 ACCEPT all -- any any 8.8.8.8 192.168.88.136 0 0 ACCEPT all -- any any 192.168.88.1 192.168.88.136 0 0 ACCEPT all -- any any 192.168.3.1 192.168.88.136 0 0 ACCEPT all -- tun+ any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT all -- wlan+ any anywhere anywhere match-set airvpn src 0 0 ACCEPT all -- tun+ any anywhere anywhere match-set airvpn src Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- wlan+ tun+ anywhere anywhere 0 0 ACCEPT all -- tun+ wlan+ anywhere anywhere Chain OUTPUT (policy ACCEPT 4 packets, 232 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- any lo anywhere anywhere 0 0 ACCEPT all -- any any 192.168.88.136 192.168.1.111 0 0 ACCEPT all -- any any 192.168.88.136 8.8.8.8 0 0 ACCEPT all -- any any 192.168.88.136 192.168.88.1 0 0 ACCEPT all -- any any 192.168.88.136 192.168.3.1 0 0 ACCEPT all -- any any 192.168.1.0/24 192.168.88.0/24 0 0 ACCEPT all -- any tun+ anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT all -- any wlan+ anywhere anywhere match-set airvpn dst 0 0 ACCEPT all -- any tun+ anywhere anywhere match-set airvpn dst

https://www.dnsleaktest.com/results.php?r1=aoJZmh0Lb52YQwPEtMdu&r2=ACBXESVXCwyq5NSdDe49&r3=WTPJjU2vymw0oJ57eSUg Your DNS test resultsThis page shows the DNS servers that your computer is using to resolve DNS names. The owners of the servers listed below have the ability to log the names of all websites you connect to. WARNING: If you are connected to a VPN service and ANY of the servers listed below are not provided by the VPN service then your DNS may be leaking. (You should be able to recognise them based on the hostname, ISP and location). This is not an issue if you trust the owners of these servers with your private data. We detected the 4 DNS servers listed below. IP: 108.59.8.182 Hostname: hosted-by.leaseweb.com ISP: Leaseweb USA Country: Anonymous Proxy IP: 167.206.245.141 Hostname: dnsqsrc9.srv.prnynj.cv.net ISP: Cablevision Systems Corp. Country: United States IP: 167.206.195.251 Hostname: dnsqsrcpub12.srv.prnynj.cv.net ISP: Cablevision Systems Corp. Country: United States IP: 167.206.195.250 Hostname: dnsqsrcpub11.srv.prnynj.cv.net ISP: Cablevision Systems Corp. Country: United States how can i fix this??? only a few days new to this

On the page https://airvpn.org/topic/9139-prevent-leaks-with-linux-iptables/ there is a guide to setting up rules for iptables to prevent any leaks if the VPN were to disconnect. There are some brief comments accompanying the commands, which is great, but I was wondering if anyone could offer a more in-depth explanation for those of us not familiar with iptables? I've been trying to decode everything through 'man iptables', but it's a little difficult. For example, how do I know that the rules don't open up access to my machine or network through the tunnel? Thanks to anyone who can help!

help !! i've set up pfsense to work with airvpn. my ip address shows as the desired location and it makes me think everything is set up correctly. but . . . when i do a dns test it shows my true ip address from the internet company. also, when i log on to this web site it indicates "not connected" and shows the same ip address. i have tried various combinations for the dns settings of general setup. for the dns server i have 10.0.5.1 and 10.0.4.1. i've tried various combinations of the "allow dns server list" box and the "do not use the dns forwarder" box. what am i missing? what settings do i need to mask my ip address with no dns leaks??? this noob appreciates any assistance.

Hello, this is a guide to prevent ANY leak on Windows 7/8 with Windows Firewall published by Omniferum. It is particularly simple to follow and well written, and it provides also a very comfortable "VPN flipper". Thank you Omniferum! Warning: the setup works on Windows 7 and Windows 8 with the default Windows Firewall. It has NOT been tested on any other Windows version. It will NOT work on Windows XP (whose firewall is completely different and very limited, Windows XP users might like to use Comodo Firewall). It is NOT suitable if you have any other firewall running on your system (remember, you must never run two firewalls simultaneously). Important: the VPN flipper script will NOT work if your Windows is not in English language, because the system Firewall rules names change (incredible but true!) according to the language (thanks to Esamu for the information). UPDATE 14-May-14: issue fixed. Original thread updated on May the 14th, 2014: https://airvpn.org/topic/9609-blocking-non-vpn-traffic-with-windows-firewall Kind regards

Comment from AirVPN Staff: this guide has been written by NaDre. It is rich, well detailed, explanatory and also very useful for related arguments. It has been tested as fully working by a member of the staff on a Windows 7 64 bit system. If you don't need the anonymity layer for all of your traffic, traffic splitting is for you. IGNORE this guide and do NOT proceed if you wish the usual anonymity layer that protects all of your system Internet traffic. Thank you Nadre! Original thread: https://airvpn.org/topic/9491-guide-to-setting-up-vpn-just-for-torrenting-on-windows/ This guide may still have typos. Parts may not be very clear. More explanation may be needed in some places. If you have feed back, please just post in the original thread. ============================================================== Table of Contents Guide to Setting Up VPN Just for Torrenting on Windows - Part 1 Purpose and Goals IP Interfaces and Routing Table Installing OpenVPN IP Interfaces Before Install Routing Table Before Install IP Interfaces with VPN Down Routing Table with VPN Down Configuring OpenVPN to Access Servers IP Interfaces with VPN Up Routing Table with VPN Up Comparison of Routing Table with VPN Up Versus Down Setting Up Port Forwarding A Very Active Copyright Free Torrent to Test With Checking That the VPN Is Working Guide to Setting Up VPN Just for Torrenting on Windows - Part 2 Routing Table Functionality Advanced Set Up for Windows XP Set Up for Windows XP Firewall Routing Table Change to Block Outgoing Native Traffic Advanced Set Up for Windows Vista and Windows 7 Set Up for Windows Firewall with Advanced Security Rules for Incoming Connections Rules for Outgoing Connections Specifying the Properties for a Firewall Rule Set Up for Torrent Clients Setting IP Interface for uTorrent Setting IP Interface for Vuze Routing Table Changes to Restore Native Gateway ============================================================== Guide to Setting Up VPN Just for Torrenting on Windows - Part 1 Purpose and Goals This guide is about setting up a VPN service on Windows using AirVPN. The goal here is to use the VPN only for torrent clients and the normal gateway for all other activities. (Staff note: if you do not understand this sentence STOP HERE, you probably don't need this guide) This way my normal activities are not impacted (Staff note: it's important that you understand that with this guide the "normal activities" will NOT be tunneled and therefore NOT anonymized in any way!) by: reduced effective bandwidthdetectable delays in response while browsing due to increased latency ("latency" is the time it takes for a packet to transit)security panics by sites I use that worry about security when my apparent location in the world changesI am using Windows 7. But this guide also discusses XP and Vista. Details are provided below. Here is a summary of what I do on Windows 7. I use the VPN only for my torrent clients. To achieve this, I override the "0.0.0.0/128.0.0.0" and "128.0.0.0/128.0.0.0" routing table entries set up by the OpenVPN client with "0.0.0.0/192.0.0.0", "64.0.0.0/192.0.0.0", "128.0.0.0/192.0.0.0" and "192.0.0.0/192.0.0.0" entries to use my normal gateway for most activities. I have two .bat files that allow me to quickly insert or delete these in order to use the VPN for web browsing when I want to. I also then need to tell my torrent clients (uTorrent and Vuze are discussed in this guide) to use the VPN interface, since it will now not be used by default. For Vuze one can specify the interface. But for uTorrent one has to specify the IP address. So long as I continue to use the same AirVPN server, since my DHCP license is for a year I do not need to change the uTorrent configurations. If I wish to change the AirVPN server, I have to change IP address uTorrent uses. This is not a lot of work. At the time of writing, AirVPN does not allow one to have a fixed local IP address for the VPN interface, otherwise this could be avoided. I also configure Windows firewall to block all traffic from torrent clients using the default gateway. So if the VPN goes down, even if Windows decides to ignore the request to bind to a specific interface/IP and bind to my default gateway (apparently Windows may do this?), nothing leaks out using my own IP address. Although I am using Windows 7, I have tried setting up a similar scheme to mine using Windows XP and Windows Vista, in the hope of making this guide more useful. I suspect many people are still using XP and Vista. I succeeded in this goal for Vista. However for XP, I was not able to achieve the goal of using the native interface for normal activities while using the VPN for the torrent clients. I describe the results below. For examples, I use the earliest version of Windows possible, since the examples are often simpler that way, and you should be able to adapt the information to a later release easily. I try to make minimal assumptions about the readers background, in the hope that this will be useful to non-technical readers. To this end, I try to explain the role of IP interfaces and the routing table in networking and how to obtain important information about these. All screenshots can be enlarged by clicking on them individually. IP Interfaces and Routing Table In a couple of places in what follows I use two commands at the the Windows "Command Prompt" to reveal some useful things about what setting up a VPN does in terms Windows IP interfaces and the Windows routing table. The commands are "ipconfig/all" and "route print". Installing OpenVPN Get the "community" version of the unaltered OpenVPN client: http://openvpn.net/index.php/open-source/downloads.html If you have a the 64-bit version of Windows then get the 64-bit version of OpenVPN - "openvpn-install-?-x86_64.exe". But if you do not have 64-bit Windows use the 32-bit version - "openvpn-install-?-i686.exe". Before you install it, use the "ipconfig/all" and "route print" commands at a Windows command prompt. You will get something similar to this: IP Interfaces Before Install C:\Documents and Settings\user>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : xp Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter Physical Address. . . . . . . . . : 00-0C-29-A2-B9-61 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.69 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.254 DHCP Server . . . . . . . . . . . : 192.168.1.254 DNS Servers . . . . . . . . . . . : 192.168.1.254 75.153.176.1 Lease Obtained. . . . . . . . . . : Wednesday, March 06, 2013 2:05:50 PM Lease Expires . . . . . . . . . . : Thursday, March 07, 2013 2:05:50 PMRouting Table Before Install C:\Documents and Settings\user>route print =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...00 0c 29 a2 b9 61 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.69 10 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.69 192.168.1.69 10 192.168.1.69 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.1.255 255.255.255.255 192.168.1.69 192.168.1.69 10 224.0.0.0 240.0.0.0 192.168.1.69 192.168.1.69 10 255.255.255.255 255.255.255.255 192.168.1.69 192.168.1.69 1 Default Gateway: 192.168.1.254 =========================================================================== Persistent Routes: NoneInstall it. You may get an "unsigned driver" warning message for the TAP driver that OpenVPN uses to create an IP interface in Windows (saying it could destabilize your system). For Windows XP it looks like this: Ignore the warning. It works fine on Windows XP (or Vista, Windows 7 or Windows 8). At this point, again use the "ipconfig/all" and "route print" commands at a Windows command prompt. You will get something similar to this: IP Interfaces with VPN Down C:\Documents and Settings\user>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : xp Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter Physical Address. . . . . . . . . : 00-0C-29-A2-B9-61 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.69 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.254 DHCP Server . . . . . . . . . . . : 192.168.1.254 DNS Servers . . . . . . . . . . . : 192.168.1.254 75.153.176.1 Lease Obtained. . . . . . . . . . : Wednesday, March 06, 2013 2:05:50 PM Lease Expires . . . . . . . . . . : Thursday, March 07, 2013 2:05:50 PM Ethernet adapter Local Area Connection 4: Media State . . . . . . . . . . . : Media disconnected Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-42-5E-D2-9ERouting Table with VPN Down C:\Documents and Settings\user>route print =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...00 0c 29 a2 b9 61 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport 0x3 ...00 ff 42 5e d2 9e ...... TAP-Windows Adapter V9 - Packet Scheduler Miniport =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.69 10 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.69 192.168.1.69 10 192.168.1.69 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.1.255 255.255.255.255 192.168.1.69 192.168.1.69 10 224.0.0.0 240.0.0.0 192.168.1.69 192.168.1.69 10 255.255.255.255 255.255.255.255 192.168.1.69 192.168.1.69 1 255.255.255.255 255.255.255.255 192.168.1.69 3 1 Default Gateway: 192.168.1.254 =========================================================================== Persistent Routes: NoneCompare these results to what we had before the install. In the sample above, a new IP interface called "Local Area Connection 4" has been created by the install. Configuring OpenVPN to Access Servers Then to get the VPN set up initially, at AirVPN go to "Client Area/Config Generator". The page says "OpenVPN Configuration Generator ". Press the "Invert" button to select all of the servers (why not?). Then select "UDP" under "Protocol" and then "443" under "Port". Agree to the terms of service and press the "Generate" button. This will have created a file called "air.zip". Save it somewhere. Unzip this into a folder. Let's say it is called "AirVPN". It will contain files like this: C:\Program Files\OpenVPN\config\AirVPN>dir Volume in drive C is Acer Volume Serial Number is 00B1-714F Directory of C:\Program Files\OpenVPN\config\AirVPN 20/02/2013 02:08 PM <DIR> . 20/02/2013 02:08 PM <DIR> .. 20/02/2013 09:07 PM 8,944 AirVPN CH Virginis - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN DE Aquilae - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN DE Tauri - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN DE Velorum - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN GB Bootis - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN GB Carinae - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN GB Cassiopeia - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN IT Crucis - UDP 443.ovpn 20/02/2013 09:07 PM 8,945 AirVPN LU Herculis - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN NL Castor - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN NL Leonis - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN NL Leporis - UDP 443.ovpn 20/02/2013 09:07 PM 8,945 AirVPN NL Lyncis - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN NL Lyra - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN NL Ophiuchi - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN NL Orionis - UDP 443.ovpn 20/02/2013 09:07 PM 8,946 AirVPN RO Phoenicis - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN SE Cygni - UDP 443.ovpn 20/02/2013 09:07 PM 8,945 AirVPN SE Serpentis - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN SG Columbae - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN SG Puppis - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN SG Sagittarii - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN US Andromedae - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN US Librae - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN US Octantis - UDP 443.ovpn 20/02/2013 09:07 PM 8,945 AirVPN US Pavonis - UDP 443.ovpn 20/02/2013 09:07 PM 8,944 AirVPN US Persei - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN US Sirius - UDP 443.ovpn 20/02/2013 09:07 PM 8,943 AirVPN US Vega - UDP 443.ovpn 29 File(s) 259,370 bytes 2 Dir(s) 244,540,530,688 bytes freeMove the "AirVPN" folder to "C:\Program Files\OpenVPN\config". You will be prompted for administrator privilege. The OpenVPN install will have created a desktop icon for the OpenVPN GUI. Stop your torrent clients. Start up the OpenVPN GUI. On Vista or Windows 7 it will require administrator privilege. The following error messages may be symptom if it is not running privileged: Either always right-mouse click and "Run as administrator", or alter the desktop icon for the OpenVPN GUI to always run as administrator: The icon for the OpenVPN GUI will be in the system tray. Right-mouse click on it and select a server. On Windows XP the menu looks like this: There is a page at AirVPN that gives info on how loaded each server is which cane be helpful when selecting a server to use. When the window showing the log closes and the message saying the VPN is up comes up. Now once more use the "ipconfig/all" and "route print" commands at a Windows command prompt. You will get something similar to this: IP Interfaces with VPN Up C:\Documents and Settings\user>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : xp Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter Physical Address. . . . . . . . . : 00-0C-29-A2-B9-61 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.69 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.254 DHCP Server . . . . . . . . . . . : 192.168.1.254 DNS Servers . . . . . . . . . . . : 192.168.1.254 75.153.176.1 Lease Obtained. . . . . . . . . . : Wednesday, March 06, 2013 2:05:50 PM Lease Expires . . . . . . . . . . : Thursday, March 07, 2013 2:05:50 PM Ethernet adapter Local Area Connection 4: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-42-5E-D2-9E Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 10.4.50.142 Subnet Mask . . . . . . . . . . . : 255.255.255.252 Default Gateway . . . . . . . . . : 10.4.50.141 DHCP Server . . . . . . . . . . . : 10.4.50.141 DNS Servers . . . . . . . . . . . : 10.4.0.1 Lease Obtained. . . . . . . . . . : Wednesday, March 06, 2013 2:31:50 PM Lease Expires . . . . . . . . . . : Thursday, March 06, 2014 2:31:50 PMRouting Table with VPN Up C:\Documents and Settings\user>route print =========================================================================== Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...00 0c 29 a2 b9 61 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport 0x3 ...00 ff 42 5e d2 9e ...... TAP-Windows Adapter V9 - Packet Scheduler Miniport =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 128.0.0.0 10.4.50.141 10.4.50.142 1 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.69 10 10.4.0.1 255.255.255.255 10.4.50.141 10.4.50.142 1 10.4.50.140 255.255.255.252 10.4.50.142 10.4.50.142 30 10.4.50.142 255.255.255.255 127.0.0.1 127.0.0.1 30 10.255.255.255 255.255.255.255 10.4.50.142 10.4.50.142 30 95.211.169.3 255.255.255.255 192.168.1.254 192.168.1.69 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 128.0.0.0 128.0.0.0 10.4.50.141 10.4.50.142 1 192.168.1.0 255.255.255.0 192.168.1.69 192.168.1.69 10 192.168.1.69 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.1.255 255.255.255.255 192.168.1.69 192.168.1.69 10 224.0.0.0 240.0.0.0 10.4.50.142 10.4.50.142 30 224.0.0.0 240.0.0.0 192.168.1.69 192.168.1.69 10 255.255.255.255 255.255.255.255 10.4.50.142 10.4.50.142 1 255.255.255.255 255.255.255.255 192.168.1.69 192.168.1.69 1 Default Gateway: 10.4.50.141 =========================================================================== Persistent Routes: NoneThe "Local Area Connection 4" interface has been configured with an IP address and other configuration information added to it. Also, the routing table has several new entries added to it involving the "Local Area Connection 4" interface. We will examine the details of these differences and comment on the information content of these listings in what follows. You can use a "diff' program such as Winmerge to make the additions and changes to the routing table easier to pick out: Comparison of Routing Table with VPN Up Versus Down Now use your browser to go to: http://whatismyipaddress.com/ Where are you in the world? Until we get port forwarding working, there is no point in running your torrent client with the VPN. Although there would be no harm in trying it for a minute. Stop your torrent clients again before you shut down the VPN. Setting Up Port Forwarding At AirVPN, go to "Client Area/Forwarded ports". The page title is "Your forwarded ports" The ports you already have are shown first with a "Remove" button. At the end there is an extra spot with an "Add" button. Click "Add" and it will generate a random number and forward that port to you. After you click the next page will say "Port ????? added" at the top. Now you need to tell your torrent client to listen on this port. Here you should first understand about UPnP: https://en.wikipedia.org/wiki/Universal_Plug_and_Play And also NAT-PMP: http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol UPnP support in the router allows a program running on your PC to tell your router to set up port forwarding. Most routers now a days support this. NAT-PMP is much less widely implemented. It seems that because of this many people do not realize that incoming connections are being forwarded to their torrent client. When using a VPN, you should turn off UPnP and NAT-PMP in your torrent client. For uTorrent, do "Options/Preferences", then select "Connection" and paste in (or type) the port number AirVPN generated for you. Then click "OK". For Vuze do "Tools/Options", then "Connections" and paste in (or type) the port number AirVPN generated for you. The click "Save". Also for Vuze, to turn off UPnP and NAT-PMP use "Tools/Options/Plugins/UPnP" and "Tools/Options/Plugins/UPnP/NAT-PMP": Now go back to the AirVPN port forwarding page and click the "Check" button for the port. When this competes the "Status" icon should turn green. A Very Active Copyright Free Torrent to Test With If you want a very active torrent to test with that has no copyright issues, use the Ubuntu Desktop torrent: http://www.ubuntu.com/download/desktop/alternative-downloads Checking That the VPN Is Working To see whether you are receiving incoming connections: uTorrent: Use "Options/Show Status Bar" In the Status Bar area (at the bottom) select the "Peers" tab. Hopefully you have the "Flags" column? If not right mouse-click on the column title area and enable it. What you want to see is a few peers with "I" as one of the flags. This means the peer connected to you. The meaning of each flags is available in "Help/uTorrent Help". Vuze: If the icon in front of the torrent is green, then you have received incoming connections. To pursue this further, right mouse-click on a torrent and select "Show Details". Then select the "Peers" tab. Hopefully you have the "T" column? If not right mouse-click on the column title area and enable it. The peers that have "R" in the "T" column came to you as incoming connections. Process Explorer But there is a more general and powerful way to check what is happening with a torrent clients IP connections. There is a useful tool that Microsoft provides - "Process Explorer": http://technet.microsoft.com/en-ca/sysinternals/bb896653.aspx With it you can see all of the network connections a program is making. Once it is installed, start it and in the process tree that gets shown locate "uTorrent.exe" or "Azureus.exe" under "explorer.exe". Right-mouse click on it and select "Properties..."`. Then select the "TCP/IP" tab. In that uncheck the "Resolve addresses" check box. If you see connections on the port that you set up as the incoming port, that is another indication that you are receiving incoming connections. Using Process Explorer you will also be able to see if any connections are being made on the native interface rather than the VPN interface (as they should). This is an example of what you can see with Process Explorer: In the example above, Vuze is listening for connections on port 63676, so the "ESTABLISHED" connections to that port are from incoming connections. It can be helpful to sort the items in this display in various orders by clicking on the column headers. The possible states are described here: http://support.microsoft.com/kb/137984 This is a summary taken from the link above: SYN_SEND - Indicates active open. SYN_RECEIVED - Server just received SYN from the client. ESTABLISHED - Client received server's SYN and session is established. LISTEN - Server is ready to accept connection. FIN_WAIT_1 - Indicates active close. TIMED_WAIT - Client enters this state after active close. CLOSE_WAIT - Indicates passive close. Server just received first FIN from a client. FIN_WAIT_2 - Client just received acknowledgment of its first FIN from the server. LAST_ACK - Server is in this state when it sends its own FIN. CLOSED - Server received ACK from client and connection is closed.Guide to Setting Up VPN Just for Torrenting on Windows - Part 2 Routing Table Functionality In what follows, manipulations of the routing table will be used to achieve certain goals. Some understanding of the routing table will be needed in order for the reader to complete these. You may also want to see the Wikipedia page about the routing table: http://en.wikipedia.org/wiki/Routing_table Please refer to the listings generated by "route print" above. When a program does an IP "bind" function without specifying a particular IP interface or IP address to bind to, the routing table is used to determine what IP interface to send a packet on, based on the destination. The packet destination is compared against the two values "Network Destination" and "Netmask". These two values together define a "subnet" or "subnetwork". For an explanation of a subnetwork and subnet notations see Wikipedia: http://en.wikipedia.org/wiki/Subnetwork The values shown as 4 numbers separated by periods are 32 bit strings, divided up into 4 8 bit chunks, so that each chunk is a value from 0 to 255. But think of these as 32 bit strings. "Netmask" will be all ones on the left and all zeros to the right of that. What matters with it is just how many 1-s are on the left. If the "Netmask" has only 4 1-s on the left, then only the left-most 4 bits of the packet destination and "Network Destination" are compared for a match. A packet destination may have several routing table entries that match by this criteria. The one that will be used is the one for which the "Netmask" had the most 1-s. If that does not resolve it, the lowest "Metric" is then checked. The entry with the "0.0.0.0." Netmask is called the "default" gateway: ... Network Destination Netmask Gateway Interface Metric ... 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.69 10 ... Default Gateway: 192.168.1.254 ...This "0.0.0.0" entry will match anything, since no bits have to be compared. So if no more specific entry is found that is where a packet will go. Now look at the screen shot above labelled "Comparison of Routing Table with VPN Up Versus Down". The extra lines when the VPN is up were added by the OpenVPN client. Note these two extra lines in particular: ... Network Destination Netmask Gateway Interface Metric ... 0.0.0.0 128.0.0.0 10.4.50.141 10.4.50.142 1 ... 128.0.0.0 128.0.0.0 10.4.50.141 10.4.50.142 1 ... Default Gateway: 10.4.50.141 ...These entries with "128.0.0.0" prevent the "0.0.0.0" from ever being used, because one of these will match any address, and they are more specific (one 1 bit on the left of the Netmask rather than no bits at all). This makes the VPN gateway (10.4.50.141) the new "default gateway". The other additional entries serve various purposes which are not relevant to our discussion below. Advanced Set Up for Windows XP As I explained above, I was not able to find a way under XP to use the native interface for normal activities while using the VPN for the torrent clients. I could not get the torrent clients to use the VPN interface unless it was the default gateway in the routing table. It appears that you have to use the VPN for everything or nothing. However it is possible to use a combination of the firewall and the routing table to ensure that no P2P traffic uses the native interface when the VPN is not running. Set Up for Windows XP Firewall First I will discuss the firewall. It does not seem to be possible to fully block all torrent traffic from the native interface using just the limited firewall that came with XP. Although you can block incoming connections to some extent, you cannot block outgoing connections at all. And registering your IP address against torrent hashes on a tracker or by DHT is already bad enough for IP address trolls to see you. And if they register themselves on a tracker as having a torrent you want, you may connect to them (even worse). You could also be given their IP address as a source by peer exchange even if you strip things to DHT only. With some other firewall that works on XP you may still be able to do this. There may be information on the AirVPN forum. If you have a router, you may not have had Windows firewall enabled, relying on your router to provide the firewall. However you should have Windows firewall enabled at least for the VPN interface, with an exception for your torrent client. The following screen shots illustrate how to do this: This will allow incoming connections for torrent clients from the native interface too. But you should be able to configure your router so that no incoming connections are forwarded from the internet to your PC. You will have to poke around in its GUI/HTTP interface. Besides turning off any explicit port forwarding in your router, you need to consider UPnP: https://en.wikipedia.org/wiki/Universal_Plug_and_Play UPnP support in the router allows a program running on your PC to tell your router to set up port forwarding. Most routers now a days support this. It seems that because of this many people do not realize that incoming connections are being forwarded to their torrent client. The thing is, malicious programs can do this too! So you may want to go further and disable UPnP in your router. However you may be using some other program that needs it. With UPnP off (and no explicit port forwarding rules in the router), you can be sure that no incoming connections can come in by the native interface. If you do want to block incoming torrent connections only on the native interface, then do not enable the exceptions for the clients on the "Exceptions" tab as shown above, but instead go to "Advanced Settings" from the "Advanced" tab and provide exception rules only for the VPN interface, as shown below: Using this approach, you have to define the rules based on the ports rather than the programs, and you will need a TCP and a UDP rule for each port. Routing Table Change to Block Outgoing Native Traffic In order to ensure that outgoing traffic will not go out over the native interface, one can make a change to the routing table which will guarantee that no traffic of any sort (except the encrypted VPN traffic itself) will be able to find its way to the native interface. Refer to the section "Routing Table Functionality" above. If the VPN goes down, the "128.0.0.0" entries that override the default gateway will be removed by the OpenVPN client. If the "0.0.0.0" entry is removed, then there will be no default gateway and nothing will be able to find its way out to the internet. A variation of this approach is discussed here: http://cranthetrader.blogspot.ca/2011/10/dont-allow-non-vpn-traffic.html But it seems to me that the procedure described on that page is far more complicated than necessary. Once the VPN is running, you can just remove the "0.0.0.0" entry from the routing table using this command at a command prompt: route delete 0.0.0.0 192.168.1.254If you want to stop the VPN and use the native interface again, then after shutting down the VPN, restore the default gateway entry for the native interface using this command at a command prompt: route add 0.0.0.0 mask 0.0.0.0 192.168.1.254Note that "192.168.1.254" above must be replaced with the gateway for your native interface. If you lose track of this, it is part of the information displayed for interfaces by "ipconfig /all" (see the examples above). For convenience, you could create two ".bat" files each with one of these commands. I suggest that you place a "pause" command at the end so that the windows that opens to run the command does not disappear before you can see if it worked. Advanced Set Up for Windows Vista and Windows 7 The set up described below works on either Vista or Windows 7. I use Windows 7, but I have confirmed that it works on Vista using a virtual machine I have with Windows Vista on it. All of the samples below are taken from Windows Vista. There a couple of small differences in the GUI for "Windows Firewall with Advanced Security". I also encountered a problem getting the firewall blocking to work fully for Windows Vista. Getting the firewall to block uTorrent from using the native interface worked, but getting it to block Vuze has not worked! Blocking Vuze works fine on Windows 7. But there is a saving grace. Fortunately Vuze has an option that prevents it using the default interface if it is configured to use a specific interface. I use this on Windows 7 too, even though it does not appear to be necessary. Set Up for Windows Firewall with Advanced Security To set up the blocking of both incoming and outgoing connections in the way we need, you have to use "Windows Firewall with Advanced Security", which is separate from "Windows Firewall" in the Windows Start menu. You have to first get into "Administrative Tools". The following screen shot shows how to get into "Windows Firewall with Advanced Security": Once you are into ""Windows Firewall with Advanced Security"" you can configure rules for both incoming and outgoing connections at a level of detail much greater than you could for Windows XP. In order to do this we will need to determine an appropriate subnet definition for the native interface and the VPN interface. This can be obtained from examining output from the "ipconfig /all" and "route print" commands: C:\Users\user>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : virtual_Vista Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Local Area Connection 3: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-B8-2E-BD-7C DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::5d15:cf7:c242:3e80(Preferred) IPv4 Address. . . . . . . . . . . : 10.4.50.142(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.252 Lease Obtained. . . . . . . . . . : Wednesday, March 13, 2013 11:38:12 AM Lease Expires . . . . . . . . . . : Thursday, March 13, 2014 11:38:12 AM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 10.4.50.141 DHCPv6 IAID . . . . . . . . . . . : 234946488 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-79-1E-1D-00-0C-29-3D-07-02 DNS Servers . . . . . . . . . . . : 10.4.0.1 NetBIOS over Tcpip. . . . . . . . : Enabled Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection Physical Address. . . . . . . . . : 00-0C-29-E3-F7-8B DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::9c19:3be7:696c:e04(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.1.67(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Wednesday, March 13, 2013 11:32:09 AM Lease Expires . . . . . . . . . . : Thursday, March 14, 2013 11:32:09 AM Default Gateway . . . . . . . . . : 192.168.1.254 DHCP Server . . . . . . . . . . . : 192.168.1.254 DHCPv6 IAID . . . . . . . . . . . : 251661353 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-79-1E-1D-00-0C-29-3D-07-02 DNS Servers . . . . . . . . . . . : 192.168.1.254 75.153.176.1 NetBIOS over Tcpip. . . . . . . . : Enabled Tunnel adapter Local Area Connection* 6: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : isatap.{A8B29C02-92F2-4901-B6DB-0A2CD26E54D2} Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Tunnel adapter Local Area Connection* 7: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physical Address. . . . . . . . . : 02-00-54-55-4E-01 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2001:0:9d38:953c:349c:1efb:f5fb:cd71(Preferred) Link-local IPv6 Address . . . . . : fe80::349c:1efb:f5fb:cd71(Preferred) Default Gateway . . . . . . . . . : :: NetBIOS over Tcpip. . . . . . . . : Disabled Tunnel adapter Local Area Connection* 11: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : isatap.{B82EBD7C-FAAE-42FB-AAA5-4E849D98E35A} Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes C:\Users\user>route print =========================================================================== Interface List 14 ...00 ff b8 2e bd 7c ...... TAP-Windows Adapter V9 10 ...00 0c 29 e3 f7 8b ...... Intel(R) PRO/1000 MT Network Connection 1 ........................... Software Loopback Interface 1 13 ...00 00 00 00 00 00 00 e0 isatap.{A8B29C02-92F2-4901-B6DB-0A2CD26E54D2} 12 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface 15 ...00 00 00 00 00 00 00 e0 isatap.{B82EBD7C-FAAE-42FB-AAA5-4E849D98E35A} =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.67 10 0.0.0.0 128.0.0.0 10.4.50.141 10.4.50.142 30 10.4.0.1 255.255.255.255 10.4.50.141 10.4.50.142 30 10.4.50.140 255.255.255.252 On-link 10.4.50.142 286 10.4.50.142 255.255.255.255 On-link 10.4.50.142 286 10.4.50.143 255.255.255.255 On-link 10.4.50.142 286 95.211.169.3 255.255.255.255 192.168.1.254 192.168.1.67 10 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 128.0.0.0 128.0.0.0 10.4.50.141 10.4.50.142 30 192.168.1.0 255.255.255.0 On-link 192.168.1.67 266 192.168.1.67 255.255.255.255 On-link 192.168.1.67 266 192.168.1.255 255.255.255.255 On-link 192.168.1.67 266 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 10.4.50.142 286 224.0.0.0 240.0.0.0 On-link 192.168.1.67 266 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 10.4.50.142 286 255.255.255.255 255.255.255.255 On-link 192.168.1.67 266 =========================================================================== Persistent Routes: None IPv6 Route Table =========================================================================== Active Routes: If Metric Network Destination Gateway 12 18 ::/0 On-link 1 306 ::1/128 On-link 12 18 2001::/32 On-link 12 266 2001:0:9d38:953c:349c:1efb:f5fb:cd71/128 On-link 14 286 fe80::/64 On-link 10 266 fe80::/64 On-link 12 266 fe80::/64 On-link 12 266 fe80::349c:1efb:f5fb:cd71/128 On-link 14 286 fe80::5d15:cf7:c242:3e80/128 On-link 10 266 fe80::9c19:3be7:696c:e04/128 On-link 1 306 ff00::/8 On-link 12 266 ff00::/8 On-link 14 286 ff00::/8 On-link 10 266 ff00::/8 On-link =========================================================================== Persistent Routes: NoneExamining the "ipconfig /all" output we see that: * the VPN interface ("Local Area Connection 3") has IP address 10.4.50.142 and provides a path to the gateway 10.4.50.141 * the native interface (with IP address 192.168.1.67) provides a path to the gateway 192.168.1.254 Examining the "route print" output we see that: * the VPN interface (with IP address 10.4.50.142) provides a path to the gateway 10.4.50.141 * the native interface ("Local Area Connection") has IP address 192.168.1.67 and provides a path to the gateway 192.168.1.254 (this can also be gleaned from the "ipconfig /all" output) For the firewall rules, we need to use the CIDR subnet ("prefix/length") notation: http://en.wikipedia.org/wiki/CIDR_notation#CIDR_notation We will go with "10.4.0.0/16" as a subnet definition containing the VPN address and with "192.168.0.0/16" as a subnet definition containing our native interface. We need these two subnet definitions to not overlap, and to be big enough that they will not need to change if the address given to us by the VPN DHCP server or our router DHCP server changes. A prefix length of 16 should be plenty for this. I will explain the rationale for the firewall rules I set up after some screen shots that give the jist of how to use the firewall set up GUI. The following screen shots show the summary window: Rules for Incoming Connections Rules for Outgoing Connections The following screen shots illustrate how to set the properties of firewall rules: Specifying the Properties for a Firewall Rule Installing (or perhaps running the first time) uTorrent will have created Inbound rules named "Torrent (TCP-In)" and "Torrent (UDP-In)". Installing (or perhaps running the first time) Vuze will have create a rule named "Azureus / Vuze" for each of TCP and UDP. We want to change these so that they allow incoming connections only from the VPN. In the screen shot above for Incoming connections you will see that the "Local IP address" property has been set to "10.4.0.0/16". Although I do not recall changing anything else, make whatever other changes you need to ensure that the rules you create are as in the example above. You could if you prefer disable the original rules and create new ones. The uTorrent and Vuze installations do not create any Outbound rules. So I have created a rule for uTorrent ("_uTorrent") and for Vuze ("_Vuze"). We want these rules to block outgoing traffic over the native interface from our torrent clients. We need these rules to be "blocking" rules, applying to all profiles and all protocols, and with that the "Local IP address" property has been set to "192.168.0.0/16". Make whatever other changes you need to ensure that the rules you create are as in the example above. Set Up for Torrent Clients Next we set up the torrent clients to use only the VPN interface. This will give additional assurance that torrent traffic does not go out over the native interface, and also allow us to make the changes to the routing table that will cause the VPN interface to be used only for torrent traffic. The following screen shot illustrates setting the IP interface for uTorrent: Setting IP Interface for uTorrent From the menu in uTorrent select "Options/Preferences" and then select "Advanced". You need to set the "net.bind.ip" and "net.outgoing.ip" to the IP address of the VPN interface. Unfortunately for uTorrent one has to specify the IP address, unlike Vuze (see below). So long as I continue to use the same AiirVPN server, since my DHCP license is for a year, I do not need to change the uTorrent configuration. If I wish to change the AirVPN server, I have to change IP address uTorrent uses. At the time of writing, AirVPN does not allow one to have a fixed local IP address for the VPN interface, otherwise this could be avoided. The following screen shot illustrates setting the IP interface for Vuze: Setting IP Interface for Vuze From the menu in Vuze select "Options" and then select "Connection/Advanced Network Settings". First ensure that the check box labelled "Enforce IP bindings even when interfaces are not available, ..." (at the bottom of the page) is enabled. Next fill in the text box labelled "Bind to local IP address or interface". You could fill in the actual IP address of the VPN interface as we did for uTorrent. But it is better to scan the list of interfaces further down the page for the one for the VPN interface. In the sample screen shot you will see that the VPN address "10.4.50.142" goes with the interface "eth5[0]". So I have copied and pasted that into the text box instead. By using the interface name rather than the IP address, I avoid having to change the Vuze set up if the address of my VPN interface changes (when I switch OpenVPN servers for example). Routing Table Changes to Restore Native Gateway The final step in this set up is to add some additional routing table entries to restore the native gateway as the default gateway. Recall (see the discussion above) that the OpenVPN client added two routing table entries with a subnet prefix length of 1 bit (net mask 128.0.0.0) in order to override the original routing table entry that made the native interface the default gateway. That original routing table entry (just 1 entry) had a subnet prefix length of 0 bits (net mask 0.0.0.0). Because the subnet prefix length of the routing table entries the VPN client made is longer, and the two entries together cover the full IP address space, these two new entries had the effect of overriding the original default gateway. One might think then that we just need to delete the two entries with net mask "128.0.0.0". And indeed, if we were not using Windows, this would probably work! But I have found that with these entries removed, Windows does not allow the torrent clients to bind to the VPN interface, which they were configured above to use. But there is another possibility, which I have found does work. We will do what the VPN client did - add more routing table entries. Our entries will have a subnet prefix length of 2 bits (new mask 192.0.0.0). In order cover the full IP address space we need 4 entries (see the pattern?). To this end, create two ".bat" files. Files ending in .bat are expected by Windows to contain "scripts" that run the same commands that you can run at the Windows Command Prompt. Create two files as follows - "VPN_gateway_suspend.bat" containing: @set GATEWAY=192.168.1.254 route add 0.0.0.0 mask 192.0.0.0 %GATEWAY% route add 64.0.0.0 mask 192.0.0.0 %GATEWAY% route add 128.0.0.0 mask 192.0.0.0 %GATEWAY% route add 192.0.0.0 mask 192.0.0.0 %GATEWAY% @pause "VPN_gateway_restore.bat" containing: @set GATEWAY=192.168.1.254 route delete 0.0.0.0 mask 192.0.0.0 %GATEWAY% route delete 64.0.0.0 mask 192.0.0.0 %GATEWAY% route delete 128.0.0.0 mask 192.0.0.0 %GATEWAY% route delete 192.0.0.0 mask 192.0.0.0 %GATEWAY% @pause I put my files into the folder "C:\bat\VPN". The route commands to add and delete entries require administrator privilege. So to run the .bat files directly you have to right mouse-click on them and select "Run as administrator". As a convenience, I create short cuts to these .bat files and set "Run as administrator" in their "Advanced Properties": To be sure these scripts and short cuts are working for you, use the "route print" command in a Windows Command Prompt window.

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

Please see the following guide (courtesy of jessez, thank you very much jessez!): https://airvpn.org/topic/1713-win-mac-bsd-block-traffic-when-vpn-disconnects/page-3?do=findComment&comment=2756

In order to prevent leaks on *BSD and Mac OS X systems with pf, please see this guide by jessez: https://airvpn.org/topic/1713-win-mac-bsd-block-traffic-when-vpn-disconnects/page-2?do=findComment&comment=2532 Thank you very much jessez! Kind regards

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

Hello! Previous thread on Windows and Comodo to prevent DNS leaks and leaks in case of unexpected VPN disconnection have become very big and detailed. We invite you to consult those threads for details and support, while we publish this message as a quick, clarifying overview of the essential steps. Please note that if you don't use Windows you don't need to read this post. If you use Windows and a firewall other than Comodo, you can anyway take these rules as an example and adapt them to your firewall. This is a minimal set of instructions to prevent any leak in case of unexpected VPN disconnection and prevent, in any case, DNS leaks, on Windows system with Comodo firewall. Comodo firewall is currently the only firewall we recommend for Windows. The free version is just fine for our purposes. Never rename the rules: in case you need support, we need to see what the rules really state. 1) If you're not familiar with a firewall, read Comodo Firewall manual or guides. In particular, please see the following: https://help.comodo.com/topic-72-1-451-4773-global-rules.html https://help.comodo.com/topic-72-1-451-4884-Network-Zones.html 2) Install Comodo Personal Firewall free version available here: https://personalfirewall.comodo.com/ 3) Set the Firewall Security Level to "Custom Policy" 4) Determine or create the Network Zone of your TAP-Win32 network adapter (from now on "AirVPN"). A safe way to define it: IP Range [10.1.0.0 - 10.255.255.255] if you need OpenVPN over SSH/SSL and other alternative connection modes, see also https://airvpn.org/specs 5) Determine the entry-IP addresses of the AirVPN server(s) you wish to connect to: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses 6) Define a "Global Rule" which blocks everything: Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any The logging is important for troubleshooting if necessary. 7) Put the above Global Rule in the top position. This will block completely your connectivity and let you add a whitelist of Allow global rules put BEFORE this total block global rule. All the "Allow" rules that you want to be evaluated shall be put BEFORE (i.e. higher than) the above block rule. 8) Define a"Global" rule which allows in/out communications of your TAP-Win32 adapter ("AirVPN") both In and Out: Allow IP In/Out From In [AirVPN] To MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To In [AirVPN] Where Protocol Is Any 9) Do the same for your loopback zone (IP range 127.0.0.1 - 127.255.255.254) Allow IP In/Out From In [Loopback Zone] to MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To In [Loopback Zone] Where Protocol Is Any 10) Do the same for any entry-IP address of the VPN servers you wish to connect to. For example for Leporis: Allow TCP or UDP In/Out From IP 95.211.191.33 To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To IP 95.211.191.33 Where Source Port Is Any And Destination Port Is Any For your comfort, you might define a Network Zone (for example [Air servers entry IPs]) containing only the entry-IP addresses of our servers and then set two rules like Allow TCP or UDP In/Out From In [Air servers entry IPs] To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To In [Air servers entry IPs] Where Source Port Is Any And Destination Port Is Any In this way, you will only need to add a single IPv4 address to that Network Zone in order to connect to a new server, instead of defining two additional rules for each server, which may be annoying if you switch between a lot of servers. 11) Add similar rules to allow communications of your device with your router (and within your home/office network, if you wish so). For example, if your network is [192.168.0.0 / 255.255.0.0] define a network zone with IP Range [192.168.0.0 - 192.168.255.255] (let's call it "Home Network") and set the following rules: Allow TCP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Not 53 Allow ICMP In/Out From In [Home Network] To In [Home Network] Where ICMP Message Is Any 11a) Allow DHCP "negotiation": Allow IP In/Out From MAC Any To IP 255.255.255.255 Where Protocol Is Any 12) In order to allow "airvpn.org" resolution even when disconnected (and any other hostname you wish to be resolved even when VPN is disconnected), add to your hosts file the line: 95.211.138.143 airvpn.org Do not forget about this change! If we change our main frontend IP address, you will not be able to reach airvpn.org anymore until you remove that line. No more necessary starting with Air client edition 2 "Eddie". 13) If you use the Air client, add rules to allow communications with IP addresses 5.196.64.52 and 95.211.138.143 (two of our frontend servers), In and Out Allow TCP or UDP In/Out From IP 5.196.64.52 To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To IP 5.196.64.52 Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From IP 95.211.138.143 To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To IP 95.211.138.143 Where Source Port Is Any And Destination Port Is Any 14) You can progressively enlarge your whitelist just by adding "Allow" rules before the total blocking rule of point 6) according to your system needs. Keep in mind that there are literally dozens of ways to accomplish the same task with Comodo. Pay attention not to confuse the "-" symbol, which stands for "IP range", with the "/" symbol, which stands for IP address / NetMask. For example, [10.4.0.0 - 10.9.255.255] is correct (the IP range from 10.4.0.0 to 10.9.255.255), while [10.4.0.0 / 10.9.255.255] is NOT correct (IP 10.4.0.0 NetMask 10.9.255.255, which covers almost every existing IP address!). When you have defined all the rules, do not forget to click "Apply" and "OK" in order to store them and make them active for any new connection. Test everything and do not be afraid to experiment before you rely on the secured connection for sensitive data transmissions. Kind regards