Search the Community

Hi i dont have a problem when connecting via ipv4 protocol. but i cant connect via ipv6 i tried on multiple computers and multiple routers on different networks, problem presisted throughout last 3 years Log: I 2023.01.06 13:38:04 - Session starting. I 2023.01.06 13:38:04 - Checking authorization ... . 2023.01.06 13:38:05 - Using WinTun network interface "OpenVPN Wintun (Wintun Userspace Tunnel)" ! 2023.01.06 13:38:05 - Connecting to Caph (Netherlands, Alblasserdam) . 2023.01.06 13:38:05 - Routes, add 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)". . 2023.01.06 13:38:05 - Routes, add 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)", already exists. . 2023.01.06 13:38:05 - OpenVPN > OpenVPN 2.5.5 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 15 2021 . 2023.01.06 13:38:05 - OpenVPN > Windows version 10.0 (Windows 10 or greater) 64bit . 2023.01.06 13:38:05 - OpenVPN > library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10 . 2023.01.06 13:38:05 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2023.01.06 13:38:05 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2023.01.06 13:38:05 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2023.01.06 13:38:05 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2023.01.06 13:38:05 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET6]2a00:1678:2470:18:5ac5:3314:8260:3523:443 . 2023.01.06 13:38:05 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144] . 2023.01.06 13:38:05 - OpenVPN > UDPv6 link local: (not bound) . 2023.01.06 13:38:05 - OpenVPN > UDPv6 link remote: [AF_INET6]2a00:1678:2470:18:5ac5:3314:8260:3523:443 . 2023.01.06 13:38:37 - OpenVPN > [UNDEF] Inactivity timeout (--ping-exit), exiting . 2023.01.06 13:38:37 - OpenVPN > SIGTERM received, sending exit notification to peer . 2023.01.06 13:38:42 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting ! 2023.01.06 13:38:42 - Disconnecting . 2023.01.06 13:38:42 - Routes, delete 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)". . 2023.01.06 13:38:42 - Routes, delete 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)", not exists. . 2023.01.06 13:38:42 - Connection terminated. I 2023.01.06 13:38:45 - Checking authorization ... . 2023.01.06 13:38:45 - Using WinTun network interface "OpenVPN Wintun (Wintun Userspace Tunnel)" ! 2023.01.06 13:38:45 - Connecting to Caph (Netherlands, Alblasserdam) . 2023.01.06 13:38:46 - Routes, add 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)". . 2023.01.06 13:38:46 - Routes, add 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)", already exists. . 2023.01.06 13:38:46 - OpenVPN > OpenVPN 2.5.5 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 15 2021 . 2023.01.06 13:38:46 - OpenVPN > Windows version 10.0 (Windows 10 or greater) 64bit . 2023.01.06 13:38:46 - OpenVPN > library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10 . 2023.01.06 13:38:46 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2023.01.06 13:38:46 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2023.01.06 13:38:46 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2023.01.06 13:38:46 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2023.01.06 13:38:46 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET6]2a00:1678:2470:18:5ac5:3314:8260:3523:443 . 2023.01.06 13:38:46 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144] . 2023.01.06 13:38:46 - OpenVPN > UDPv6 link local: (not bound) . 2023.01.06 13:38:46 - OpenVPN > UDPv6 link remote: [AF_INET6]2a00:1678:2470:18:5ac5:3314:8260:3523:443 ! 2023.01.06 13:38:57 - Disconnecting . 2023.01.06 13:38:57 - Sending soft termination signal . 2023.01.06 13:39:00 - OpenVPN > SIGTERM received, sending exit notification to peer . 2023.01.06 13:39:02 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting . 2023.01.06 13:39:03 - Routes, delete 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)". . 2023.01.06 13:39:03 - Routes, delete 2a00:1678:2470:18:5ac5:3314:8260:3523/128 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)", not exists. . 2023.01.06 13:39:03 - Connection terminated. I 2023.01.06 13:39:03 - Cancel requested. ! 2023.01.06 13:39:03 - Session terminated. I 2023.01.06 13:39:05 - Session starting. I 2023.01.06 13:39:05 - Checking authorization ... . 2023.01.06 13:39:06 - Using WinTun network interface "OpenVPN Wintun (Wintun Userspace Tunnel)" ! 2023.01.06 13:39:06 - Connecting to Caph (Netherlands, Alblasserdam) . 2023.01.06 13:39:06 - Routes, add 213.152.162.172/32 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)". . 2023.01.06 13:39:06 - Routes, add 213.152.162.172/32 for interface "Ethernet (Intel(R) Ethernet Connection (7) I219-V)", already exists. . 2023.01.06 13:39:06 - OpenVPN > OpenVPN 2.5.5 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 15 2021 . 2023.01.06 13:39:06 - OpenVPN > Windows version 10.0 (Windows 10 or greater) 64bit . 2023.01.06 13:39:06 - OpenVPN > library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10 . 2023.01.06 13:39:06 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2023.01.06 13:39:06 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2023.01.06 13:39:06 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2023.01.06 13:39:06 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2023.01.06 13:39:06 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]213.152.162.172:443 . 2023.01.06 13:39:06 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144] . 2023.01.06 13:39:06 - OpenVPN > UDP link local: (not bound) . 2023.01.06 13:39:06 - OpenVPN > UDP link remote: [AF_INET]213.152.162.172:443 . 2023.01.06 13:39:06 - OpenVPN > TLS: Initial packet from [AF_INET]213.152.162.172:443, sid=372ea917 90a0d157 . 2023.01.06 13:39:06 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2023.01.06 13:39:06 - OpenVPN > VERIFY KU OK . 2023.01.06 13:39:06 - OpenVPN > Validating certificate extended key usage . 2023.01.06 13:39:06 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2023.01.06 13:39:06 - OpenVPN > VERIFY EKU OK . 2023.01.06 13:39:06 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Caph, emailAddress=info@airvpn.org . 2023.01.06 13:39:06 - OpenVPN > Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 4096 bit RSA, signature: RSA-SHA512 . 2023.01.06 13:39:06 - OpenVPN > [Caph] Peer Connection Initiated with [AF_INET]213.152.162.172:443 . 2023.01.06 13:39:06 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.12.138.1,dhcp-option DNS6 fde6:7a:7d20:88a::1,tun-ipv6,route-gateway 10.12.138.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:88a::10df/64 fde6:7a:7d20:88a::1,ifconfig 10.12.138.225 255.255.255.0,peer-id 1,cipher AES-256-GCM' . 2023.01.06 13:39:06 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2023.01.06 13:39:06 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS 10.12.138.1' . 2023.01.06 13:39:06 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:88a::1' . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: peer-id set . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2023.01.06 13:39:06 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2023.01.06 13:39:06 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2023.01.06 13:39:06 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2023.01.06 13:39:06 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2023.01.06 13:39:06 - OpenVPN > interactive service msg_channel=0 . 2023.01.06 13:39:06 - OpenVPN > open_tun . 2023.01.06 13:39:06 - OpenVPN > wintun device [OpenVPN Wintun] opened . 2023.01.06 13:39:06 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address 9 static 10.12.138.225 255.255.255.0 . 2023.01.06 13:39:07 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ip delete dns 9 all . 2023.01.06 13:39:07 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ip delete wins 9 all . 2023.01.06 13:39:07 - OpenVPN > IPv4 MTU set to 1500 on interface 9 using SetIpInterfaceEntry() . 2023.01.06 13:39:07 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ipv6 set address 9 fde6:7a:7d20:88a::10df/128 store=active . 2023.01.06 13:39:07 - OpenVPN > add_route_ipv6(fde6:7a:7d20:88a::/64 -> fde6:7a:7d20:88a::10df metric 0) dev OpenVPN Wintun . 2023.01.06 13:39:07 - OpenVPN > C:\WINDOWS\system32\netsh.exe interface ipv6 add route fde6:7a:7d20:88a::/64 9 fe80::8 store=active . 2023.01.06 13:39:07 - OpenVPN > env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem . 2023.01.06 13:39:07 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ipv6 delete dns 9 all . 2023.01.06 13:39:07 - OpenVPN > IPv6 MTU set to 1500 on interface 9 using SetIpInterfaceEntry() . 2023.01.06 13:39:07 - OpenVPN > Initialization Sequence Completed . 2023.01.06 13:39:07 - Interface OpenVPN Wintun metric changed from Automatic to 3, layer IPv4 . 2023.01.06 13:39:07 - Interface OpenVPN Wintun metric changed from Automatic to 3, layer IPv6 . 2023.01.06 13:39:07 - DNS leak protection with packet filtering enabled. . 2023.01.06 13:39:07 - DNS IPv4 of a network adapter forced (OpenVPN Wintun, from automatic to 10.12.138.1) . 2023.01.06 13:39:07 - DNS IPv6 of a network adapter forced (OpenVPN Wintun, from automatic to fde6:7a:7d20:88a::1) . 2023.01.06 13:39:07 - DNS IPv4 of a network adapter forced (Ethernet, from automatic to 10.12.138.1) . 2023.01.06 13:39:07 - DNS IPv6 of a network adapter forced (Ethernet, from automatic to fde6:7a:7d20:88a::1) . 2023.01.06 13:39:07 - DNS IPv4 of a network adapter forced (VirtualBox Host-Only Network, from automatic to 10.12.138.1) . 2023.01.06 13:39:07 - DNS IPv6 of a network adapter forced (VirtualBox Host-Only Network, from automatic to fde6:7a:7d20:88a::1) . 2023.01.06 13:39:07 - Routes, add 0.0.0.0/1 for interface "OpenVPN Wintun (Wintun Userspace Tunnel)". . 2023.01.06 13:39:07 - Routes, add 128.0.0.0/1 for interface "OpenVPN Wintun (Wintun Userspace Tunnel)". . 2023.01.06 13:39:07 - Routes, add ::/1 for interface "OpenVPN Wintun (Wintun Userspace Tunnel)". . 2023.01.06 13:39:07 - Routes, add 8000::/1 for interface "OpenVPN Wintun (Wintun Userspace Tunnel)". . 2023.01.06 13:39:08 - Routes, add 213.152.162.170/32 for interface "OpenVPN Wintun (Wintun Userspace Tunnel)". . 2023.01.06 13:39:08 - Routes, add 2a00:1678:2470:18:c954:55da:f018:70ff/128 for interface "OpenVPN Wintun (Wintun Userspace Tunnel)". . 2023.01.06 13:39:08 - Flushing DNS I 2023.01.06 13:39:08 - Checking route IPv4 I 2023.01.06 13:39:11 - Checking route IPv6 I 2023.01.06 13:39:11 - Checking DNS ! 2023.01.06 13:39:12 - Connected.

