Search the Community

Hello all, This is collection from different tutorials which I will refer here, but usually changed since some things changed. Setting up VPN on Synology is modified neolefort tutorial from here and reconnect script if from sundi which you can find here, which probably modified this script, plus my iptables for blocking Synology on router level when VPN fails. Other contributions: foobar666 - you no longer need to enter variables manually _sinnerman_ - fixed script for DS 6.1 I'm doing this mostly because I usually forget things I managed to solve after year or two, so this is way to have constant reminder how it was solved and also help others. 1. Get your certificates from AirVPN. Go to the https://airvpn.org/generator/ page to generate the configuration file. (1) SELECT the Advanced Mode (under "Config generator" title ) (2) SELECT LINUX OS (3) Under "Protocols" section select one with protocol UDP, port 443 and tls-auth in the right column (at the time of writing, it was in middle of the list). You can choose any combination of protocol/port, but then also change iptables accordingly if you are using failsafe script. Don't choose any combination which has tls-crypt in the right column. (4) Under "Advanced - OpenVPN only" section (right part of page), toggle "Separate keys/certs from .ovpn file" button and change/leave OpenVPN version to 2.5 (This works in DSM 7.2.1. For older versions you will maybe have to select OpenVPN version 2.4). (5) SELECT 1 SERVER (refer to section "by single servers") OR COUNTRY OR ANYTHING ELSE YOU WANT In original tutorial, neolefort said to choose 1 server, because in that case you will get IP instead of xxx.airvpn.org domain. Choosing 1 server is safe because it doesn't need working DNS when you want to connect to VPN. If you choose anything else, you need working DNS on your router when establishing VPN connection. (6) Click "GENERATE" at the bottom. (7) Page will reload with links on top to your files, save them to you computer. Following files will be generated: -AirVPN_XXXXX_UDP-443.ovpn -ca.crt -user.crt -user.key -ta.key 2. Setup AirVPN on Synology. - Login as admin or with user from Administrator group. - Open Control panel. - Go "Network" and click on tab "Network Interface" - Click on button "Create" - "Create VPN profile" - Choose "OpenVPN (via importing .ovpn file)" - Click "Advanced options" so it shows all options - Profile name: anything you want, but please keep is short and if you can without spaces " ", for example "AirVPN". - User name: LEAVE EMPTY (for DSM 7+ just put anything here) - Password: LEAVE EMPTY (for DSM 7+ just put anything here) - Import .ovpn file: click button and import your AirVPN_XXXXX_UDP-443.ovpn - CA certificate: click button and import your ca.crt - Client certificate: click button and import your user.crt - Client key: click button and import your user.key - Certificate revocation: LEAVE EMPTY - TLS-auth key: click button and import your ta.key - Click "Next" - Select all options and click "Done" Now you have working OpenVPN link on your Synology. You just need to start it from "Control panel" - "Network" - "Network Interface". If you want to make your connection faster, you can remove some ciphers. Look for this line in .ovpn file: data-ciphers AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC:AES-128-GCM:AES-128-CBC And change it to this: data-ciphers AES-128-GCM Then save file and create new connection with it. After some testing I found out AES-128-GCM is fastest from all other mentioned in settings. You can also test other ciphers your self and leave one you find fastest. EXTRAS!!! 3. Setting up external access to your Synology. First what you will notice is, "I CAN'T ACCESS MY SYNOLOGY FROM OUTSIDE OF MY LAN!!!!!!! OMG OMG OMG!!!!" I will not explain port fowards on your router here, if you don't know how to make one, learn! (1) You can port forward trough AirVPN webpage and access your Syno via VPN exit IP. This sometimes works, most of times it doesn't since Syno has some ports you cannot change. Anyway, change your default HTTP / HTTPS port on Syno to your forwarded AirVPN port and you should be fine. But forget about Cloudstation and similliar things. (2) If you want to access Syno via you ISP IP (WAN), then problem is, your Syno is receiving your connection, but it's replying trough VPN. That's a security risk and those connections get droped. But there is solution! - Access "Control panel" - "Network" - "General" - Click "Advanced Settings" button - Mark "Enable multiple gateways" and click "OK" and then "Apply" You're done! It's working now (if you forwarded good ports on your router). 4. Prevent leaks when VPN connection on Synology fails. There will be time, when you VPN will fail, drop, disconnect, and your ISP IP will become visible to world. This is one of ways you can prevent it, on router level. For this you need Tomato, Merlin, DD-WRT or OpenWRT firmware on your router. I will tell you steps for Tomato router. If you are using different firmware, then you need to learn alone how to input this code into your router. Since Shibby version 129 for ARM routers, syntax of iptables changed and depending on which version of iptables you are using, apply that code. - Login to your router (usually just by entering 192.168.1.1 into your browser, if your IP is different, find out which is your gateway IP). - Click on "Administration" - Click on "Scripts" - Choose tab "Firewall" For Shibby v129 for ARM and later (iptables 1.4.x) us this: #Use this order of commands because it executes in reverse order. #This command will execute last, it kills all UDP requests. iptables -I FORWARD -p udp -s 192.168.1.100 -j REJECT #This command will execute second and will block all TCP source ports except those needed for web access or services iptables -I FORWARD -p tcp -s 192.168.1.100 -m multiport ! --sports 5000,5001,6690 -j REJECT #This command will execute first and will ACCEPT connection to your VPN on destination port 443 UDP iptables -I FORWARD -p udp -s 192.168.1.100 -m multiport --dports 443 -j ACCEPT For earlier Shibby versions and later for MIPS routers: #Use this order of commands because it executes in reverse order. #This command will execute last, it kills all UDP requests. iptables -I FORWARD -p udp -s 192.168.1.100 -j REJECT #This command will execute second and will block all TCP source ports except those needed for web access or services iptables -I FORWARD -p tcp -s 192.168.1.100 -m multiport --sports ! 5000,5001,6690 -j REJECT #This command will execute first and will ACCEPT connection to your VPN on destination port 443 UDP iptables -I FORWARD -p udp -s 192.168.1.100 -m multiport --dports 443 -j ACCEPT Port TCP 5000 = HTTP for for Synology web access (change to your if it's not default) Port TCP 5001 = HTTPS for for Synology web access (change to your it's not default) Port TCP 6690 = Cloud Station port Port UDP 443 = AirVPN connection port which you defined in step 1 of this tutorial. If you are using TCP port, then you need to change "-p udp" to "-p tcp" in that line. If you need more ports, just add them separated by comma ",". If you want port range, for example 123,124,125,126,127, you can add it like this 123:127. Change IP 192.168.1.100 to your Synology LAN IP. Be careful NOT TO assign those ports to your Download Station on Synology. This isn't perfect, you can still leak your IP through UDP 443, but since torrent uses mostly TCP, those chances are minimal. If you use TCP port for VPN, then those chances increase. If you really want to be sure nothing leaks even on UDP 443 (or your custom port), you need to choose 1 (ONE) AirVPN server. You need to find that server entry IP and change last IPTABLES rule to something like this: iptables -I FORWARD -p udp -s 192.168.1.100 -d 123.456.789.123 -m multiport --dports 443 -j ACCEPT Where 123.456.789.123 is AirVPN server entry IP. This will allow UDP 443 only for that server, rest will be rejected by router. These are all my opinions, from my very limited knowledge, which may be right and may be wrong. 5. Auto reconnection when VPN is down. Since when you made your VPN connection on your Synology, you checked "Reconnect" option, Syno will try to reconnect automaticly when connection fails. But in some cases, your network will be offline long enough and Syno will stop trying to reconnect, or will hang with VPN connection established, but not working. In those cases you can use this auto reconnect script. This is reconnect script. Just select all script text and copy it. #VPN Check script modified Sep 11, 2016 #Script checks if VPN is up, and if it is, it checks if it's working or not. It provides details like VPN is up since, data #received/sent, VPN IP & WAN IP. #If VPN is not up it will report it in the log file and start it #Change LogFile path to your own location. #Save this script to file of your choosing (for example "synovpn_reconnect"). Store it in one of your Synology shared folders and chmod it: "chmod +x /volume1/shared_folder_name/your_path/synovpn_reconnect" #Edit "/etc/crontab" and add this line without quotes for starting script every 10 minutes: "*/10 * * * * root /volume1/shared_folder_name/your_path/synovpn_reconnect" #After that restart cron with: "/usr/syno/sbin/synoservicectl --restart crond" #!/bin/sh DATE=$(date +"%F") TIME=$(date +"%T") VPNID=$(grep "\[.*\]" /usr/syno/etc/synovpnclient/openvpn/ovpnclient.conf | cut -f 2 -d "[" | cut -f 1 -d "]") VPNNAME=$(grep conf_name /usr/syno/etc/synovpnclient/openvpn/ovpnclient.conf | cut -f 2 -d "=") LogFile="/volume1/filmovi/Backup/airvpn/check_airvpn_$DATE.log" PUBIP=$(curl -s -m 5 icanhazip.com) #PUBIP=$(curl -s -m 5 ipinfo.io/ip) #PUBIP=$(curl -s -m 5 ifconfig.me) CHECKIP=$(echo $PUBIP | grep -c ".") start_vpn() { echo "VPN is down. Attempting to (re)start now." >> $LogFile # /usr/syno/bin/synovpnc kill_client --protocol=openvpn --name=$VPNNAME /usr/syno/bin/synovpnc kill_client /bin/kill `cat /var/run/ovpn_client.pid` 2>/dev/null sleep 35 echo 1 > /usr/syno/etc/synovpnclient/vpnc_connecting echo conf_id=$VPNID > /usr/syno/etc/synovpnclient/vpnc_connecting echo conf_name=$VPNNAME >> /usr/syno/etc/synovpnclient/vpnc_connecting echo proto=openvpn >> /usr/syno/etc/synovpnclient/vpnc_connecting /usr/syno/bin/synovpnc reconnect --protocol=openvpn --name=$VPNNAME >> $LogFile } sleep 6 echo "======================================" >> $LogFile echo "$DATE $TIME" >> $LogFile if ifconfig tun0 | grep -q "00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00" then if [ "$CHECKIP" == 1 ] then IPADDR=$(/sbin/ifconfig tun0 | grep 'inet addr' | cut -d: -f2 | awk '{print $1}') RXDATA=$(/sbin/ifconfig tun0 | grep "bytes:" | cut -d: -f2 | awk '{print $1,$2,$3}') TXDATA=$(/sbin/ifconfig tun0 | grep "bytes:" | cut -d: -f3 | awk '{print $1,$2,$3}') UPTIME=$(cat /var/log/messages | grep "$IPADDR" | awk '{print $1}' | tail -1) UPTIME=$(date -d"$UPTIME" +"%Y/%m/%d %H:%M:%S") echo "VPN is up since: $UPTIME" >> $LogFile echo "Session Data RX: $RXDATA" >> $LogFile echo "Session Data TX: $TXDATA" >> $LogFile echo "VPN IP is: $IPADDR" >> $LogFile echo "WAN IP is: $PUBIP" >> $LogFile else start_vpn fi else start_vpn fi exit 0 (1) Login to you Synology DSM web interface as admin. - As admin go to "Control panel" - "Task Scheduler" (you need to enable advanced mode in top right corner of control panel for this) - Click "Create" button near top of page, then select "Scheduled Task" and then "User-defined script" (2) New popup window will open. - under "Task:" enter task name - under "User:" select "root" if it's not already selected - switch to "Schedule" tab and select how often you want this task to run, my settings are: - "Run of following days" - "Daily" - "First run time" - 00:00 - "Frequency" - "Every 10 minutes" - "Last run time" - 23:50 - switch to "Task settings" tab - paste script you copied into empty box under "User-defined script" title - press OK and you're done I tested this on DSM 6.2.2 and it works without problems for now. Still, I'm keeping old instructions in next post, if someone wants to do it like that. Tip: If you don't want logfile, you can comment out those lines, or remove ">> $LogFile" code from whole script. That's all. If you entered everything correctly, you should be fine and ready to go! Comments are welcome. If you find mistakes, please correct me.