The service is amazing, it has so many configurable options, for me its a piece of art and I hope all the backbone scripts and configs are safely kept. In Config Generator -> Advanced Mode, when you select entry layer you can only select IPv4 or IPv6. So far so good, but nowadays there are plenty plenty of dual-stacked users, wouldn't it make sense to also have a third button, "Both" that will: a) try in order first IPv6 if available, if not fail back to IPv4 (easily achieved with two `remote` config lines and no `remote random` so they are tried in order. We first try IPv6. b) this can be manually done by any users, easily, but I did not see documentation for our *airdns.org hostname blueprint. example. nl.all.ipv6.vpn.airdns.org does not resolve to any valid IPv6 addresses. I see the *.airdns.org is configured in a sane logic way, as in nl3.vpn for example IP3 entry, and so on, but its not as clear for IPv6. A web page explaining it would be neat, I could do it if I knew the logic. Or is there any reason to keep this information private?

Hi. I kindly ask if someone can help me to solve a couple of problems that I have not found by searching a bit on the forum. My OS is Win 10 Home fully updated. 1- I've set AirVPN to start with the operating system and at the same time connect automatically, but I've noticed that using this setting the OS doesn't shut down and I have to do it manually (the usual Windows message appears warning that is trying to close the program that prevents shutdown but the operation fails). 2 - On all adapters (both wi-fi and ethernet) I keep IPV6 disabled).With the other VPNs I have used in the past (Mullvad and ProtonVPN) I have never had problems, but now - during the connection - I receive continuous notifications (I don't know if from Eddie or from Win) asking me to activate IPV6 on the adapter even if the connection succeeds... after many attempts. 3 - I have enabled the option to activate the Network Lock at startup but the lock in the upper right corner of the GUI remains always unlocked. Is there something wrong with the settings?

I have a computer connected to AirVPN using openvpn. I forwarded a port into the "Client Area configurations" and if I check the port by click on "Test open" I receive "Open!" for both ipv4 and ipv6 protocols: my computer is listening the open port correctly on both IP protocol. If I use another computer connected to internet out of AirVPN and I check the open port using ipv4 protocol: nmap <ipv4_of_AirVPN_device> -sV -Pn -p <port_to_check> -4 I receive "open" but if check using ipv6 protocol: nmap <ipv6_of_AirVPN_device> -sV -Pn -p <port_to_check> -6 I receive "filtered". I also can't use the service listening on that port unless I force the use of the ipv4 protocol. What could be the problem? Why is my ip not correctly forwarded despite the AirVPN check being successful?

Currently AirVPN servers ONLY provide you with IPv6 connectivity (IPv6 traffic via VPN) if OpenVPN correctly pushes a certain value to the server. This is what the relevant config lines look like: push-peer-info setenv UV_IPV6 yes 'UV_IPV6 yes' is a variable that is set to 'yes', basically: yes, gimme IPv6 push-peer-info sends the server information about the client. This includes: OS version and OpenVPN client release, your router's MAC address and of course the UV_IPV6 variable that tells the server to give you an IPv6 address. This last part is problematic and has already led to problems for AirVPN users: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/556 I've run into this issue myself when I tried to get AirVPN running on Linux using the NetworkManager interface (present in virtually every distro out there). It's confusing because it seems to work but in reality it doesn't. You do get a connection, except without IPv6 forwarding. It's no surprise people encounter this: Why would one really need to install your client if the preinstalled GUI manager has worked fine before? Nobody knows the intricacies. Not even those who reported the issue to the correct place above! *drum-roll* and the problem is: NetworkManager. Really. NetworkManager is crippled in that it DOES NOT support many of the OpenVPN features. The combination of push-peer-info + setenv is one of them. The variable is not set upon connection -> VPN connects to the server -> The server does not see UV_IPV6=yes -> The server only setups IPv4 for the client. Yes, THIS IS A SECURITY ISSUE. According to Google, 32% of users have IPv6. Here come you, an AirVPN user with IPv4 and IPv6 on Linux, using NetworkManager. It seems to connect. You quickly check a website to see your IP and see that you indeed got a new IP (IPv4) after connecting to the VPN. Maybe the website doesn't show IPv6 at all, or the user doesn't pay attention to the fact this long and cryptic IPv6 didn't change or maybe the user did not yet have IPv6 and it was enabled later by the ISP... And there the user goes to surf online with half his ass naked: IPv4 is properly routed through AirVPN but IPv6 is still going through his real ISP. This must be changed. IPv6 must be the default. Do not leave a chance to expose users. When this change is applied, both config lines will be rendered obsolete and as a bonus, the clients will no longer unnecessarily send their internal MAC addresses to the server, which can be used too: - https://threatpost.com/fbi-mum-on-how-exactly-it-hacked-tor/117127/ | https://www.theregister.com/2018/02/24/tor_fbi_hacking_appeal/ - https://web.archive.org/web/20180923231303/https://blog.owenson.me/analysis-of-the-fbi-tor-malware/ Finally if you feel there's someone who really wishes to not use IPv6 via Air: reverse the config. Make it an explicit UV_IPV6=no to opt-out. Security must be the default. Thanks for reading. I really hope this change to be introduced soon. PS: Can someone login at the Freedesktop bug tracker above to tell these people that it's fixable? I don't have an account PPS: You can see what push-peer-info sends if you set verbosity to 4: "verb 4" in the config Tags: IPv6 not working AirVPN Linux config openvpn

Hello my friends, on an debian box Im using two vpn IPv6 connections. One for the default route and the other for foreign services via local proxys for my clients. The problem is that if I connect the Split-Traffic-VPN (ignored def/route) first, it reconnects after All-Traffic-VPN is connected b/c of: I tried this config in All-Traffic-VPN like for IPv4 connections but its ignored: route-ipv6 2001:ac8:28:8:c4d0:d13a:3b31:4d fe80::d63f:cbff:fe8a:xxxx How can I prevent the non def/routed IPv6 tunnel to connect through the def/route IPv6 tunnel ? How can I set a static route to my local default gateway fe80::d63f:cbff:fe8a:xxxx ?