I have installed WireGuard on my Synology. Does anyoe know if there is a way to connect? My configuration looks like this, but no connection is being established, and I am getting an error message.

I'm on macOS sonoma, using Eddie with network lock and port forwarding set up in qbittorrent. I'm not getting any transfer activity. The interface list in the advanced settings doesn't have "eddie" like it does on pc. I've been trying them all, but nothing seems to enable transfers. I've attached a screenshot of the options available to me. I have a feeling it's one of the utun0-6, but I can't get it to work. Any help?

Ive followed instructions below (both methods, same resulting interface) to bind qbit to Eddie and it did not work. I tested with this ubunti torrent which should stop when you disconnect and it did not stop.

Linux user (ZorinOS, based on Ubuntu 22.04). Recently upgraded its version on a clean install, and now Eddie leaks DNS requests (this was not the case on the older version). On ipleak.net, first it shows the VPN's DNS, then some "GOOGLE" stuff I'm not sure where they're from, then my real ISP DNS. This is the case on multiple browsers (hardened firefox and brave)‌ so I'm assuming it's a system-wide issue. Please if you have any suggestions let me know

Hello. I stumble accross this article https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the-vpn-tunnel-on-android and i would like to know if Eddie is affected or what should i do to avoid this issue. Thank you.

Can this happen while being connected via AirVPN ? I do not know? --- Read more of this story at Slashdot. https://yro.slashdot.org/story/22/01/31/222250/website-fined-by-german-court-for-leaking-visitors-ip-address-via-google-fonts I originally saw this story posted on Facebook and here is their comment thread on it: https://www.facebook.com/slashdot/posts/10158469206330857 I do not know if this can still happen while being connected on ANY VPN, let alone while on or using AirVPN? Can anyone help me who knows better? I guess a simple yes or no from someone who knows better, would be reassuring lol

Hi, I configured my router to work via ee.vpn.airdns.org and use Google DNS servers (8.8.8.8 and 8.8.4.4). All requests do seem to go via 213.152.161.25, ipleak.net doesn't show any leaks curl ifconfig.me returns 213.152.161.25, all DNS requests seem to go via the VPN too: $ traceroute -U 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 Linksys00639.lan (10.20.0.1) 1.119 ms 1.814 ms 1.872 ms 2 10.24.244.1 (10.24.244.1) 71.463 ms 71.703 ms 71.763 ms 3 hosted-by-macrobash.com (134.19.179.249) 78.392 ms 78.364 ms 78.336 ms 4 37.123.210.78 (37.123.210.78) 75.221 ms 72.374 ms 72.561 ms 5 core1.ams.net.google.com (80.249.208.247) 72.763 ms 72.508 ms 72.712 ms 6 108.170.241.193 (108.170.241.193) 73.058 ms 108.170.241.161 (108.170.241.161) 71.979 ms 108.170.241.225 (108.170.241.225) 72.067 ms 7 142.251.48.175 (142.251.48.175) 71.375 ms 172.253.71.199 (172.253.71.199) 73.352 ms 142.250.211.91 (142.250.211.91) 73.113 ms 8 * * * Just like any other traffic: $ traceroute google.com traceroute to google.com (142.251.36.14), 30 hops max, 60 byte packets 1 Linksys00639.lan (10.20.0.1) 0.649 ms 1.530 ms 1.554 ms 2 10.24.244.1 (10.24.244.1) 138.558 ms 138.657 ms 138.702 ms 3 hosted-by-macrobash.com (134.19.179.249) 222.638 ms 222.611 ms 222.585 ms 4 37.123.210.78 (37.123.210.78) 137.943 ms 137.867 ms 137.833 ms 5 core1.ams.net.google.com (80.249.208.247) 137.803 ms 137.774 ms 137.745 ms 6 108.170.241.129 (108.170.241.129) 138.485 ms 108.170.241.161 (108.170.241.161) 134.951 ms 108.170.241.129 (108.170.241.129) 135.559 ms 7 172.253.71.201 (172.253.71.201) 135.577 ms 172.253.71.199 (172.253.71.199) 72.217 ms 72.184 ms 8 ams15s44-in-f14.1e100.net (142.251.36.14) 72.526 ms 72.487 ms 72.638 ms The problem is that Google somehow detects my ISP's IP address: whatismyipaddress.com also sometimes reports that address (and sometimes it reports 213.152.161.25). I have a "kill switch" configured, so whenever the VPN tunnel goes down nothing is routed via my ISP. My own web server hosted on AWS always shows me that I connect from 213.152.161.25 (even when whatismyipaddress.com and Google show me 91.236.xxx.xxx). How can that happen?

Any advice greatly appreciated on this subject as i am not of a high level of understanding when it comes to networking in Linux iptables! When connected to a vpn server through Eddie on a Ubuntu based Linux OS i always use the network lock feature in Eddie. This should lock the Linux iptables to stop any traffic outside the vpn tunnel. When i use any IP check service, or torrent address checker, (e.g ipleak.net) they always come back with no leaks. However, whilst torrenting, if i use the NETSTAT command in the terminal, i can see established connections to IP addresses matching the IP's of peers I'm connected to in my torrent client! I thought that the only ip i should see in netstat should be the VPN server NOT the peers as i shouldn't be connected to them directly? Am i leaking my IP outside the tunnel or should i expect to see bittorrent peer ip addresses in netstat when using the vpn? Thank you!

Hi I use a custom bash script in Linux to enable leak protection using iptables. That is, the firewall blocks all the outgoing internet connections whose destination is a non-AirVPN IP address. I would like to keep the protection enabled always and automatically connect to the best current server in the Netherlands, for instance. This requires resolving the IP address of nl.vpn.airdns.org. However, if the leak protection is enabled and I have not connected to any AirVPN server, I cannot resolve the IP address. Neither I would like to enable temporarily access to some other DNS service, like Cloudflare's 1.1.1.1 or Google's 8.8.8.8 nor temporarily connecting to a random AirVPN server to just find out the best current server. I have not yet tested the AirVPN's Linux suite, which would likely do this automatically. I wonder, if there is a way to accomplish this DNS name resolution in a simple manner using just bash? What I know AirVPN does not have public DNS servers.

Hi - the instructions for setting up AirVPN on Chromebook are very helpful, and worked for me. https://airvpn.org/chromeos/ But I cannot figure out if the "block-outside-dns" (or similar) command is enabled as part of this software and settings. When I used dnsleaktest.com I don't see any leaks, and it seems like the "tunnel" is secure. So: Can someone tell me if the AirVPN Chromebook set up has the same "network lock" functionality as Eddie does when I use it on a Mac? Is there a code to use or setting to *check* to make sure this is *always* enabled (block outside dns etc.)? Thank you!

Hi all, I've followed the instructions at https://airvpn.org/topic/11431-using-airvpn-with-linux-from-terminal/ in order to set up my account. This works fine and leak-free, when my local networks gives me an IPv4 address -- but if I get an IPv6 address, that address is leaked to remote sites according to https://ipleak.net/ . How do I prevent that? Thanks, Chris