Hi, Ive been using Airvpn for a few years now with now real issues. About a week ago had problems with Eddie 2:13:6 and connection dropping out because of "server and updates" failing. Updated yesterday to Eddie 2:15:2 and have similar problems, Eddie will not connect unless I uncheck the "check Airvpn tunnel" in options, had to do this because Eddie kept hanging on checking IPV6 on startup. When it does connect to any server - I have tried a lot of them along with different protocols - the speed drops to zero very quickly and get the "Cannot retrieve systems & servers data" error . 2018.07.09 13:15:16 - Eddie version: 2.15.2 / 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.07.09 13:15:16 - Reading options from C:\Program Files\AirVPN\default.xml . 2018.07.09 13:15:17 - Command line arguments (0): . 2018.07.09 13:15:17 - Profile path: C:\Program Files\AirVPN\default.xml . 2018.07.09 13:15:20 - OpenVPN Driver - TAP-Windows Adapter V9, version 9.21.2 . 2018.07.09 13:15:20 - OpenVPN - Version: 2.4.6 - OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 (C:\Program Files\AirVPN\openvpn.exe) . 2018.07.09 13:15:20 - SSH - Version: plink 0.67 (C:\Program Files\AirVPN\plink.exe) . 2018.07.09 13:15:20 - SSL - Version: stunnel 5.40 (C:\Program Files\AirVPN\stunnel.exe) . 2018.07.09 13:15:20 - curl - Version: 7.54.1 (C:\Program Files\AirVPN\curl.exe) . 2018.07.09 13:15:20 - Certification Authorities: C:\Program Files\AirVPN\res\cacert.pem ! 2018.07.09 13:15:21 - Activation of Network Lock - Windows Filtering Platform . 2018.07.09 13:15:21 - Updating systems & servers data ... I 2018.07.09 13:15:21 - Ready . 2018.07.09 13:15:22 - Systems & servers data update completed I 2018.07.09 13:15:29 - Session starting. I 2018.07.09 13:15:30 - Checking authorization ... ! 2018.07.09 13:15:30 - Connecting to Alathfar (United Kingdom, Maidenhead) . 2018.07.09 13:15:30 - Routes, added a new route, 185.103.96.146 for gateway 192.168.1.254 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[ui]: stunnel 5.40 on x86-pc-mingw32-gnu platform . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[ui]: Compiled/running with OpenSSL 1.0.2k 26 Jan 2017 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[ui]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[ui]: Reading configuration from file C:\Program Files\AirVPN\cb1b90540e7095dd0a0a5d83eae2bfeb2ac25471cf9c04369f2b50cb42ccb2ba.tmp.ssl . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[ui]: UTF-8 byte order mark not detected . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[ui]: Initializing service [openvpn] . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG4[ui]: Service [openvpn] needs authentication to prevent MITM attacks . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[ui]: Configuration successful . 2018.07.09 13:15:31 - OpenVPN > OpenVPN 2.4.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 27 2018 . 2018.07.09 13:15:31 - OpenVPN > Windows version 6.1 (Windows 7) 64bit . 2018.07.09 13:15:31 - OpenVPN > library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 . 2018.07.09 13:15:31 - Connection to OpenVPN Management Interface . 2018.07.09 13:15:31 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2018.07.09 13:15:31 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2018.07.09 13:15:31 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2018.07.09 13:15:31 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2018.07.09 13:15:31 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2018.07.09 13:15:31 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:60783 . 2018.07.09 13:15:31 - OpenVPN > Socket Buffers: R=[8192->262144] S=[8192->262144] . 2018.07.09 13:15:31 - OpenVPN > Attempting to establish TCP connection with [AF_INET]127.0.0.1:60783 [nonblock] . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[0]: Service [openvpn] accepted connection from 127.0.0.1:49333 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: s_connect: connecting 185.103.96.146:443 . 2018.07.09 13:15:31 - OpenVPN > TCP connection established with [AF_INET]127.0.0.1:60783 . 2018.07.09 13:15:31 - OpenVPN > TCP_CLIENT link local: (not bound) . 2018.07.09 13:15:31 - OpenVPN > TCP_CLIENT link remote: [AF_INET]127.0.0.1:60783 . 2018.07.09 13:15:31 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[0]: s_connect: connected 185.103.96.146:443 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG5[0]: Service [openvpn] connected remote server from 192.168.1.81:49335 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: SNI: sending servername: 185.103.96.146 . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: Peer certificate not required . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: Certificate verification disabled . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: Client certificate not requested . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: TLS connected: new session negotiated . 2018.07.09 13:15:31 - SSL > 2018.07.09 13:15:31 LOG6[0]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) . 2018.07.09 13:15:31 - OpenVPN > TLS: Initial packet from [AF_INET]127.0.0.1:60783, sid=b2b90158 7d1916da . 2018.07.09 13:15:31 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2018.07.09 13:15:31 - OpenVPN > VERIFY KU OK . 2018.07.09 13:15:31 - OpenVPN > Validating certificate extended key usage . 2018.07.09 13:15:31 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2018.07.09 13:15:31 - OpenVPN > VERIFY EKU OK . 2018.07.09 13:15:31 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org . 2018.07.09 13:15:32 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2018.07.09 13:15:32 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]127.0.0.1:60783 . 2018.07.09 13:15:33 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) . 2018.07.09 13:15:33 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.5.39.1,dhcp-option DNS6 fde6:7a:7d20:127::1,tun-ipv6,route-gateway 10.5.39.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:127::1000/64 fde6:7a:7d20:127::1,ifconfig 10.5.39.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' . 2018.07.09 13:15:33 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: peer-id set . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1627 . 2018.07.09 13:15:33 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2018.07.09 13:15:33 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2018.07.09 13:15:33 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.07.09 13:15:33 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.07.09 13:15:33 - OpenVPN > interactive service msg_channel=0 . 2018.07.09 13:15:33 - OpenVPN > ROUTE_GATEWAY 192.168.1.254/255.255.255.0 I=11 HWADDR=00:24:8c:3e:fe:f6 . 2018.07.09 13:15:33 - OpenVPN > GDG6: remote_host_ipv6=n/a . 2018.07.09 13:15:33 - OpenVPN > NOTE: GetBestInterfaceEx returned error: Element not found. (code=1168) . 2018.07.09 13:15:33 - OpenVPN > ROUTE6: default_gateway=UNDEF . 2018.07.09 13:15:33 - OpenVPN > open_tun . 2018.07.09 13:15:33 - OpenVPN > TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{854F057F-7592-4A70-90F5-0CB7FD030F92}.tap . 2018.07.09 13:15:33 - OpenVPN > TAP-Windows Driver Version 9.21 . 2018.07.09 13:15:33 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.5.39.0/10.5.39.2/255.255.255.0 [sUCCEEDED] . 2018.07.09 13:15:33 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.5.39.2/255.255.255.0 on interface {854F057F-7592-4A70-90F5-0CB7FD030F92} [DHCP-serv: 10.5.39.254, lease-time: 31536000] . 2018.07.09 13:15:33 - OpenVPN > Successful ARP Flush on interface [12] {854F057F-7592-4A70-90F5-0CB7FD030F92} . 2018.07.09 13:15:33 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=1 . 2018.07.09 13:15:34 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ipv6 set address interface=12 fde6:7a:7d20:127::1000 store=active . 2018.07.09 13:15:35 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ipv6 set dns Local Area Connection 2 static fde6:7a:7d20:127::1 validate=no . 2018.07.09 13:15:36 - Detected an OpenVPN bug (On-Link route on VPN range), autofix. . 2018.07.09 13:15:36 - OpenVPN > add_route_ipv6(fde6:7a:7d20:127::/64 -> fde6:7a:7d20:127::1000 metric 0) dev Local Area Connection 2 . 2018.07.09 13:15:36 - OpenVPN > C:\Windows\system32\netsh.exe interface ipv6 add route fde6:7a:7d20:127::/64 interface=12 fe80::8 store=active . 2018.07.09 13:15:36 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem . 2018.07.09 13:15:41 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up . 2018.07.09 13:15:41 - OpenVPN > C:\Windows\system32\route.exe ADD 127.0.0.1 MASK 255.255.255.255 192.168.1.254 . 2018.07.09 13:15:41 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.07.09 13:15:41 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.07.09 13:15:41 - OpenVPN > C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.5.39.1 . 2018.07.09 13:15:41 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.07.09 13:15:41 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.07.09 13:15:41 - OpenVPN > C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.5.39.1 . 2018.07.09 13:15:41 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4 . 2018.07.09 13:15:41 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2018.07.09 13:15:41 - OpenVPN > add_route_ipv6(::/3 -> fde6:7a:7d20:127::1 metric -1) dev Local Area Connection 2 . 2018.07.09 13:15:41 - OpenVPN > C:\Windows\system32\netsh.exe interface ipv6 add route ::/3 interface=12 fe80::8 store=active . 2018.07.09 13:15:41 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem . 2018.07.09 13:15:41 - OpenVPN > add_route_ipv6(2000::/4 -> fde6:7a:7d20:127::1 metric -1) dev Local Area Connection 2 . 2018.07.09 13:15:41 - OpenVPN > C:\Windows\system32\netsh.exe interface ipv6 add route 2000::/4 interface=12 fe80::8 store=active . 2018.07.09 13:15:41 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem . 2018.07.09 13:15:42 - OpenVPN > add_route_ipv6(3000::/4 -> fde6:7a:7d20:127::1 metric -1) dev Local Area Connection 2 . 2018.07.09 13:15:42 - OpenVPN > C:\Windows\system32\netsh.exe interface ipv6 add route 3000::/4 interface=12 fe80::8 store=active . 2018.07.09 13:15:42 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem . 2018.07.09 13:15:42 - OpenVPN > add_route_ipv6(fc00::/7 -> fde6:7a:7d20:127::1 metric -1) dev Local Area Connection 2 . 2018.07.09 13:15:42 - OpenVPN > C:\Windows\system32\netsh.exe interface ipv6 add route fc00::/7 interface=12 fe80::8 store=active . 2018.07.09 13:15:42 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem . 2018.07.09 13:15:42 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv4 . 2018.07.09 13:15:42 - Interface Local Area Connection 2 metric changed from Automatic to 3, layer IPv6 . 2018.07.09 13:15:42 - DNS leak protection with packet filtering enabled. . 2018.07.09 13:15:43 - DNS IPv4 of a network adapter forced (Local Area Connection 2, from manual (10.50.0.1) to 10.5.39.1) . 2018.07.09 13:15:44 - DNS IPv6 of a network adapter forced (Local Area Connection 2, from automatic to fde6:7a:7d20:127::1) . 2018.07.09 13:15:44 - Routes, added a new route, 185.103.96.143 for gateway 10.5.39.1 . 2018.07.09 13:15:44 - Routes, added a new route, 2a01:a500:320:52a4:c626:3328:bc3c:1a5f for gateway fde6:7a:7d20:127::1 . 2018.07.09 13:15:44 - Flushing DNS I 2018.07.09 13:15:51 - Checking DNS ! 2018.07.09 13:15:52 - Connected. . 2018.07.09 13:15:52 - OpenVPN > Initialization Sequence Completed . 2018.07.09 13:16:31 - SSL > 2018.07.09 13:16:31 LOG6[cron]: Executing cron jobs . 2018.07.09 13:16:31 - SSL > 2018.07.09 13:16:31 LOG6[cron]: Cron jobs completed in 0 seconds . 2018.07.09 13:26:22 - Updating systems & servers data ... . 2018.07.09 13:27:43 - Cannot retrieve systems & servers data. (curl: (28) Connection timed out after 20000 milliseconds) Id be very grateful if anyone could take a look at the log and see whats going on, Thanks.

Hi there, A couple of times I've been torrenting overnight & found in the morning that Eddie was off & my internet was not blocked. Which is cause for concern... So today I upgraded Eddie to 2.18.9 & for the first time installed Hummingbird (I use MX Linux running sysv init). I have IPv6 blocked at the GRUB kernel line (& /etc/hosts for all its worth) & via the Eddie GUI interface as well. I believe that due to IPv6 being blocked I get a Hummingbird warning as follows (taken from the Eddie System Report) when I start Eddie: . 2020.09.21 12:21:54 - Elevated: __Shell, stderr: RTNETLINK answers: Operation not supported W 2020.09.21 12:21:54 - Routes, add 2606:6080:1002:7:def:437f:f6fa:7759 for gateway fde6:7a:7d20:1402::1 failed: Exception: RTNETLINK answers: Operation not supported This error doesn't really bother me, what does, is that the Eddie tray icon remains grey due to this warning (I think that's why, as in my ignorance I can see no other problems when I read the system report). Is there a way to get that tray icon to function properly - display blue when it is connected & grey when not? As I find that to be such a quick visual validation of what is happening with Eddie/Hummingbird. I made a conky script to display my external IP on desktop 1. only. As that is where I want to see it. This is nowhere near as good as the tray icon, as it is only hidden when I watch a video. Thanks for your time.

I just added in IPv6 support on my pfSense box, using AirVPN and a VLAN. Note that I already had the VPN VLAN setup and working correctly with IPv4, so this guide is only about what needed to be changed to add in IPv6 support. Recently, AirVPN has implemented IPv6 across their servers. Provided you are running a recent version of OpenVPN (>= 2.4), and you adjust your client configuration properly, you will be assigned an IPv6 address along with the typical IPv4 address. In my setup, I’m using pfSense as my firewall / router, and have several VLANs configured for various purposes. One of these VLANs is specifically for VPN usage. So the question becomes, how to take the single IPv6 address assigned from AirVPN and make it usable on a VLAN, for multiple hosts. This setup is severely sub-optimal, as IPv6 was designed to avoid NAT (there are what, 3.4x10^38 available addresses?). Given that the design of the protocol and AirVPN’s implementation are at odds, there are some problems that you will encounter. The most annoying being that browsers don’t want to use your IPv6 address, and you will continue to use IPv4, despite having everything setup “correctly.” It may be possible to overcome this with some per-host modifications (on Linux, look to /etc/gai.conf), but that is perhaps not maintainable in the long run. This problem stems from the fact that the address Air is providing is a Unique Local Address (ULA), which, by definition, is not globally routable. This address gets translated at Air’s servers into a normal, globally routable, address. But what the software on your machine sees is a ULA, and since that isn’t a globally routable IP address, the software will prefer the IPv4 address, where it is understood that NAT will probably be used. Given this implementation, I am not convinced it is worth it to setup IPv6 in this type of configuration. Having said all that, here is how I configured things to get IPv6 “working” with AirVPN on a pfSense VLAN: 1: Get an IPv6 address from AirVPN Assuming you are running a recent release of pfSense, you should have the necessary OpenVPN version for this to work (I’m on pfSense 2.4.4, which is using OpenVPN 2.4.6). Go into your OpenVPN client configuration and set “Protocol” to “UDP IPv4 and IPv6 on all interfaces (multihome)” scroll down to “Custom options” and make sure you have these 2 lines: push-peer-info; setenv UV_IPV6 yes; Save, and possibly restart the service. You should now have both IPv4 and IPv6 addresses assigned to your VPN connection 2: Create a new Gateway I can’t remember if the gateway was automatically created at this point. If not, Add a new gateway. If one was auto created, edit it. Then Make sure Interface is set to the VPN Address family is IPv6 Give it a name (VPN1_WAN_IPv6 in my case) I’ve left everything else at default settings, then set a description, and Save and reload 3: Modify your VPN VLAN From the “Interfaces” menu, select your VPN VLAN entry, then Set “IPv6 Configuration Type” to “Static IPv6” Scroll down to the “Static IPv6 Configuration” section and set an address and prefix. I chose a “random” ULA (FDxx:xxxx:xxxx:10::1). Obviously, choose hex characters in place of the “x”s and the “10” matches my vlan number. Set the prefix to /64 Leave the “use IPv4 connectivity” unchecked and the gateway set to “None” Save and reload 4: Configure Router Advertisements and/or DHCPv6 From the “Services” menu, select “DHCPv6 Server & RA” - then choose your VLAN. In my setup, I’m not bothering with DHCP, just using SLACC, so I go directly to the “Router Advertisements” tab. Set Router Mode to unmanaged Priority to Normal You may choose to put your IPv6 DNS server into the DNS configuration section (I believe Air’s server is fde6:7a:7d20:4::1 Leave everything else as is (blank) Save and reload 5: Set NAT Rules From the “Firewall” menu, select “NAT”, then go to the “Outbound” tab Click the second “Add” button Set “Interface” to your VPN gateway “Address Family” is “IPv6” Source type is “network” Source network is the ULA you setup earlier (“Fdxx:xxxx:xxxx:10::/64”) I did this using an alias. Note that the subnet drop down doesn’t list anything above a /32 (it’s meant for IPv4), so I left it at /32. Seems to work anyway. The Translation Address should be set to “Interface Address” Add in a description, if you wish, and Save and reload 6: Set Firewall Rules From the “Firewall” menu, select “Rules” and then the appropriate VLAN tab Click the second “Add” button “Action” is “Pass” “Interface” is your VLAN “Address Family” is “IPv6” Set the rules appropriately for your situation. In my case, just to get things working, I set “Protocol” to “Any” “Source” to “[VLAN] net” Click the “Display Advanced” button Scroll down to “Gateway” and select your previously configured VPN IPv6 gateway Save and reload NOTE: Be sure to move the rule you just created into the correct spot in your rules list! Remember, the rules are checked in order, so if you have a deny rule above your new pass rule in the list, it won’t work. At this point I rebooted pfSense and my VPN client machine. I now have an IPv6 address, assigned from the ULA block I setup. Visiting https://ipleak.net shows I have both IPv4 and IPv6 connectivity. Going to https://test-ipv6.com gives me a 10/10, but with the note that the browser is avoiding using the IPv6 address. See the note from AirVPN Staff about this: https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/ Hopefully this is helpful to someone out there. MrFricken

Hello, recently started up the Eddie-ui trying to connect to a Canadian Server and noticed my client keeps showing the IPv6 can't connect and just fails and retries a few times. Don't really have any idea of what has changed since I last used it, but maybe someone can find something in my logs? Eddie_20200420_093730.txt

Hi all, I use Network Manager to configure my VPN with Linux, I generated the configuration with "Config Generator" and I imported it into the VPN section of Network Manager but if i check my ip on ipleak.net only IPv4 is under AirVPN. Is there a solution of this problem? Thanks to all,

As the title states, I cannot connect to any servers using Eddie UI on Windows 10. This wasn't an issue till a week ago, where all of a sudden I started taking 3-4 minutes to connect to an AirVPN server or not being able to connect to any AirVPN server. Usually, I keep getting stuck at "Checking route IPv4" or "Checking route IPv6" or at worst case "Checking DNS". Even if I do manage to connect, I don't have an internet connection; I cannot connect to Google, Speedtest, Twitter etc. My best bet (and worst-case scenario here) is that the Turkish government has finally imposed blocks on AirVPN as they did with other VPN services like ProtonVPN, NordVPN, CyberGhost, PIA, etc. but I cannot confirm that. This is an exemplary connection attempt I've made prior to writing this: Regardless, can someone help me diagnose and perhaps fix this? Thanks in advance. Eddie_20200104_012349.txt

I use Ubuntu 16.04.5 with ipv6.disable=1 in my grub file. I have OpenVPN version 2.4 installed. I generated ovpn config files for all TLS 1.2 primary servers (entry point 3) UDP 443 with the following options: IPv4 only Resolve hostnames Separate keys / certs Then to connect I only ever run openvpn in terminal selecting one of the ovpn files pretty much at random but lately most of them generate the following and fail to connect. It looks as if they're trying to force an ipv6 connection? I don't want to use ipv6 as it's harder to lock down and I make sure to select IPv4 ONLY in the config generator. Wed Dec 4 04:36:47 2019 OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 31 2019 Wed Dec 4 04:36:47 2019 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Wed Dec 4 04:36:47 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Wed Dec 4 04:36:47 2019 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Wed Dec 4 04:36:47 2019 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Dec 4 04:36:47 2019 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Wed Dec 4 04:36:47 2019 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Dec 4 04:36:47 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]184.75.223.213:443 Wed Dec 4 04:36:47 2019 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed Dec 4 04:36:47 2019 UDP link local: (not bound) Wed Dec 4 04:36:47 2019 UDP link remote: [AF_INET]184.75.223.213:443 Wed Dec 4 04:36:47 2019 TLS: Initial packet from [AF_INET]184.75.223.213:443, sid=4dfd5b1f 47dea206 Wed Dec 4 04:36:47 2019 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org Wed Dec 4 04:36:47 2019 VERIFY KU OK Wed Dec 4 04:36:47 2019 Validating certificate extended key usage Wed Dec 4 04:36:47 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Wed Dec 4 04:36:47 2019 VERIFY EKU OK Wed Dec 4 04:36:47 2019 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Agena, emailAddress=info@airvpn.org Wed Dec 4 04:36:48 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Wed Dec 4 04:36:48 2019 [Agena] Peer Connection Initiated with [AF_INET]184.75.223.213:443 Wed Dec 4 04:36:49 2019 SENT CONTROL [Agena]: 'PUSH_REQUEST' (status=1) Wed Dec 4 04:36:49 2019 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.4.210.1,dhcp-option DNS6 fde6:7a:7d20:d2::1,tun-ipv6,route-gateway 10.4.210.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:d2::1073/64 fde6:7a:7d20:d2::1,ifconfig 10.4.210.117 255.255.255.0,peer-id 2,cipher AES-256-GCM' Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: timers and/or timeouts modified Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: compression parms modified Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: --ifconfig/up options modified Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: route options modified Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: route-related options modified Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: peer-id set Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: adjusting link_mtu to 1625 Wed Dec 4 04:36:49 2019 OPTIONS IMPORT: data channel crypto options modified Wed Dec 4 04:36:49 2019 Data Channel: using negotiated cipher 'AES-256-GCM' Wed Dec 4 04:36:49 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Dec 4 04:36:49 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Dec 4 04:36:49 2019 ROUTE_GATEWAY 10.1.1.1/255.255.255.0 IFACE=eno1 HWADDR=2c:27:d7:1e:2f:56 Wed Dec 4 04:36:49 2019 GDG6: remote_host_ipv6=n/a Wed Dec 4 04:36:49 2019 GDG6: NLMSG_ERROR: error Operation not supported Wed Dec 4 04:36:49 2019 ROUTE6: default_gateway=UNDEF Wed Dec 4 04:36:49 2019 TUN/TAP device tun0 opened Wed Dec 4 04:36:49 2019 TUN/TAP TX queue length set to 100 Wed Dec 4 04:36:49 2019 /sbin/ip link set dev tun0 up mtu 1500 Wed Dec 4 04:36:49 2019 /sbin/ip addr add dev tun0 10.4.210.117/24 broadcast 10.4.210.255 Wed Dec 4 04:36:49 2019 /sbin/ip -6 addr add fde6:7a:7d20:d2::1073/64 dev tun0 RTNETLINK answers: Operation not supported Wed Dec 4 04:36:49 2019 Linux ip -6 addr add failed: external program exited with error status: 2 Wed Dec 4 04:36:49 2019 Exiting due to fatal error

Hello, I am having technical problems with my current IPv6 setup. Specifically, when I try to access websites that report my IP (such as whatismyipaddress.com), they report only detecting an IPv4 address (specifically 185.9.19.107, which is an AirVPN server I believe) from my browser's request when I'm connected with my airvpn configuration, no IPv6 address visible to them. This is strange, specifically because my airvpn configuration is setup to use both IPv6 as the outbound address as well as the inbound one. So my question is, why is this happening? I'm assuming this is a configuration issue on my side. Further context below: 1) All the devices in my house are connected in a LAN that has a single gateway to the public internet: a wireless router with OpenWrt 18.06.2 2) The OpenWrt router is the one maintaining an open connection to the AirVPN server. Basically, the devices in my LAN should have all their network traffic routed through AirVPN servers before reaching their intended destinations. 3) OpenVPN has the airvpn.conf file generated using this website's config generator after selecting the "Linux" category (maybe "Router" would have been a better choice for the configuration file?). The conf file is attached to this thread (the same conf file also contains the certificates, openvpn static key and my private key but I omitted them since I don't believe they are relevant here). airvpn.conf 4) Here are other configurations from my OpenWRT setup: networkfirewall 5) I should probably point out that my internet didn't work at all when using the VPN with the initial airvpn config file (not even pinging the remote server by its Ipv6 address). After digging a lot through the internet I eventually came up with a script called remote_host_route6.sh which I reference in my airvpn config file and which gets executed every time openvpn tries to start the said configuration (it's referenced in the "route-up" directive in the airvpn.conf file attached). It was only after I added this script to the configuration that I began having internet at all when the VPN connection was up, albeit with the problem I'm describing in this post. The contents of this remote_host_route6 script are the following: remote_host_route6.sh 6) OpenVPN version is OpenVPN 2.4.5 7) Finally, although I am unsure how relevant this is, my "gateway" router that all my LAN devices connect to and which connects to the VPN server is itself behind an OTN device from my ISP which converts all traffic to fiber optic signal. This device is set into bridge mode and should be transparent to the network though, I believe (hence why my OpenVPN router handles the pppoe configuration). Sorry for the long post :(

Hello, when I try to connect to two of three closest servers to me, I receive an error, and the connection disconnects. I can successfully connect to Aquila, but NOT to Persei or Heze. Connections to most other servers are fine. The error I receive is attached as a screenshot. I'm also attaching the log for an attempted connection to Persei. How do I fix this? I presume it's a setting issue within Eddie? Thanks! log.txt

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've just installed Eddie 2.16.3 on a new Windows 10 system. When Network Lock is active, I can't seem to get Eddie to connect to any of the servers because it gets stuck at "Checking route IPv6" and the connection keeps timing out. I have put exceptions in both Malwarebytes and Windows Firewall for all components used by Eddie including the OpenVPN Daemon but it still refuses to connect when Network Lock has been activated. It works fine otherwise, but it is annoying since Network Lock is a useful feature for preventing DNS leaks. I have attached a log file to see if anyone can help me figure out what's causing the problem. Bizarrely this problem is not present in earlier builds of Eddie such as 2.14.5, which I don't want to use for security reasons. I am using Windows 10 Home, Version 1803, OS build 17134.345. I hope this information is sufficient to help resolve the issue. Eddie_20181011_131408.txt

. 2019.01.30 14:37:29 - Eddie version: 2.17.2 / windows_x64, System: Windows, Name: Windows 10 Pro, Version: Microsoft Windows NT 10.0.17763.0, Mono/.Net: v4.0.30319 . 2019.01.30 14:37:29 - Reading options from C:\Users\tharr\AppData\Local\AirVPN\default.xml . 2019.01.30 14:37:29 - Command line arguments (1): path="home" . 2019.01.30 14:37:29 - Profile path: C:\Users\tharr\AppData\Local\AirVPN\default.xml . 2019.01.30 14:37:31 - OpenVPN Driver - TAP-Windows Adapter V9, version 9.21.2 . 2019.01.30 14:37:31 - OpenVPN - Version: 2.4.6 - OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 (C:\Program Files\AirVPN\openvpn.exe) . 2019.01.30 14:37:31 - SSH - Version: plink 0.67 (C:\Program Files\AirVPN\plink.exe) . 2019.01.30 14:37:31 - SSL - Version: stunnel 5.40 (C:\Program Files\AirVPN\stunnel.exe) . 2019.01.30 14:37:31 - curl - Version: 7.54.1 (C:\Program Files\AirVPN\curl.exe) . 2019.01.30 14:37:31 - Certification Authorities: C:\Program Files\AirVPN\res\cacert.pem I 2019.01.30 14:37:32 - Ready . 2019.01.30 14:37:36 - Cannot retrieve information about AirVPN: Length of the data to decrypt is invalid. - Status: HTTP/1.1 100 Continue - Headers: - Body (127875 bytes): HTTP/1.1 200 OK . 2019.01.30 14:37:36 - Server: nginx . 2019.01.30 14:37:36 - Date: Wed, 30 Jan 2019 20:37:32 GMT . 2019.01.30 14:37:36 - Content-Type: application/octet-stream . 2019.01.30 14:37:36 - Content-Length: 127376 . 2019.01.30 14:37:36 - Connection: keep-alive . 2019.01.30 14:37:36 - Pragma: no-cache . 2019.01.30 14:37:36 - Expires: 0 . 2019.01.30 14:37:36 - Cache-Control: max-age=0, no-cache, no-store, must-revalidate . 2019.01.30 14:37:36 - x-air-bk: 1 . 2019.01.30 14:37:36 - x-air-cache: 0 . 2019.01.30 14:37:36 - X-Frame-Options: SAMEORIGIN . 2019.01.30 14:37:36 - X-XSS-Protection: 1; mode=block . 2019.01.30 14:37:36 - X-Content-Type-Options: nosniff . 2019.01.30 14:37:36 - Referrer-Policy: strict-origin-when-cross-origin . 2019.01.30 14:37:36 - Strict-Transport-Security: max-age=31536000; includeSubdomains; preload . 2019.01.30 14:37:36 - wSX<X7??????~?\5?(???????~UTh9????v??Q???|??4??BpE?

Hello! I'm facing a strange issue regarding IPv6. On the same machine (macOS Mojave) with latest Eddie client and IPv6, enabled some browser do work with IPv6 (Chromium based) and others - Safari & Firefox - do not. I tested with IPleak.net and other IPv6 tests online. I also reset both browsers and disabled all extension/plugins to see if any of them would interfere maybe. Still no love for IPv6. What could be causing this? Is this to be expected? Am I missing something? Thank you for your help!

When trying to add a .ovpn to Gnome network manger with ipv6 enabled (Linux | >=2.4 | UDP 53 Entry 2 | IPv4 & IPv6 (connect with IPv6) | continent > America) It gives the error seen in the Attached file The VPN Plugin failed to import the VPN connection correctly configuration error: invalid 1th argument to 'proto' (line 23) With line 23 being proto udp6 OS Info System: Kernel: 4.19.7-103.current x86_64 bits: 64 compiler: gcc v: 8.2.0 Desktop: Budgie 10.4-85-g36667bcb Distro: Solus 3.9999 Is this something wrong with the Config Generator or should I contact Solus support and try to debug there

Does Android 9 (Pie) fully support IPv6? I'm wondering because I'm not sure which options to choose in AirVPN's Config Generator. Should I choose "IPv4 only," "IPv4 & IPv6 (connect with IPv4)," or "IPv4 & IPv6 (connect with IPv6)?" Right now, I'm using an AirVPN configuration with just IPv4. But, I'm wondering if one of the IPV6 options might be a better choice.

I use Windows 10 Pro and every time I connect using Eddie I saw the following "toast" warning: The Wi-Fi properties had IPv6 enabled: ... so I was puzzled why I am getting this warning repeatedly. According to the following reference I had 0xff set in ...\Tcpip6\Parameters\DisabledComponents: https://support.microsoft.com/en-us/help/929852/guidance-for-configuring-ipv6-in-windows-for-advanced-users Initially I tried 0xfe, and after a reboot the warning was still there when Eddie connects to a server. I then set 0x20 (as recommended by Microsoft) and now the warning no longer appears. Please be aware that changes to the registry need to be done with great care and I advise a manual key backup as well as creating a System Restore Point. You are responsible for all eventualities.

Hello, This has been asked in quite a few places already but there is no clear answer as far as I can tell. Long story short, if you ISP provides you with both IPv4 and IPv6 addresses, then by connecting to AirVPN VPN only the IPv4 traffic is being routed through the tunnel. If a website (or any other remote endpoint) runs on IPv6, then your real IPv6 (the one provided to you by your ISP) will be used and so you end up with an IP leak. Not good. The easiest choice is to disable IPv6 per host basis or use some iptables or other firewall magic to filter out all the IPv6 traffic. This is only a workaround and a very inconvenient one especially when you run AirVPN on a router. The best solution would be for AirVPN to provide a dual stack IPv4/IPv6 tunnel so connected clients can reach the modern IPv6 world privately and securely in a similar fashion to IPv4. Are there any plans to support this option? As far as I can see there are only a handful of VPN providers out there which actually provide dual stack VPNs so it would be nice for AirVPN join this effort.

heyhey, i'm having trouble setting up a ipv6 vpn connection with the (manjaro/arch) linux "network-manager". when i want to set up a ipv4 connection, i go to the "client area" on airvpn.org, start the "config generator", check "advanced" an then set: OS: LinuxOpenVPN version >= 2.4Need IPv6?: "IPv4 only"Protocol: UDP | Port: 443 | Entry IP: 1In the advanced section i check "Separate keys/certs from .ovpn file" and "Resolved hosts in .ovpn file"Server: xxxi then generate the config and download all the files into a new/empty folder. afterwards i start the network-manager connection editors gui ($ nm-connection-editor), click the "+" button, select "import a saved vpn configuration", click "create", navigate to the folder with the config and key files, select the "xxx.ovpn" file and then just click "save", since the nm-connection-editor automatically sets up the right key files etc. in this case everything works as expected. HOWEVER if i try to do the same with a IPv6 config file ("Need IPv6?" set to "IPv4 & IPv6 (connect with IPv6)" - all other settings the same) i get an error when trying to "import a saved vpn configuration" with the nm-connection-editor. when i open the "xxx.ovpn" file with a text editor and change the line "proto udp6" (this is the line before "tls-auth 'ta.key' 1") to "proto udp", i can import without the error message however the connection is not working afterwards. do you have any ideas what i could do different? should i set up the connection manually? thanks in advance!

Since yesterday I cannot connect to the AirVPN servers using the Eddie client anymore. It used to work just fine, but now when I try to connect to a recommended server, it will flush the DNS, check IPv4 routes and finally check IPv6 routes and then the connection is cancelled. I get a pop-up message (notification) saying "Checking route IPv6 failed" and then I am disconnected. Eddie automatically tries to reconnect to the next server then, but that also failed. I have waited for about 5 retries, and also tried manually selecting servers from different countries. Still I cannot connect. I just updated my Eddie client to version 2.16.3. My OS is Linux Mint 18. I am now connected using openvpn from the command line: sudo openvpn AirVPN_UDP-443.ovpn still works. Any idea how I can get the Eddie client to connect again? Any help would be appreciated, thanks in advance! Also, please let me know if I can provide more information that you might need to help.