I'm sorry if I say anything stupid here I'm not claiming to know anything except that network lock is enabled, my DNS servers and ipv4 settings are on airvpns reccomended, and I still get webRTC leaks. See attached image below for an example of ipleak test on mozilla. Same results show on Chrome. Only setting I changed from default was what I saw in another forum to fix a problem where once network locked you were permanently stuck checking ipv6 unable to connect. https://airvpn.org/topic/28749-eddie-problems-wont-connect-keeps-dropping/Posted 12 July 2018 - 06:26 AM UPDATE: If anyone is having an issue with IPv6 check hanging during scanning try this (Support guys advised solution and it works for me ) In Eddie "Preferences" > "Networking" set: Layer IPv4: Inside Tunnel Layer IPv6: Blocked (HERE IS THE DIFFERENCE) Protocol used for connection: IPv4 only (another difference) Click "Save" to save the changes and test again. I'm not sure how bad webRTC leaks are and I would also like to ask if my ISP can find my torrents since I just noticed this, been torrenting for half an hour thought network lock would have made that ok but now I'm worred as I am one strike away from my service being terminated. I am aware that you can disable this in browser, but if browsers can see my personal info and location here it makes me nervous ISP can as well. I'm using windows 7 Home Premium and the only virus protection I have is windows defender. Logs here Eddie System/Environment Report - 9/26/2018 2:29 AM UTC Eddie version: 2.16.3 Eddie OS build: windows_x64 Eddie architecture: x64 OS type: Windows OS name: Windows 7 Home Premium OS version: Microsoft Windows NT 6.1.7601 Service Pack 1 OS architecture: x64 Mono /.Net Framework: v2.0.50727 OpenVPN driver: TAP-Windows Adapter V9, version 9.21.2 OpenVPN: 2.4.6 - OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 (C:\Program Files\AirVPN\openvpn.exe) SSH: plink 0.67 (C:\Program Files\AirVPN\plink.exe) SSL: stunnel 5.40 (C:\Program Files\AirVPN\stunnel.exe) curl: 7.54.1 (C:\Program Files\AirVPN\curl.exe) Profile path: C:\Users\brettwardo\AppData\Local\AirVPN\default.xml Data path: C:\Users\brettwardo\AppData\Local\AirVPN Application path: C:\Program Files\AirVPN Executable path: C:\Program Files\AirVPN\Eddie-UI.exe Command line arguments: (1 args) path="home" Network Lock Active: Yes, Windows Filtering Platform Connected to VPN: Yes, Lesath Detected DNS: 10.20.228.1, 10.4.0.1, 10.5.0.1, 2607:f428:ffff:ffff::1, 2607:f428:ffff:ffff::2 Test DNS IPv4: Ok Test DNS IPv6: Failed Test Ping IPv4: 54 ms Test Ping IPv6: -1 ms Test HTTP IPv4: Ok Test HTTP IPv6: Error:curl: (7) Failed to connect to ipv6.eddie.website port 80: Bad access Test HTTPS: Ok ---------------------------- Important options not at defaults: login: (omissis) password: (omissis) remember: True network.entry.iplayer: ipv4-only network.ipv6.mode: block ---------------------------- Logs: . 2018.09.25 21:14:24 - Eddie version: 2.16.3 / windows_x64, System: Windows, Name: Windows 7 Home Premium, Version: Microsoft Windows NT 6.1.7601 Service Pack 1, Mono/.Net: v2.0.50727 . 2018.09.25 21:14:24 - Reading options from C:\Users\brettwardo\AppData\Local\AirVPN\default.xml . 2018.09.25 21:14:24 - Command line arguments (1): path="home" . 2018.09.25 21:14:24 - Profile path: C:\Users\brettwardo\AppData\Local\AirVPN\default.xml . 2018.09.25 21:14:26 - OpenVPN Driver - TAP-Windows Adapter V9, version 9.21.2 . 2018.09.25 21:14:26 - OpenVPN - Version: 2.4.6 - OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 (C:\Program Files\AirVPN\openvpn.exe) . 2018.09.25 21:14:26 - SSH - Version: plink 0.67 (C:\Program Files\AirVPN\plink.exe) . 2018.09.25 21:14:26 - SSL - Version: stunnel 5.40 (C:\Program Files\AirVPN\stunnel.exe) . 2018.09.25 21:14:26 - curl - Version: 7.54.1 (C:\Program Files\AirVPN\curl.exe) . 2018.09.25 21:14:26 - Certification Authorities: C:\Program Files\AirVPN\res\cacert.pem . 2018.09.25 21:14:26 - Updating systems & servers data ... I 2018.09.25 21:14:27 - Ready . 2018.09.25 21:14:27 - Systems & servers data update completed ! 2018.09.25 21:14:33 - Activation of Network Lock - Windows Filtering Platform I 2018.09.25 21:14:34 - Session starting. I 2018.09.25 21:14:34 - Checking authorization ... . 2018.09.25 21:14:35 - IPv6 disabled with packet filtering. ! 2018.09.25 21:14:35 - Connecting to Grumium (Canada, Toronto, Ontario) . 2018.09.25 21:14:35 - OpenVPN > OpenVPN 2.4.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 27 2018 . 2018.09.25 21:14:35 - OpenVPN > Windows version 6.1 (Windows 7) 64bit . 2018.09.25 21:14:35 - OpenVPN > library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 . 2018.09.25 21:14:35 - Connection to OpenVPN Management Interface . 2018.09.25 21:14:35 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2018.09.25 21:14:35 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.25 21:14:35 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.25 21:14:35 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]199.19.95.187:443 . 2018.09.25 21:14:35 - OpenVPN > Socket Buffers: R=[8192->262144] S=[8192->262144] . 2018.09.25 21:14:35 - OpenVPN > UDP link local: (not bound) . 2018.09.25 21:14:35 - OpenVPN > UDP link remote: [AF_INET]199.19.95.187:443 . 2018.09.25 21:14:35 - OpenVPN > TLS: Initial packet from [AF_INET]199.19.95.187:443, sid=e36f7027 601fd48a . 2018.09.25 21:14:35 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2018.09.25 21:14:35 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2018.09.25 21:14:35 - OpenVPN > VERIFY KU OK . 2018.09.25 21:14:35 - OpenVPN > Validating certificate extended key usage . 2018.09.25 21:14:35 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2018.09.25 21:14:35 - OpenVPN > VERIFY EKU OK . 2018.09.25 21:14:35 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Grumium, emailAddress=info@airvpn.org . 2018.09.25 21:14:35 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2018.09.25 21:14:35 - OpenVPN > [Grumium] Peer Connection Initiated with [AF_INET]199.19.95.187:443 . 2018.09.25 21:14:36 - OpenVPN > SENT CONTROL [Grumium]: 'PUSH_REQUEST' (status=1) . 2018.09.25 21:14:36 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.18.36.1,dhcp-option DNS6 fde6:7a:7d20:e24::1,tun-ipv6,route-gateway 10.18.36.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:e24::10d5/64 fde6:7a:7d20:e24::1,ifconfig 10.18.36.215 255.255.255.0,peer-id 10,cipher AES-256-GCM' . 2018.09.25 21:14:36 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2018.09.25 21:14:36 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:e24::1' . 2018.09.25 21:14:36 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2018.09.25 21:14:36 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:e24::10d5/64 fde6:7a:7d20:e24::1' . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: peer-id set . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2018.09.25 21:14:36 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2018.09.25 21:14:36 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2018.09.25 21:14:36 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.25 21:14:36 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.25 21:14:36 - OpenVPN > interactive service msg_channel=0 . 2018.09.25 21:14:36 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=14 HWADDR=44:94:fc:f1:19:cf . 2018.09.25 21:14:36 - OpenVPN > open_tun . 2018.09.25 21:14:36 - OpenVPN > TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{3C87471E-B44B-4746-949C-C8101ADDA671}.tap . 2018.09.25 21:14:36 - OpenVPN > TAP-Windows Driver Version 9.21 . 2018.09.25 21:14:36 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.18.36.0/10.18.36.215/255.255.255.0 [sUCCEEDED] . 2018.09.25 21:14:36 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.18.36.215/255.255.255.0 on interface {3C87471E-B44B-4746-949C-C8101ADDA671} [DHCP-serv: 10.18.36.254, lease-time: 31536000] . 2018.09.25 21:14:36 - OpenVPN > Successful ARP Flush on interface [26] {3C87471E-B44B-4746-949C-C8101ADDA671} . 2018.09.25 21:14:36 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2018.09.25 21:14:41 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up . 2018.09.25 21:14:41 - OpenVPN > C:\Windows\system32\route.exe ADD 199.19.95.187 MASK 255.255.255.255 192.168.1.1 . 2018.09.25 21:14:41 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 21:14:41 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 21:14:41 - OpenVPN > C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.18.36.1 . 2018.09.25 21:14:41 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 21:14:41 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 21:14:41 - OpenVPN > C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.18.36.1 . 2018.09.25 21:14:41 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 21:14:41 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 21:14:41 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv4 . 2018.09.25 21:14:41 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv6 . 2018.09.25 21:14:41 - DNS leak protection with packet filtering enabled. . 2018.09.25 21:14:41 - DNS IPv4 of a network adapter forced (Local Area Connection 2, from automatic to 10.18.36.1) . 2018.09.25 21:14:41 - Routes, added a new route, 199.19.95.188 for gateway 10.18.36.1 . 2018.09.25 21:14:41 - Unable to compute route for 2604:6880:c713:5fbb:d656:d7e2:835e:6be2: IPv6 VPN gateway not available. . 2018.09.25 21:14:41 - Flushing DNS I 2018.09.25 21:14:47 - Checking route IPv4 I 2018.09.25 21:14:47 - Checking DNS ! 2018.09.25 21:14:48 - Connected. . 2018.09.25 21:14:48 - OpenVPN > Initialization Sequence Completed . 2018.09.25 21:24:27 - Updating systems & servers data ... . 2018.09.25 21:24:29 - Systems & servers data update completed . 2018.09.25 21:24:52 - OpenVPN > AEAD Decrypt error: bad packet ID (may be a replay): [ #109931 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings . 2018.09.25 21:34:29 - Above log line repeated 13 times more . 2018.09.25 21:34:29 - Updating systems & servers data ... . 2018.09.25 21:34:34 - Systems & servers data update completed . 2018.09.25 21:36:10 - OpenVPN > AEAD Decrypt error: bad packet ID (may be a replay): [ #711050 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings . 2018.09.25 21:42:30 - Above log line repeated 4 times more ! 2018.09.25 21:42:30 - Disconnecting . 2018.09.25 21:42:30 - Routes, removed a route previously added, 199.19.95.188 for gateway 10.18.36.1 . 2018.09.25 21:42:30 - Sending management termination signal . 2018.09.25 21:42:30 - Management - Send 'signal SIGTERM' . 2018.09.25 21:42:30 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM' . 2018.09.25 21:42:30 - OpenVPN > SIGTERM received, sending exit notification to peer . 2018.09.25 21:42:35 - OpenVPN > C:\Windows\system32\route.exe DELETE 199.19.95.187 MASK 255.255.255.255 192.168.1.1 . 2018.09.25 21:42:35 - OpenVPN > Route deletion via IPAPI succeeded [adaptive] . 2018.09.25 21:42:35 - OpenVPN > C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.18.36.1 . 2018.09.25 21:42:35 - OpenVPN > Route deletion via IPAPI succeeded [adaptive] . 2018.09.25 21:42:35 - OpenVPN > C:\Windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.18.36.1 . 2018.09.25 21:42:35 - OpenVPN > Route deletion via IPAPI succeeded [adaptive] . 2018.09.25 21:42:35 - OpenVPN > Closing TUN/TAP interface . 2018.09.25 21:42:35 - OpenVPN > TAP: DHCP address released . 2018.09.25 21:42:35 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting . 2018.09.25 21:42:35 - Connection terminated. . 2018.09.25 21:42:35 - IPv6 restored with packet filtering. . 2018.09.25 21:42:35 - DNS IPv4 of a network adapter restored to original settings (Local Area Connection 2, to automatic) . 2018.09.25 21:42:35 - DNS leak protection with packet filtering disabled. . 2018.09.25 21:42:35 - Interface Local Area Connection 2 metric restored from 3 to Automatic, layer IPv4 . 2018.09.25 21:42:35 - Interface Local Area Connection 2 metric restored from 3 to Automatic, layer IPv6 . 2018.09.25 21:42:35 - Flushing DNS ! 2018.09.25 21:42:41 - Session terminated. ! 2018.09.25 21:42:48 - Deactivation of Network Lock ! 2018.09.25 21:44:15 - Activation of Network Lock - Windows Filtering Platform I 2018.09.25 21:44:16 - Session starting. I 2018.09.25 21:44:16 - Checking authorization ... . 2018.09.25 21:44:17 - IPv6 disabled with packet filtering. ! 2018.09.25 21:44:17 - Connecting to Sualocin (Canada, Toronto, Ontario) . 2018.09.25 21:44:17 - OpenVPN > OpenVPN 2.4.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 27 2018 . 2018.09.25 21:44:17 - OpenVPN > Windows version 6.1 (Windows 7) 64bit . 2018.09.25 21:44:17 - OpenVPN > library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 . 2018.09.25 21:44:17 - Connection to OpenVPN Management Interface . 2018.09.25 21:44:17 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2018.09.25 21:44:17 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.25 21:44:17 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.25 21:44:17 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]184.75.221.42:443 . 2018.09.25 21:44:17 - OpenVPN > Socket Buffers: R=[8192->262144] S=[8192->262144] . 2018.09.25 21:44:17 - OpenVPN > UDP link local: (not bound) . 2018.09.25 21:44:17 - OpenVPN > UDP link remote: [AF_INET]184.75.221.42:443 . 2018.09.25 21:44:17 - OpenVPN > TLS: Initial packet from [AF_INET]184.75.221.42:443, sid=16fb3226 abdc439b . 2018.09.25 21:44:17 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2018.09.25 21:44:17 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2018.09.25 21:44:17 - OpenVPN > VERIFY KU OK . 2018.09.25 21:44:17 - OpenVPN > Validating certificate extended key usage . 2018.09.25 21:44:17 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2018.09.25 21:44:17 - OpenVPN > VERIFY EKU OK . 2018.09.25 21:44:17 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Sualocin, emailAddress=info@airvpn.org . 2018.09.25 21:44:17 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2018.09.25 21:44:17 - OpenVPN > [sualocin] Peer Connection Initiated with [AF_INET]184.75.221.42:443 . 2018.09.25 21:44:18 - OpenVPN > SENT CONTROL [sualocin]: 'PUSH_REQUEST' (status=1) . 2018.09.25 21:44:18 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.30.196.1,dhcp-option DNS6 fde6:7a:7d20:1ac4::1,tun-ipv6,route-gateway 10.30.196.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:1ac4::1023/64 fde6:7a:7d20:1ac4::1,ifconfig 10.30.196.37 255.255.255.0,peer-id 0,cipher AES-256-GCM' . 2018.09.25 21:44:18 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2018.09.25 21:44:18 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:1ac4::1' . 2018.09.25 21:44:18 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2018.09.25 21:44:18 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:1ac4::1023/64 fde6:7a:7d20:1ac4::1' . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: peer-id set . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2018.09.25 21:44:18 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2018.09.25 21:44:18 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2018.09.25 21:44:18 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.25 21:44:18 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.25 21:44:18 - OpenVPN > interactive service msg_channel=0 . 2018.09.25 21:44:18 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=14 HWADDR=44:94:fc:f1:19:cf . 2018.09.25 21:44:18 - OpenVPN > open_tun . 2018.09.25 21:44:18 - OpenVPN > TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{3C87471E-B44B-4746-949C-C8101ADDA671}.tap . 2018.09.25 21:44:18 - OpenVPN > TAP-Windows Driver Version 9.21 . 2018.09.25 21:44:18 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.30.196.0/10.30.196.37/255.255.255.0 [sUCCEEDED] . 2018.09.25 21:44:18 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.30.196.37/255.255.255.0 on interface {3C87471E-B44B-4746-949C-C8101ADDA671} [DHCP-serv: 10.30.196.254, lease-time: 31536000] . 2018.09.25 21:44:18 - OpenVPN > Successful ARP Flush on interface [26] {3C87471E-B44B-4746-949C-C8101ADDA671} . 2018.09.25 21:44:18 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2018.09.25 21:44:23 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up . 2018.09.25 21:44:23 - OpenVPN > C:\Windows\system32\route.exe ADD 184.75.221.42 MASK 255.255.255.255 192.168.1.1 . 2018.09.25 21:44:23 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 21:44:23 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 21:44:23 - OpenVPN > C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.30.196.1 . 2018.09.25 21:44:23 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 21:44:23 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 21:44:23 - OpenVPN > C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.30.196.1 . 2018.09.25 21:44:23 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 21:44:23 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 21:44:23 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv4 . 2018.09.25 21:44:23 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv6 . 2018.09.25 21:44:23 - DNS leak protection with packet filtering enabled. . 2018.09.25 21:44:23 - DNS IPv4 of a network adapter forced (Local Area Connection 2, from automatic to 10.30.196.1) . 2018.09.25 21:44:23 - Routes, added a new route, 184.75.221.43 for gateway 10.30.196.1 . 2018.09.25 21:44:23 - Unable to compute route for 2606:6080:1001:f:ed79:9361:ea0e:3e88: IPv6 VPN gateway not available. . 2018.09.25 21:44:23 - Flushing DNS I 2018.09.25 21:44:29 - Checking route IPv4 I 2018.09.25 21:44:30 - Checking DNS ! 2018.09.25 21:44:30 - Connected. . 2018.09.25 21:44:30 - OpenVPN > Initialization Sequence Completed . 2018.09.25 21:44:34 - Updating systems & servers data ... . 2018.09.25 21:44:36 - Systems & servers data update completed . 2018.09.25 21:45:46 - OpenVPN > AEAD Decrypt error: bad packet ID (may be a replay): [ #40969 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings . 2018.09.25 21:54:36 - Above log line repeated 16 times more . 2018.09.25 21:54:36 - Updating systems & servers data ... . 2018.09.25 21:54:38 - Systems & servers data update completed . 2018.09.25 22:00:07 - OpenVPN > write UDP: Unknown error (code=10065) . 2018.09.25 22:00:46 - Above log line repeated 45 times more ! 2018.09.25 22:00:46 - Disconnecting . 2018.09.25 22:00:46 - Routes, removed a route previously added, 184.75.221.43 for gateway 10.30.196.1 . 2018.09.25 22:00:46 - Sending management termination signal . 2018.09.25 22:00:46 - Management - Send 'signal SIGTERM' . 2018.09.25 22:00:46 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM' . 2018.09.25 22:00:46 - OpenVPN > SIGTERM received, sending exit notification to peer . 2018.09.25 22:00:51 - OpenVPN > C:\Windows\system32\route.exe DELETE 184.75.221.42 MASK 255.255.255.255 192.168.1.1 . 2018.09.25 22:00:51 - OpenVPN > Route deletion via IPAPI succeeded [adaptive] . 2018.09.25 22:00:51 - OpenVPN > C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.30.196.1 . 2018.09.25 22:00:51 - OpenVPN > Route deletion via IPAPI succeeded [adaptive] . 2018.09.25 22:00:51 - OpenVPN > C:\Windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.30.196.1 . 2018.09.25 22:00:51 - OpenVPN > Route deletion via IPAPI succeeded [adaptive] . 2018.09.25 22:00:51 - OpenVPN > Closing TUN/TAP interface . 2018.09.25 22:00:51 - OpenVPN > TAP: DHCP address released . 2018.09.25 22:00:51 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting . 2018.09.25 22:00:51 - Connection terminated. . 2018.09.25 22:00:51 - IPv6 restored with packet filtering. . 2018.09.25 22:00:51 - DNS IPv4 of a network adapter restored to original settings (Local Area Connection 2, to automatic) . 2018.09.25 22:00:51 - DNS leak protection with packet filtering disabled. . 2018.09.25 22:00:51 - Interface Local Area Connection 2 metric restored from 3 to Automatic, layer IPv4 . 2018.09.25 22:00:51 - Interface Local Area Connection 2 metric restored from 3 to Automatic, layer IPv6 . 2018.09.25 22:00:51 - Flushing DNS ! 2018.09.25 22:00:57 - Session terminated. ! 2018.09.25 22:01:19 - Deactivation of Network Lock ! 2018.09.25 22:01:21 - Activation of Network Lock - Windows Filtering Platform I 2018.09.25 22:01:23 - Session starting. I 2018.09.25 22:01:23 - Checking authorization ... . 2018.09.25 22:01:23 - IPv6 disabled with packet filtering. ! 2018.09.25 22:01:23 - Connecting to Lesath (Canada, Toronto, Ontario) . 2018.09.25 22:01:23 - OpenVPN > OpenVPN 2.4.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 27 2018 . 2018.09.25 22:01:23 - OpenVPN > Windows version 6.1 (Windows 7) 64bit . 2018.09.25 22:01:23 - OpenVPN > library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 . 2018.09.25 22:01:23 - Connection to OpenVPN Management Interface . 2018.09.25 22:01:23 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2018.09.25 22:01:23 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.25 22:01:23 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.25 22:01:23 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]184.75.221.2:443 . 2018.09.25 22:01:23 - OpenVPN > Socket Buffers: R=[8192->262144] S=[8192->262144] . 2018.09.25 22:01:23 - OpenVPN > UDP link local: (not bound) . 2018.09.25 22:01:23 - OpenVPN > UDP link remote: [AF_INET]184.75.221.2:443 . 2018.09.25 22:01:23 - OpenVPN > TLS: Initial packet from [AF_INET]184.75.221.2:443, sid=99f7cc86 7b2ab3a7 . 2018.09.25 22:01:23 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2018.09.25 22:01:23 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2018.09.25 22:01:23 - OpenVPN > VERIFY KU OK . 2018.09.25 22:01:23 - OpenVPN > Validating certificate extended key usage . 2018.09.25 22:01:23 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2018.09.25 22:01:23 - OpenVPN > VERIFY EKU OK . 2018.09.25 22:01:23 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Lesath, emailAddress=info@airvpn.org . 2018.09.25 22:01:24 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2018.09.25 22:01:24 - OpenVPN > [Lesath] Peer Connection Initiated with [AF_INET]184.75.221.2:443 . 2018.09.25 22:01:25 - OpenVPN > SENT CONTROL [Lesath]: 'PUSH_REQUEST' (status=1) . 2018.09.25 22:01:25 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.20.228.1,dhcp-option DNS6 fde6:7a:7d20:10e4::1,tun-ipv6,route-gateway 10.20.228.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:10e4::10c4/64 fde6:7a:7d20:10e4::1,ifconfig 10.20.228.198 255.255.255.0,peer-id 5,cipher AES-256-GCM' . 2018.09.25 22:01:25 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2018.09.25 22:01:25 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:10e4::1' . 2018.09.25 22:01:25 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2018.09.25 22:01:25 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:10e4::10c4/64 fde6:7a:7d20:10e4::1' . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: peer-id set . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2018.09.25 22:01:25 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2018.09.25 22:01:25 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2018.09.25 22:01:25 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.25 22:01:25 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.25 22:01:25 - OpenVPN > interactive service msg_channel=0 . 2018.09.25 22:01:25 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=14 HWADDR=44:94:fc:f1:19:cf . 2018.09.25 22:01:25 - OpenVPN > open_tun . 2018.09.25 22:01:25 - OpenVPN > TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{3C87471E-B44B-4746-949C-C8101ADDA671}.tap . 2018.09.25 22:01:25 - OpenVPN > TAP-Windows Driver Version 9.21 . 2018.09.25 22:01:25 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.20.228.0/10.20.228.198/255.255.255.0 [sUCCEEDED] . 2018.09.25 22:01:25 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.20.228.198/255.255.255.0 on interface {3C87471E-B44B-4746-949C-C8101ADDA671} [DHCP-serv: 10.20.228.254, lease-time: 31536000] . 2018.09.25 22:01:25 - OpenVPN > Successful ARP Flush on interface [26] {3C87471E-B44B-4746-949C-C8101ADDA671} . 2018.09.25 22:01:25 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2018.09.25 22:01:30 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up . 2018.09.25 22:01:30 - OpenVPN > C:\Windows\system32\route.exe ADD 184.75.221.2 MASK 255.255.255.255 192.168.1.1 . 2018.09.25 22:01:30 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 22:01:30 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 22:01:30 - OpenVPN > C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.20.228.1 . 2018.09.25 22:01:30 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 22:01:30 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 22:01:30 - OpenVPN > C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.20.228.1 . 2018.09.25 22:01:30 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.09.25 22:01:30 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.09.25 22:01:30 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv4 . 2018.09.25 22:01:30 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv6 . 2018.09.25 22:01:30 - DNS leak protection with packet filtering enabled. . 2018.09.25 22:01:30 - DNS IPv4 of a network adapter forced (Local Area Connection 2, from automatic to 10.20.228.1) . 2018.09.25 22:01:30 - Routes, added a new route, 184.75.221.3 for gateway 10.20.228.1 . 2018.09.25 22:01:30 - Unable to compute route for 2606:6080:1001:d:c59c:6e9a:3115:6f2f: IPv6 VPN gateway not available. . 2018.09.25 22:01:30 - Flushing DNS I 2018.09.25 22:01:36 - Checking route IPv4 I 2018.09.25 22:01:36 - Checking DNS ! 2018.09.25 22:01:37 - Connected. . 2018.09.25 22:01:37 - OpenVPN > Initialization Sequence Completed . 2018.09.25 22:03:17 - OpenVPN > AEAD Decrypt error: bad packet ID (may be a replay): [ #21871 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings . 2018.09.25 22:04:38 - Above log line repeated 4 times more . 2018.09.25 22:04:38 - Updating systems & servers data ... . 2018.09.25 22:04:43 - Systems & servers data update completed . 2018.09.25 22:05:32 - OpenVPN > AEAD Decrypt error: bad packet ID (may be a replay): [ #168297 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings . 2018.09.25 22:14:43 - Above log line repeated 20 times more . 2018.09.25 22:14:43 - Updating systems & servers data ... . 2018.09.25 22:14:49 - Systems & servers data update completed . 2018.09.25 22:24:49 - Updating systems & servers data ... . 2018.09.25 22:24:51 - Systems & servers data update completed ---------------------------- Network Interfaces and Routes: { "support_ipv4": true, "support_ipv6": true, "routes": [ { "address": "0.0.0.0\/0", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "192.168.1.1", "metric": "276" }, { "address": "0.0.0.0\/1", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "10.20.228.1", "metric": "3" }, { "address": "10.20.228.0\/24", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "10.20.228.198", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "10.20.228.255", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "127.0.0.0\/8", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "127.0.0.1", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "127.255.255.255", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "128.0.0.0\/1", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "10.20.228.1", "metric": "3" }, { "address": "184.75.221.2", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "192.168.1.1", "metric": "20" }, { "address": "184.75.221.3", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "10.20.228.1", "metric": "4" }, { "address": "192.168.1.0\/24", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "192.168.1.169", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "192.168.1.255", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "224.0.0.0\/4", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "224.0.0.0\/4", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "224.0.0.0\/4", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "255.255.255.255", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "255.255.255.255", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "255.255.255.255", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "::\/0", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "fe80::a3e:5dff:fe8c:d67a", "metric": "276" }, { "address": "::1", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "2600:6c4a:5d00:ac1::\/64", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "28" }, { "address": "2600:6c4a:5d00:ac1:0:7ece:4875:7bc9", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "2600:6c4a:5d00:ac1:1877:14e:85da:7a1", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "2600:6c4a:5d00:ac1:35aa:306a:8c91:7398", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "fe80::\/64", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "fe80::\/64", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "fe80::1877:14e:85da:7a1", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "fe80::31a3:666f:6191:32e", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" }, { "address": "ff00::\/8", "interface": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "gateway": "link", "metric": "306" }, { "address": "ff00::\/8", "interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "gateway": "link", "metric": "276" }, { "address": "ff00::\/8", "interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "gateway": "link", "metric": "259" } ], "interfaces": [ { "friendly": "Local Area Connection 2", "id": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "name": "Local Area Connection 2", "description": "TAP-Windows Adapter V9", "type": "Ethernet", "status": "Up", "bytes_received": "2136216354", "bytes_sent": "2520367760", "support_ipv4": true, "support_ipv6": true, "ips": [ "fe80::31a3:666f:6191:32e", "10.20.228.198" ], "gateways": [ "10.20.228.1" ], "bind": true, "dns4": "10.20.228.1", "dns6": null }, { "friendly": "Wireless Network Connection 3", "id": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "name": "Wireless Network Connection 3", "description": "NETGEAR WNDA3100v2 N600 Wireless Dual Band USB Adapter", "type": "Wireless80211", "status": "Up", "bytes_received": "2710689643", "bytes_sent": "2874237229", "support_ipv4": true, "support_ipv6": true, "ips": [ "2600:6c4a:5d00:ac1:0:7ece:4875:7bc9", "2600:6c4a:5d00:ac1:1877:14e:85da:7a1", "2600:6c4a:5d00:ac1:35aa:306a:8c91:7398", "fe80::1877:14e:85da:7a1", "192.168.1.169" ], "gateways": [ "192.168.1.1", "fe80::a3e:5dff:fe8c:d67a" ], "bind": true, "dns4": "10.4.0.1,10.5.0.1", "dns6": null }, { "friendly": "Local Area Connection", "id": "{DF769F17-E1B7-49C6-847A-8D8C2F5C173D}", "name": "Local Area Connection", "description": "Intel® Ethernet Connection (2) I219-V", "type": "Ethernet", "status": "Down", "bytes_received": "0", "bytes_sent": "0", "support_ipv4": true, "support_ipv6": true, "ips": [ "fe80::a4fd:d3cb:9bd4:90d", "169.254.9.13" ], "gateways": [], "bind": true, "dns4": "", "dns6": null }, { "friendly": "Loopback Pseudo-Interface 1", "id": "{846EE342-7039-11DE-9D20-806E6F6E6963}", "name": "Loopback Pseudo-Interface 1", "description": "Software Loopback Interface 1", "type": "Loopback", "status": "Up", "bytes_received": "0", "bytes_sent": "0", "support_ipv4": true, "support_ipv6": true, "ips": [ "::1", "127.0.0.1" ], "gateways": [], "bind": true, "dns4": null, "dns6": null }, { "friendly": "isatap.home", "id": "{22F03BFD-EC1C-4E68-AAF2-FA213A435BCA}", "name": "isatap.home", "description": "Microsoft ISATAP Adapter", "type": "Tunnel", "status": "Down", "bytes_received": "0", "bytes_sent": "0", "support_ipv4": true, "support_ipv6": true, "ips": [], "gateways": [], "bind": false, "dns4": null, "dns6": null }, { "friendly": "isatap.{3C87471E-B44B-4746-949C-C8101ADDA671}", "id": "{377485AD-B0E9-4E77-8EF0-6986F2E35604}", "name": "isatap.{3C87471E-B44B-4746-949C-C8101ADDA671}", "description": "Microsoft ISATAP Adapter #2", "type": "Tunnel", "status": "Down", "bytes_received": "0", "bytes_sent": "0", "support_ipv4": true, "support_ipv6": true, "ips": [ "fe80::5efe:10.20.228.198" ], "gateways": [], "bind": true, "dns4": null, "dns6": null }, { "friendly": "isatap.{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "id": "{6E326A1F-4759-43DB-AA7C-663901F34BFC}", "name": "isatap.{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}", "description": "Microsoft ISATAP Adapter #3", "type": "Tunnel", "status": "Down", "bytes_received": "0", "bytes_sent": "0", "support_ipv4": true, "support_ipv6": true, "ips": [ "fe80::5efe:192.168.1.169" ], "gateways": [], "bind": true, "dns4": null, "dns6": null } ], "ipv4-default-gateway": "10.20.228.1", "ipv4-default-interface": "{3C87471E-B44B-4746-949C-C8101ADDA671}", "ipv6-default-gateway": "fe80::a3e:5dff:fe8c:d67a", "ipv6-default-interface": "{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}" } ---------------------------- ipconfig /all: Windows IP Configuration Host Name . . . . . . . . . . . . : brettwardo-PC Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Mixed IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : home Ethernet adapter Local Area Connection 2: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-3C-87-47-1E DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::31a3:666f:6191:32e%26(Preferred) IPv4 Address. . . . . . . . . . . : 10.20.228.198(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Tuesday, September 25, 2018 10:01:25 PM Lease Expires . . . . . . . . . . : Wednesday, September 25, 2019 10:01:24 PM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 10.20.228.254 DHCPv6 IAID . . . . . . . . . . . : 436272956 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-85-B8-AC-44-94-FC-F1-19-CF DNS Servers . . . . . . . . . . . : 10.20.228.1 NetBIOS over Tcpip. . . . . . . . : Enabled Wireless LAN adapter Wireless Network Connection 3: Connection-specific DNS Suffix . : home Description . . . . . . . . . . . : NETGEAR WNDA3100v2 N600 Wireless Dual Band USB Adapter Physical Address. . . . . . . . . : 44-94-FC-F1-19-CF DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2600:6c4a:5d00:ac1:0:7ece:4875:7bc9(Preferred) Lease Obtained. . . . . . . . . . : Tuesday, September 25, 2018 8:08:37 PM Lease Expires . . . . . . . . . . : Monday, October 01, 2018 10:09:50 AM IPv6 Address. . . . . . . . . . . : 2600:6c4a:5d00:ac1:1877:14e:85da:7a1(Preferred) Temporary IPv6 Address. . . . . . : 2600:6c4a:5d00:ac1:35aa:306a:8c91:7398(Preferred) Link-local IPv6 Address . . . . . : fe80::1877:14e:85da:7a1%14(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.1.169(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : fe80::a3e:5dff:fe8c:d67a%14 192.168.1.1 DHCPv6 IAID . . . . . . . . . . . : 356816124 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-85-B8-AC-44-94-FC-F1-19-CF DNS Servers . . . . . . . . . . . : 2607:f428:ffff:ffff::1 2607:f428:ffff:ffff::2 10.4.0.1 10.5.0.1 NetBIOS over Tcpip. . . . . . . . : Enabled Connection-specific DNS Suffix Search List : home Ethernet adapter Local Area Connection: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : home Description . . . . . . . . . . . : Intel® Ethernet Connection (2) I219-V Physical Address. . . . . . . . . : B0-6E-BF-C1-39-4A DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Tunnel adapter isatap.home: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Tunnel adapter isatap.{3C87471E-B44B-4746-949C-C8101ADDA671}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Tunnel adapter isatap.{059B872A-1CA2-4DBA-9DDF-FB9A70B4B0DA}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : home Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3 Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes

When using VPN on Linux with openvpn I get 3 DNS adresses on ipleak.net. 1. AirVpn-Server Exit Ipv4, 2. AirVpn-Server Exit Ipv6 and 3. the residential address of my ISP. Note: This is not my own home IP, but rather the one by my ISP. Should I be worried? Ipv6 is disabled.

Hi, I'm using Eddie 2.13.6 on Debian. In the fall, I received a DMCA notice when I accidentally launched my torrent client while AirVPN was not running. To avoid this mistake in the future, I set the qBittorrent configuration setting "Network Interface" to tun0. The other day, I was having trouble accessing a website and thought they might be throttling/blocking the AirVPN server I was using, so I temporarily disconnected AirVPN and disabled the network lock. It seems that qBittorrent leaked over my wlan0 interface during this time, since I received another DMCA notice. Any suggestions on how I might safely configure my torrent client to cease all communication when the VPN is not enabled? Or maybe a way to temporarily configure only a single application (my Internet browser) to communicate outside of the Network Lock? Thanks.

Topic closed.

Eddie IS without a doubt leaking lastpass connections to the web through the vpn. Eddie is still using the 2.4.3 client; though seeing eddie is a big program it could be some other function of Eddie. Using OpenVPN 2.4.5 solves this leakage. So, OpenVPN 2.4.5 it is. Here is a screenshot of the leak inside Wireshark. https://ibb.co/jgdQqH https://image.ibb.co/gzbBVH/Leaks_using_Eddie.png

Hi, I have been happily using AirVPN with the same config for a few years. But today, I just realized that my real IP has probably been exposed for a few days. I restarted openvpn and everything is now back to normal, but I would like to avoid that in the future, and I would appreciate any relevant advice. I use an up to date Debian 9, and openvpn from the official packages. I created the config with the AirVPN configurator, and I added these lines, in order to automatically restart a stalled connection, and to have stats : ping 10 ping-restart 60 remap-usr1 SIGHUP status openvpn-status.log What follows are excerpts from the syslog. It started like this: [Altarf] Inactivity timeout (--ping-restart), restarting /sbin/ip route del 62.102.xxx.xxx/32 /sbin/ip route del 0.0.0.0/1 /sbin/ip route del 128.0.0.0/1 Closing TUN/TAP interface /sbin/ip addr del dev tun0 10.4.xxx.xxx/16 SIGHUP[soft,ping-restart] received, process restarting Inactivity timeout is always working well. But not this time: RESOLVE: Cannot resolve host address: europe.vpn.airdns.org:443 (Temporary failure in name resolution) The resolving problems lasts for half an hour. After that, inactivity was still detected, restarting every minute : [uNDEF] Inactivity timeout (--ping-restart), restarting After one hour hour after, I see this message : [server] Peer Connection Initiated with [AF_INET]213.152.xxx.xxx:443 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) AUTH: Received control message: AUTH_FAILED SIGTERM received, sending exit notification to peer SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) SIGTERM[soft,exit-with-notification] received, process exiting From now on, openvpn did not retry to connect, and my reaI IP is exposed. It was 4 days ago. How can I avoid such a behavior, so that my real IP is hidden, even if something like this happens again?

Is it an issue that I can see a local ip here? I know I can disable WebRTC, but I use it. It seems to me like it gets routed through vpn, since it changes when I disconnect. And I don't leak my real, public IP behind VPN from what I can see. Is this safe (pics) or am I leaking? Btw I use Ubuntu 16.04 and Eddie 2.13.6 with network lock enabled. Some help would be appreciated!

This may be a newb question, but I need to satisfy my curiosity. Whenever I fire up a VPN connection, I like to check with www.ipleak.net to make sure everything is on the up & up after connecting. I've noticed that on the results page, it shows "IPv6 test not reachable", which I assume means that the Eddie client is doing it's job and disabling IPv6 when connecting. I then see that under "DNS Addresses" it's show 2 servers, One using an IPv4 IP address and the other using an IPv6 address, but of course these two addresses are connected to the VPN IP address I've been assigned. This tells me that there is no DNS leaking going on. I've only witnessed this situation when using AirVPN's servers and the Eddie client (as opposed to, for example, using another VPN service and their connection client). I attached a screencap to show what I am talking about: So, after my long-winded explanation of the issue, here's my question. Because it is showing two DNS servers, and one being a IPv6 server, is this a potential leak for IPv6 traffic since the test is able to connect to this particular server? Is it also possible for it to be a DNS leak, even though it is obviously associated with VPN server that gave me this particular IP address? I'm wondering about this simply because when I use other VPN providers and check ipleak.net, it only shows the one DNS server (IPv4) with the same IP address as the one issued to me by the VPN server. This would lead me to believe that my VPN connection is correctly blocking leaks and using DNS servers provided by the VPN service. Any help with this would be greatly appreciated, and of course, please don't hesitate to ask if I need to clarify any information.

Hi I tried accessing some torrent sites in the UK yesterday while using AirVPN (Eddie client, connected to Atik, Netherlands server) and they still seemed to be blocked "by the high court" which led me to believe that somehow the VPN isn't working on that there's a leak as it's seeing that I'm in the UK. So I went to https://www.dnsleaktest.com/ and it says I'm in the Netherlands, which seems correct as that's the server I've connected to but then when I do the standard test, it shows me 4 servers with my country and ISP provider. I have enabled Network Lock at startup in the preferences but that doesn't seem to change anything. Is there something else I should be doing? Sorry I'm new to this. Why would I not be able to access these sites if I'm connected to the Netherlands where they're not blocked? Thanks. EDIT: El Capitan, not Mavericks!

Hi. My ISP assigns me an IPv4 and v6 address. v4 seems to be tunneled fine, but IPv6 still yields my own IP. I.e. when I visit https://ipleak.net/ I see the VPN address for ipv4, but still my own ipv6 address. I'm using the official client on Windows 7, where I tried both settings in "advanced": None and Disabled. Both yield the same result. Any input?

I recently upgraded to latest Ubuntu Version and just found out I'm leaking DNS. Even though I'm using Eddie v2.12.4 with network lock enabled. I tried to add block-outside-dns to ovpn directives in Eddie settings but I'm still leaking DNS. Didn't read correct, this works only in Windows. edit: I tried to use OpenVPN with a config file and DNS push with resolvconf instead of Eddie with same results. Still leaking DNS. Tried to use a VM with Ubuntu 16.10 configured DNS push and had no leaks. So I guess something is wrong with resolvconf in Ubuntu 17.04. edit2: Seems to be a Ubuntu 17.04 problem. Many users seem to have problems with DNS. Still looking for help here. If anyone has an idea. Since this is no Eddie specific problem please push this topic to the right subforum.

Hello everyone! I am using AirVPN on Fedora 25 and the first week it worked perfectly. But, as I got a router (D-Link DIR-868L) this week I have started noticing DNS Leaks occurring now and then, and if I bypass the router by connecting straight to wall the DNS leaks go away. It doesn't seem to matter what way I have of connecting to the VPN, I have tried Gnome-Network-Manager, Eddie and using the terminal and it is all the same. How can I fix this?

So I've just installed the AirVPN client and got it to work without any troubles, every setting is set on default. But sadly after running a test on doileak.com (can't connect to doileak.net ??) I see instances of DNS requests originating from my ips. I use Firefox which according to the test is not suffering from an WebRTC IP Leak. When checking the ethernet connections like the TAP-Windows Adapter V9 IPV4 settings I do see its working with a preferred DNS server adress. Changing this to obtaining a DNS server address automatically did not solve the issue. Neither after a pc restart. I have no idea how to solve this. (ps. I confused doileak.com with ipleak.net, so yeah of course I cannot connect to doileak.net )