Jump to content
Not connected, Your IP: 34.239.158.223

Search the Community

Showing results for tags 'dns'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • AirVPN
    • News and Announcement
    • How-To
    • Databases
  • Community
    • General & Suggestions
    • Troubleshooting and Problems
    • Blocked websites warning
    • Eddie - AirVPN Client
    • DNS Lists
    • Reviews
    • Other VPN competitors or features
    • Nonprofit
    • Off-Topic
  • Other Projects
    • IP Leak
    • XMPP

Product Groups

  • AirVPN Access
  • Coupons
  • Misc

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Twitter


Mastodon


AIM


MSN


ICQ


Yahoo


XMPP / Jabber


Skype


Location


Interests

Found 190 results

  1. 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.
  2. i'm currently using airVPN and i'm getting a DNS leak as per ipleak.net . i've tried the netherlands and german servers. I tried ipleak using IPVanish and no leaks. It's worth mentioning i forwarded 1 port on air VPN to allow transmission torrent client to use thta port. I'm on pi OS on a raspberry pi 5. is there some guide a novice could follow for setting static IP and DNS on pi OS?
  3. I thought I'd share some links I've found to check for DNS leaks: http://www.dnsleaktest.com http://ipleak.net/ If you see your real IP or another IP (other than the one that you are connected to by VPN) then you have a DNS leak. You should fix it by setting static IP and DNS server settings on your network adapter. I've written a step-by-step guide for people unfamiliar with network and IP settings. Instructions on how to make your IP settings static for Windows 7: You might be asked to elevate system priviledges or authenticate as Admin while you perform these steps, just allow it all. Click on the network icon on the taskbar (the lower right screen near the clock) -> Click on "Network and sharing center" -> Click on "Change adapter settings" on the menu to the left. You need to know your router's network settings before you continue: Right click on your network adapter (Local area connection if you're connected by a LAN cable or Wireless network connection if WiFi) and choose "Status" -> Click on "Details...". There you should notice your "IPv4 Address", "IPv4 Subnet Mask", "IPv4 Default Gateway" and "IPv4 DNS Server". Click "Close" and again "Close". Right click on your network adapter and choose "Properties" -> Click on "Internet Protocol Version 4" (don't un-check it) and click "Properties". Select the "Use the following IP address" button. IP address: When you noticed your "IPv4 Address" in the "Details" screen earler, it might have looked like this: 192.168.0.1 or 192.168.1.1. This was an IP address assigned by the DHCP pool on your router and happens automatically. You might think to put in the same IP address as you saw in the "Details" window but if you do that, the IP address might be assigned to another computer while your computer is turned off. You should choose an IP address that's much higher than your current IP address so it will be unlikely that another computer will get the same IP address from the DHCP pool. When you put in the "IP address" on the "Properties" screen, you should put in the same first three numbers (e.g. 192.168.0.) and then the last number should be a random number between 100 and 250. It doesn't really matter what number you choose, you are just choosing a number that should be unused on your local LAN. If you get an error about an "IP address conflict", you should choose another last number in the IP address. Subnet mask: Copy the "IPv4 Subnet Mask" from earlier. Default gateway: Copy the "IPv4 Default Gateway" from earlier. This is the IP address of your router. Preferred DNS server: Put in "10.4.0.1". This is AirVPN's DNS server. Alternate DNS server: Put in "10.5.0.1". AirVPN's DNS server. What you have done here is tell Windows to only use AirVPN's DNS servers instead of your routers (or ISP's) DNS servers. If you are not connected to an AirVPN server, you cannot go to the internet unless you put in your normal DNS server settings that you should have noticed in the "Details" screen before (IPv4 DNS Server above). You can also put AirVPN's website IP address in your "Hosts" file. This means that you can get to Airvpn.org to download a config without constantly changing your DNS server settings. Here's how you do it: Open notepad.exe as Admin (Right click -> Run as Administrator). Go to File -> Open. You need to navigate to this folder: "C:\Windows\System32\drivers\etc" and it might involve changing folder settings ("Organize" -> "Folder and search options") to show hidden files (View -> Show hidden files). The folder might appear to be empty but change the document type from "Text Document" to "All files" and then open the file called "hosts". Put in this lines at the bottom: 95.211.138.143 airvpn.org Then save the file as "hosts" and overwrite the old one. If you didn't run notepad.exe as Admin then you can't save the file. Hopefully this guide will help people. If there are any questions, just ask!
  4. last Thursday (31st of August), I installed hummingbird on a mini-PC with Ubuntu 23.04 as described on the download page. Using the generated OVPN file as argument, I started hummingbird successfully. And according to ipleak.net, everything looked fine. After a couple of hours, I noticed that hummingbird kept trying to reconnect. I stopped hummingbird, and at first glance, there was not network connection. It was late, so I shut the PC down. The next day, I booted the mini-PC and noticed that DNS was broken. I could ping the router, ping the other PC connected to the router, but there was no name resolution. It appears I can ping an IP address like 5.196.64.52, but not www.airvpn.org. At this point, I must admit my understanding of DNS resolution on Ubuntu is very limited. I don't know how to proceed to diagnose and solve the problem. My initial thought was that hummingbird did not shut down properly and left the system in a state where DNS is broken... except I don't know if that is even possible. Could you point me to a resource with the steps to follow for addressing the problem? What do I need to look at, in what order? Do I need to disable something? Enable something? Reinstall something?
  5. Does anyone know how to get this to work? I want to be able to route *.<my-ddns-name>.airdns.org:<open_port> to my <vpn_ip>:<local_port> and then route that to the correct service in my reverse proxy
  6. So Eddie is not working with Adguard anymore. Earlier I did not have this issue. I try to turn off different programs, like a firewall, but Eddie started working olny after I turn off Adguard. I'm also using Adguard DNS, but it's fine, when AdGuard is turn off. Do you know solution to my problem? I would like to use those two programs in the same time.
  7. EDIT: Figured it out. I was under the assumption that systemd-resolved took over all DNS processing and made /etc/resolv.conf obsolete, but apparently that's still where AirVPN pushes the DNS settings too and somehow systemd-resolved overwrites it. Disabling systemd-resolved seems to have fixed this problem for now. Running AirVPNsuite on my server (Operating System: Debian GNU/Linux 11 (bullseye); Kernel: Linux 5.10.0-20-amd64), DNS breaks randomly 5-60mins after establishing connection. DNS settings, as far as I can tell, aren't being changed. I can still ping the server-pushed DNS server as well, but it just doesn't resolve. Relevant logs below: Logs immediately after establishing connection: root@labserver:~# resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: foreign Current DNS Server: 10.32.178.1 DNS Servers: 10.32.178.1 Link 2 (enp0s25) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.32.178.1 Link 3 (docker0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.32.178.1 Link 4 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.32.178.1 root@labserver:~# goldcrest --bluetit-status 2023-03-02 22:47:43 Reading run control directives from file /root/.config/goldcrest.rc Goldcrest 1.2.1 - 9 December 2022 2023-03-02 22:47:43 Bluetit - AirVPN OpenVPN 3 Service 1.2.1 - 9 December 2022 2023-03-02 22:47:43 OpenVPN core 3.8.2 AirVPN linux x86_64 64-bit 2023-03-02 22:47:43 Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved. 2023-03-02 22:47:43 OpenSSL 1.1.1n 15 Mar 2022 2023-03-02 22:47:43 Bluetit is connected to VPN 2023-03-02 22:47:43 Persistent Network Lock and Filter is enabled. (using nftables) 2023-03-02 22:47:43 ---------------------- 2023-03-02 22:47:43 Connected to AirVPN server Yildun (Miami, United States of America) 2023-03-02 22:47:43 Users 50 - Load 8% - Bandwidth 80.08 Mbit/s - Max 1 Gbit/s 2023-03-02 22:47:43 Server IP Address 173.44.55.181 - Port 443 - Protocol UDPv4 - Cipher AES-256-GCM 2023-03-02 22:47:43 Network topology: subnet - Server ping 10 s - Ping restart 60 s 2023-03-02 22:47:43 Pushed DNS: 10.32.178.1 (IPv4) 2023-03-02 22:47:43 Connection time: 00:02:25 2023-03-02 22:47:43 Transferred data: In 34.09 KB, Out 9.15 KB 2023-03-02 22:47:43 Current rate: In 0 bit/s, Out 0 bit/s 2023-03-02 22:47:43 Maximum rate: In 14.78 Kbit/s, Out 1.09 Kbit/s root@labserver:~# ping google.com PING google.com (142.250.217.206) 56(84) bytes of data. 64 bytes from mia07s61-in-f14.1e100.net (142.250.217.206): icmp_seq=1 ttl=120 time=72.3 ms 64 bytes from mia07s61-in-f14.1e100.net (142.250.217.206): icmp_seq=2 ttl=120 time=72.3 ms 64 bytes from mia07s61-in-f14.1e100.net (142.250.217.206): icmp_seq=3 ttl=120 time=72.5 ms Logs ~1 hour later when DNS has failed: root@labserver:~# resolvectl Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: foreign Current DNS Server: 10.32.178.1 DNS Servers: 10.32.178.1 Link 2 (enp0s25) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.32.178.1 Link 3 (docker0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.32.178.1 Link 4 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 10.32.178.1 root@labserver:~# goldcrest --bluetit-status 2023-03-02 23:56:38 Reading run control directives from file /root/.config/goldcrest.rc Goldcrest 1.2.1 - 9 December 2022 2023-03-02 23:56:38 Bluetit - AirVPN OpenVPN 3 Service 1.2.1 - 9 December 2022 2023-03-02 23:56:38 OpenVPN core 3.8.2 AirVPN linux x86_64 64-bit 2023-03-02 23:56:38 Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved. 2023-03-02 23:56:38 OpenSSL 1.1.1n 15 Mar 2022 2023-03-02 23:56:38 Bluetit is connected to VPN 2023-03-02 23:56:38 Persistent Network Lock and Filter is enabled. (using nftables) 2023-03-02 23:56:39 ---------------------- 2023-03-02 23:56:39 Connected to AirVPN server Yildun (Miami, United States of America) 2023-03-02 23:56:39 Users 50 - Load 4% - Bandwidth 48.70 Mbit/s - Max 1 Gbit/s 2023-03-02 23:56:39 Server IP Address 173.44.55.181 - Port 443 - Protocol UDPv4 - Cipher AES-256-GCM 2023-03-02 23:56:39 Network topology: subnet - Server ping 10 s - Ping restart 60 s 2023-03-02 23:56:39 Pushed DNS: 10.32.178.1 (IPv4) 2023-03-02 23:56:39 Connection time: 01:11:19 2023-03-02 23:56:39 Transferred data: In 627.65 KB, Out 107.48 KB 2023-03-02 23:56:39 Current rate: In 20 bit/s, Out 0 bit/s 2023-03-02 23:56:39 Maximum rate: In 65.65 Kbit/s, Out 3.59 Kbit/s root@labserver:~# ping google.com ping: google.com: Temporary failure in name resolution root@labserver:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=72.3 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=72.3 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=72.3 ms root@labserver:~# dig google.com ; <<>> DiG 9.16.33-Debian <<>> google.com ;; global options: +cmd ;; connection timed out; no servers could be reached
  8. Hello everyone, I have got a problem with connecting to my service via <name>.airdns.org:<open port>. I can connect to the service via entering airvpn ip:<open port> address. I have tried two independent internet connections, not sure but seems that domain cannot be resolved to ip address for me for some reason. From the AirVPN DNS test, I can see that correct IP is recorded for <name>.airdns.org. Can anyone recommend some further troubleshooting steps?
  9. Hi there, Long time hassle-free AirVPN user with a first troubleshooting request after switching from Eddie-UI to the Bluetit stack (love your work!) Looks as though the two processes are fighting for `/etc/resolv.conf` and causing issues with DNS. NetworkManager will rewrite the file on a Wi-Fi network change, causing loss of connectivity as local DNS is disallowed by the network lock. Can be worked around by stopping the Bluetit service, toggling Wi-Fi, then re-enabling; but this is tedious to repeat if the network is at marginal signal strength. Is there a way to configure NetworkManager not to mess with DNS? I think that would largely resolve the issue. But, in an ideal world I would be able to have NetworkManager still manage the DNS if Bluetit is not active so that I can still operate normally on local networks without routing through AirVPN if I choose to. Seems unlikely to be simple, but worth asking. Given that I am getting two warnings about DNS, I wonder if `systemd-resolved` could also be interfering and if there are other configuration steps I can take to ensure compatibility with it- ``` bluetit: WARNING: NetworkManager is running on this system and may interfere with DNS management and cause DNS leaks bluetit: WARNING: systemd-resolved is running on this system and may interfere with DNS management and cause DNS leaks ``` I also wonder whether use of Goldcrest could avoid some of these problems. Personally I have not understood the need for the utility and have been interacting with Bluetit directly via systemctl and `/etc/airvpn/bluetit.rc`. As far as I can tell, Goldcrest just moves configuration stuff out of the `.rc` file into CLI args?
  10. As the title says i can't resolve any domains when i'm connected to airvpn servers via wireguard. It worked fine a few weeks ago, and open vpn works fine too. I tried an other vpn service with wireguard, and it didn't had any problem, so i think this might be a configuration problem on the config generator's part.
  11. I currently use Jackett for torrent searching + Tixati as my torrent client. A feature in Jackett lets you create your own custom RSS Filters for the torrent sites you have added. This is great for me as it will automatically download whatever I have configured. But every time I disconnect and reconnect servers, the Local IP changes, and then I must reconfigure the RSS IP again. Jackett lets you override the Base URL + path, can I somehow do configure this to work with Dynamic DNS? I have Dynamic DNS configured correctly (All DNS servers are green) but when I set it as the RSS URL it does not work. Jackett also listens on the local IP address 0.0.0.0 but I don't think you can change the Jackett IP If anyone can help me with problem that would be great. Thank you!
  12. Quality of Service post: Although it is a 10Gbit server it seems to be suffering. I'm from Europe and checking its ping shows average 344ms over 234 attempts. This puts it in range of JP and NZ servers at 350ms. This is not the first time I've seen it perform poorly. Last week I connected to se.vpn.airdns.org (and it still shows as the preferred choice in API and https://airvpn.org/status/ EDIT: not any longer as of finishing writing) and had the same problems downloading a file with speed jumping up and down. To get the ping results I filtered the API JSON into an IP list to use with Nirsoft PingInfoView: https://www.nirsoft.net/utils/multiple_ping_tool.html Current IP list: (if you read this post at a later date: it is not up to date!) sortscript.sh | sort -k2 185.9.19.106 at, Alderamin (Austria, Vienna; 1000) 37.120.155.178 at, Beemim (Austria, Vienna; 1000) 217.64.127.194 at, Caelum (Austria, Vienna; 1000) 194.187.251.90 be, Capricornus (Belgium, Brussels; 1000) 91.207.57.114 be, Castor (Belgium, Brussels; 1000) 194.187.251.114 be, Columba (Belgium, Brussels; 1000) 194.187.251.162 be, Diadema (Belgium, Brussels; 1000) 194.187.251.154 be, Mebsuta (Belgium, Brussels; 1000) 82.102.23.130 bg, Apus (Bulgaria, Sofia; 1000) 82.102.23.138 bg, Grus (Bulgaria, Sofia; 1000) 45.162.229.146 br, Lalande (Brazil, Sao Paulo; 1000) 45.162.228.170 br, Peony (Brazil, Sao Paulo; 1000) 184.75.223.210 ca, Agena (Canada, Toronto, Ontario; 1000) 162.219.176.2 ca, Alhena (Canada, Toronto, Ontario; 1000) 184.75.221.202 ca, Alkurhah (Canada, Toronto, Ontario; 1000) 104.254.90.202 ca, Aludra (Canada, Toronto, Ontario; 1000) 184.75.221.114 ca, Alwaid (Canada, Toronto, Ontario; 1000) 184.75.221.170 ca, Alya (Canada, Toronto, Ontario; 1000) 184.75.221.162 ca, Angetenar (Canada, Toronto, Ontario; 1000) 184.75.221.210 ca, Arkab (Canada, Toronto, Ontario; 1000) 184.75.223.234 ca, Avior (Canada, Toronto, Ontario; 1000) 184.75.214.162 ca, Cephei (Canada, Toronto, Ontario; 1000) 104.254.90.234 ca, Chort (Canada, Toronto, Ontario; 1000) 104.254.90.242 ca, Enif (Canada, Toronto, Ontario; 1000) 104.254.90.250 ca, Gorgonea (Canada, Toronto, Ontario; 1000) 87.101.92.170 ca, Lacerta (Canada, Montreal; 1000) 184.75.221.2 ca, Lesath (Canada, Toronto, Ontario; 1000) 184.75.223.218 ca, Mintaka (Canada, Toronto, Ontario; 1000) 192.30.89.66 ca, Nahn (Canada, Vancouver; 1000) 192.30.89.26 ca, Pisces (Canada, Vancouver; 1000) 184.75.221.34 ca, Regulus (Canada, Toronto, Ontario; 1000) 139.28.218.234 ca, Ross (Canada, Montreal; 1000) 104.254.90.186 ca, Rotanev (Canada, Toronto, Ontario; 1000) 184.75.221.178 ca, Sadalbari (Canada, Toronto, Ontario; 1000) 184.75.223.226 ca, Saiph (Canada, Toronto, Ontario; 1000) 184.75.223.194 ca, Sargas (Canada, Toronto, Ontario; 1000) 192.30.89.74 ca, Sham (Canada, Vancouver; 1000) 104.254.90.194 ca, Sharatan (Canada, Toronto, Ontario; 1000) 184.75.221.42 ca, Sualocin (Canada, Toronto, Ontario; 1000) 137.63.71.50 ca, Tegmen (Canada, Toronto, Ontario; 1000) 184.75.221.194 ca, Tejat (Canada, Toronto, Ontario; 1000) 192.30.89.50 ca, Telescopium (Canada, Vancouver; 1000) 192.30.89.58 ca, Titawin (Canada, Vancouver; 1000) 184.75.223.202 ca, Tyl (Canada, Toronto, Ontario; 1000) 184.75.221.58 ca, Ukdah (Canada, Toronto, Ontario; 1000) 185.156.175.170 ch, Achernar (Switzerland, Zurich; 1000) 185.156.175.34 ch, Achird (Switzerland, Zurich; 1000) 185.156.175.50 ch, Baiten (Switzerland, Zurich; 1000) 195.206.105.226 ch, Dorado (Switzerland, Zurich; 1000) 185.156.175.42 ch, Hamal (Switzerland, Zurich; 1000) 91.214.169.68 ch, Kitalpha (Switzerland, Zurich; 1000) 195.206.105.202 ch, Sextans (Switzerland, Zurich; 1000) 185.156.175.58 ch, Sirrah (Switzerland, Zurich; 1000) 46.19.137.114 ch, Virginis (Switzerland, Bern; 1000) 79.142.69.159 ch, Xuange (Switzerland, Zurich; 10000) 185.156.174.114 cz, Centaurus (Czech Republic, Prague; 1000) 185.156.174.26 cz, Markab (Czech Republic, Prague; 1000) 185.156.174.154 cz, Turais (Czech Republic, Prague; 1000) 89.238.166.234 cz, Zuben (Czech Republic, Prague; 1000) 185.104.184.42 de, Adhara (Germany, Frankfurt; 1000) 141.98.102.186 de, Alsephina (Germany, Frankfurt; 1000) 185.189.112.26 de, Cervantes (Germany, Frankfurt; 1000) 37.120.217.242 de, Cujam (Germany, Berlin; 1000) 141.98.102.242 de, Dubhe (Germany, Frankfurt; 1000) 185.189.112.10 de, Errai (Germany, Frankfurt; 1000) 178.162.204.227 de, Intercrus (Germany, Frankfurt; 1000) 141.98.102.226 de, Menkalinan (Germany, Frankfurt; 1000) 79.143.191.166 de, Mesarthim (Germany, Munich; 1000) 141.98.102.234 de, Mirfak (Germany, Frankfurt; 1000) 141.98.102.178 de, Mirzam (Germany, Frankfurt; 1000) 185.189.112.18 de, Ogma (Germany, Frankfurt; 1000) 178.162.209.151 de, Serpens (Germany, Frankfurt; 1000) 178.162.204.219 de, Tucana (Germany, Frankfurt; 1000) 178.162.204.222 de, Veritate (Germany, Frankfurt; 1000) 185.195.237.202 ee, Alruba (Estonia, Tallinn; 1000) 185.183.106.2 es, Eridanus (Spain, Barcelona; 1000) 185.93.182.170 es, Mekbuda (Spain, Madrid; 1000) 194.99.104.34 es, Taurus (Spain, Madrid; 1000) 185.103.96.132 gb, Alathfar (United Kingdom, Maidenhead; 1000) 217.151.98.162 gb, Alshain (United Kingdom, London; 1000) #89.238.150.42 gb, Arion (United Kingdom, London; 1000) 217.151.98.167 gb, Asterion (United Kingdom, London; 1000) 89.249.74.212 gb, Asterope (United Kingdom, Manchester; 1000) 185.103.96.134 gb, Betelgeuse (United Kingdom, Maidenhead; 1000) 94.229.74.90 gb, Carinae (United Kingdom, Maidenhead; 1000) 89.249.74.217 gb, Chow (United Kingdom, Manchester; 1000) 185.103.96.133 gb, Denebola (United Kingdom, Maidenhead; 1000) 2.58.47.202 gb, Geminorum (United Kingdom, London; 1000) 185.103.96.131 gb, Kitel (United Kingdom, Maidenhead; 1000) 185.103.96.130 gb, Minkar (United Kingdom, Maidenhead; 1000) 84.39.117.56 gb, Naos (United Kingdom, Manchester; 1000) 84.39.116.179 gb, Nashira (United Kingdom, Manchester; 1000) 192.145.126.114 gb, Orbitar (United Kingdom, Manchester; 1000) 141.98.101.132 gb, Westerlund (United Kingdom, Manchester; 1000) 37.120.210.210 jp, Biham (Japan, Tokyo; 1000) 82.102.28.106 jp, Iskandar (Japan, Tokyo; 1000) 37.120.210.218 jp, Okab (Japan, Tokyo; 1000) 193.148.16.210 jp, Taphao (Japan, Tokyo; 1000) 46.183.220.202 lv, Felis (Latvia, Riga; 1000) #159.148.186.13 lv, Meissa (Latvia, Riga; 100) 159.148.186.18 lv, Phact (Latvia, Riga; 100) 159.148.186.24 lv, Schedir (Latvia, Riga; 100) 159.148.186.31 lv, Shaula (Latvia, Riga; 100) 213.152.161.180 nl, Alchiba (Netherlands, Alblasserdam; 1000) 213.152.161.116 nl, Alcyone (Netherlands, Alblasserdam; 1000) 134.19.179.170 nl, Aljanah (Netherlands, Alblasserdam; 1000) 213.152.187.199 nl, Alphard (Netherlands, Alblasserdam; 1000) 213.152.187.194 nl, Alphecca (Netherlands, Alblasserdam; 1000) 134.19.179.242 nl, Alpheratz (Netherlands, Alblasserdam; 1000) 213.152.187.214 nl, Alphirk (Netherlands, Alblasserdam; 1000) 213.152.162.78 nl, Alrai (Netherlands, Alblasserdam; 1000) 213.152.161.4 nl, Alshat (Netherlands, Alblasserdam; 1000) 213.152.161.169 nl, Alterf (Netherlands, Alblasserdam; 1000) 213.152.187.204 nl, Alzirr (Netherlands, Alblasserdam; 1000) 213.152.162.164 nl, Ancha (Netherlands, Alblasserdam; 1000) 213.152.161.228 nl, Andromeda (Netherlands, Alblasserdam; 1000) 213.152.186.18 nl, Anser (Netherlands, Alblasserdam; 1000) 213.152.187.209 nl, Asellus (Netherlands, Alblasserdam; 1000) 134.19.179.194 nl, Aspidiske (Netherlands, Alblasserdam; 1000) 213.152.161.9 nl, Atik (Netherlands, Alblasserdam; 1000) 213.152.161.218 nl, Canis (Netherlands, Alblasserdam; 1000) 134.19.179.138 nl, Capella (Netherlands, Alblasserdam; 1000) 213.152.162.169 nl, Caph (Netherlands, Alblasserdam; 1000) 213.152.161.68 nl, Celaeno (Netherlands, Alblasserdam; 1000) 213.152.187.219 nl, Chara (Netherlands, Alblasserdam; 1000) 213.152.186.162 nl, Comae (Netherlands, Alblasserdam; 1000) 213.152.162.14 nl, Crater (Netherlands, Alblasserdam; 1000) 213.152.161.243 nl, Cygnus (Netherlands, Alblasserdam; 1000) 213.152.161.164 nl, Diphda (Netherlands, Alblasserdam; 1000) 213.152.161.210 nl, Edasich (Netherlands, Alblasserdam; 1000) 213.152.186.39 nl, Elnath (Netherlands, Alblasserdam; 1000) 134.19.179.146 nl, Eltanin (Netherlands, Alblasserdam; 1000) 213.152.162.73 nl, Garnet (Netherlands, Alblasserdam; 1000) 213.152.161.100 nl, Gianfar (Netherlands, Alblasserdam; 1000) 213.152.162.93 nl, Gienah (Netherlands, Alblasserdam; 1000) 213.152.161.39 nl, Hassaleh (Netherlands, Alblasserdam; 1000) 213.152.162.4 nl, Horologium (Netherlands, Alblasserdam; 1000) 213.152.161.34 nl, Hyadum (Netherlands, Alblasserdam; 1000) 213.152.162.9 nl, Hydrus (Netherlands, Alblasserdam; 1000) 213.152.186.23 nl, Jabbah (Netherlands, Alblasserdam; 1000) 213.152.161.84 nl, Kajam (Netherlands, Alblasserdam; 1000) 213.152.162.180 nl, Kocab (Netherlands, Alblasserdam; 1000) 134.19.179.178 nl, Larawag (Netherlands, Alblasserdam; 1000) 213.152.186.167 nl, Luhman (Netherlands, Alblasserdam; 1000) 213.152.162.103 nl, Maasym (Netherlands, Alblasserdam; 1000) 213.152.187.224 nl, Matar (Netherlands, Alblasserdam; 1000) 134.19.179.162 nl, Melnick (Netherlands, Alblasserdam; 1000) 213.152.161.29 nl, Merga (Netherlands, Alblasserdam; 1000) 213.152.162.68 nl, Mirach (Netherlands, Alblasserdam; 1000) 213.152.162.88 nl, Miram (Netherlands, Alblasserdam; 1000) 134.19.179.202 nl, Muhlifain (Netherlands, Alblasserdam; 1000) 213.152.162.153 nl, Muscida (Netherlands, Alblasserdam; 1000) 213.152.161.248 nl, Musica (Netherlands, Alblasserdam; 1000) 213.152.161.24 nl, Nash (Netherlands, Alblasserdam; 1000) 213.152.161.238 nl, Orion (Netherlands, Alblasserdam; 1000) 213.152.187.229 nl, Phaet (Netherlands, Alblasserdam; 1000) 134.19.179.130 nl, Piscium (Netherlands, Alblasserdam; 1000) 213.152.162.148 nl, Pleione (Netherlands, Alblasserdam; 1000) 213.152.161.233 nl, Pyxis (Netherlands, Alblasserdam; 1000) 213.152.162.83 nl, Rukbat (Netherlands, Alblasserdam; 1000) 213.152.161.19 nl, Salm (Netherlands, Alblasserdam; 1000) 134.19.179.154 nl, Scuti (Netherlands, Alblasserdam; 1000) 213.152.186.34 nl, Sheliak (Netherlands, Alblasserdam; 1000) 213.152.161.14 nl, Situla (Netherlands, Alblasserdam; 1000) 213.152.162.98 nl, Subra (Netherlands, Alblasserdam; 1000) 134.19.179.186 nl, Suhail (Netherlands, Alblasserdam; 1000) 213.152.161.137 nl, Talitha (Netherlands, Alblasserdam; 1000) 213.152.161.132 nl, Tarazed (Netherlands, Alblasserdam; 1000) 134.19.179.234 nl, Tiaki (Netherlands, Alblasserdam; 1000) 213.152.186.172 nl, Tianyi (Netherlands, Alblasserdam; 1000) 213.152.161.148 nl, Zibal (Netherlands, Alblasserdam; 1000) 82.102.27.194 no, Camelopardalis (Norway, Oslo; 1000) 82.102.27.170 no, Cepheus (Norway, Oslo; 1000) 185.206.225.50 no, Fomalhaut (Norway, Oslo; 1000) 82.102.27.162 no, Gemini (Norway, Oslo; 1000) 185.206.225.58 no, Ophiuchus (Norway, Oslo; 1000) 103.231.91.58 nz, Fawaris (New Zealand, Auckland; 1000) 91.207.102.162 ro, Alamak (Romania, Bucharest; 1000) 86.105.9.66 ro, Canes (Romania, Bucharest; 1000) 152.89.160.130 rs, Alnitak (Serbia, Belgrade; 1000) 128.127.104.79 se, Ain (Sweden, Stockholm; 10000) 62.102.148.149 se, Albali (Sweden, Uppsala; 1000) 62.102.148.142 se, Algieba (Sweden, Uppsala; 1000) 62.102.148.147 se, Algorab (Sweden, Uppsala; 1000) 62.102.148.145 se, Alrami (Sweden, Uppsala; 1000) 62.102.148.140 se, Altarf (Sweden, Uppsala; 1000) 62.102.148.151 se, Alula (Sweden, Uppsala; 1000) 62.102.148.150 se, Atria (Sweden, Uppsala; 1000) 62.102.148.141 se, Azmidiske (Sweden, Uppsala; 1000) 62.102.148.148 se, Benetnasch (Sweden, Uppsala; 1000) 79.142.76.243 se, Copernicus (Sweden, Stockholm; 1000) 62.102.148.144 se, Hatysa (Sweden, Uppsala; 1000) 128.127.105.183 se, Lupus (Sweden, Stockholm; 1000) 62.102.148.143 se, Menkab (Sweden, Uppsala; 1000) 62.102.148.146 se, Muphrid (Sweden, Uppsala; 1000) 31.3.152.99 se, Norma (Sweden, Stockholm; 1000) 103.254.153.68 sg, Antares (Singapore, Singapore; 1000) 185.200.116.210 sg, Auriga (Singapore, Singapore; 1000) 185.200.116.202 sg, Circinus (Singapore, Singapore; 1000) 185.200.116.218 sg, Delphinus (Singapore, Singapore; 1000) 185.200.117.130 sg, Hydra (Singapore, Singapore; 1000) 209.58.173.142 sg, Lacaille (Singapore, Singapore; 1000) 92.119.178.2 sg, Luyten (Singapore, Singapore; 1000) 209.58.183.86 sg, Struve (Singapore, Singapore; 1000) 185.200.116.130 sg, Triangulum (Singapore, Singapore; 1000) 91.231.84.39 ua, Alcor (Ukraine, Kiev; 1000) 173.44.55.154 us, Acamar (United States, Miami; 1000) 107.167.244.66 us, Alkes (United States, Los Angeles; 1000) 199.249.223.129 us, Aquila (United States, Fremont, California; 1000) 193.37.254.2 us, Bootes (United States, Phoenix, Arizona; 1000) 193.37.254.18 us, Chalawan (United States, Phoenix, Arizona; 1000) 199.249.230.41 us, Chamaeleon (United States, Dallas, Texas; 1000) 96.47.229.58 us, Cursa (United States, Miami; 1000) 185.228.19.146 us, Dimidium (United States, New York City; 1000) 199.249.230.36 us, Equuleus (United States, Dallas, Texas; 1000) 68.235.48.107 us, Fang (United States, Chicago, Illinois; 1000) 91.132.0.202 us, Gliese (United States, New York City; 1000) 37.120.132.82 us, Groombridge (United States, Los Angeles; 1000) 199.249.230.46 us, Helvetios (United States, Dallas, Texas; 1000) 64.42.179.58 us, Hercules (United States, Atlanta, Georgia; 1000) 193.37.254.26 us, Indus (United States, Phoenix, Arizona; 1000) 68.235.35.123 us, Kruger (United States, Chicago, Illinois; 1000) 199.249.230.21 us, Leo (United States, Dallas, Texas; 1000) 64.42.179.66 us, Libra (United States, Atlanta, Georgia; 1000) 194.36.111.58 us, Lich (United States, New York City; 1000) 199.249.230.6 us, Mensa (United States, Dallas, Texas; 1000) 107.167.244.50 us, Merope (United States, Los Angeles; 1000) 156.96.151.131 us, Metallah (United States, Pennsylvania; 1000) 64.42.179.42 us, Musca (United States, Atlanta, Georgia; 1000) 199.249.230.16 us, Pegasus (United States, Dallas, Texas; 1000) 193.37.254.34 us, Phoenix (United States, Phoenix, Arizona; 1000) 198.203.28.42 us, Pollux (United States, Jacksonville, Florida; 1000) 199.249.230.26 us, Ran (United States, Dallas, Texas; 1000) 107.167.244.82 us, Sabik (United States, Los Angeles; 1000) 64.42.179.34 us, Sculptor (United States, Atlanta, Georgia; 1000) 199.249.230.11 us, Scutum (United States, Dallas, Texas; 1000) 68.235.52.35 us, Sneden (United States, Chicago, Illinois; 1000) 37.120.132.90 us, Teegarden (United States, Los Angeles; 1000) 64.42.179.50 us, Ursa (United States, Atlanta, Georgia; 1000) 193.37.254.10 us, Virgo (United States, Phoenix, Arizona; 1000) 199.249.230.31 us, Volans (United States, Dallas, Texas; 1000) 199.249.230.1 us, Vulpecula (United States, Dallas, Texas; 1000) 173.44.55.178 us, Yildun (United States, Miami; 1000) I believe it doesn't affect Eddie as it can pick servers on its own by pinging. But the "preferred" server and DNS responses are still dependent on the server logic, hence Ain sometimes ends up recommended as Earth or Europe server (currently not any longer) but seems to always be the preferred choice for Sweden. To quantify that, it's 350 out of 755 users connected to Swedish servers and unnecessarily getting insane jitter and latencies. To proof it's not just me, https://lg.telia.net/ from AMS-IX showed 24ms to another Swedish server by AirVPN and approx. 340ms to Ain. Or AirVPN's own lookup: https://airvpn.org/routes/?q=128.127.104.79 PS: Is it an Intel CPU? Edit: What I meant to say with this post (not only to start investigating Ain) that the "best server" logic should be not only working based on bandwidth load, but the server's relative latency times. PS2: I do realize that it's currently listed as having issues (packet loss) but during my last week's connect afaik it wasn't. Logically, jitter/high latency begins before packet loss kicks in (networking and throughput theory) - https://airvpn.org/servers/Ain/
  13. 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.
  14. On Ubuntu 18.04.5 LTS, with humminbird version 1.1.1, after ending the VPN session, my DNS is shot, and I don't know how to restore it other than rebooting. I had no problem with an earlier version of hummingbird. I tried the AirVPN Suite. Same problem. The attached file contains the output of hummingbird. The assertion at the end "Successfully restored DNS settings" is not correct. I would be happy enough if you could tell me where to look for the DNS settings, or how to restore them manually. hummingbird.log
  15. Could you provide step by step guide to remove DNS leaks for openvpn on Fedora 33 with terminal?
  16. Hi all, I'm running the new AirVPN suite (which is awesome) on a Raspberry Pi (Debian) and connecting a SOCKS 5 proxy (Dante) to tun0. So far so good in terms of having a VPN available for my network devices that I want to direct traffic to. Where I reach the edge of my understanding is handling DNS in such a setup. I can see that the suite overwrites resolv.conf on the Pi with the (varying) VPN DNS server. What I'd really like is to point my local DNS server to the Pi and have all my outgoing DNS traffic to the VPN DNS. I'm guessing I need something listening on the Pi's DNS ports that forwards appropriately, but I don't know if I need a full server like Bind, a proxy, a forwarder, or how to pick up the correct DNS from the VPN. Possibly I'm literally just missing a good search term for finding the right tool & configuration. Suggestions would be appreciated!
  17. hi, i'm unable to use eddie so connect to airvpn using the terminal. however, this means that my system uses my ISP's dns servers and not airvpn dns servers. the guide on how to accept push requests mentions that I need to add the following to my openvpn configuration file: now please know that I am a dummy. i have tried putting this script into different openvpn files but have had no luck. could someone tell me exactly in which file this goes and exactly where in the specified file? i've also looked at the config generator but cannot find the "customs directives" field. thanks for any help
  18. Hi, folks, I observe a strange behavior when trying to bypass DNS-based site blocking in Russia. The name flibusta.is gets unexpectedly resolved to the ban site lawfilter.ertelecom.ru. I use openvpn under Debian Linux. OpenVPN 2.5.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 31 2020 Configuration files are downloaded from airvpn.org generator. By default, /etc/resolv.conf contains the following: nameserver 192.168.1.1 When I connect to VPN, the settings do not change. My browser (Firefox 84) is configured to use DNS over HTTPS, but I can also change /etc/resolv.conf to use the Cloudflare DNS: nameserver 1.1.1.1 Now, I run tcpdump to capture all DNS exchange and try to open flibusta.is in the browser. Here's what I get: 19:32:41.326041 Out ethertype IPv4 (0x0800), length 73: 10.7.213.47.41548 > 1.1.1.1.53: 38651+ A? flibusta.is. (29) 19:32:41.326052 Out ethertype IPv4 (0x0800), length 73: 10.7.213.47.41548 > 1.1.1.1.53: 2303+ AAAA? flibusta.is. (29) 19:32:41.345679 Out ethertype IPv4 (0x0800), length 84: 10.7.213.47.37238 > 1.1.1.1.53: 25045+ A? lawfilter.ertelecom.ru. (40) 19:32:41.345690 Out ethertype IPv4 (0x0800), length 84: 10.7.213.47.37238 > 1.1.1.1.53: 13267+ AAAA? lawfilter.ertelecom.ru. (40) 19:32:41.471163 In ethertype IPv4 (0x0800), length 100: 1.1.1.1.53 > 10.7.213.47.37238: 25045 1/0/0 A 188.186.157.49 (56) 19:32:41.619187 In ethertype IPv4 (0x0800), length 149: 1.1.1.1.53 > 10.7.213.47.41548: 2303 0/1/0 (105) 19:32:41.619205 In ethertype IPv4 (0x0800), length 128: 1.1.1.1.53 > 10.7.213.47.37238: 13267 0/1/0 (84) 19:32:41.619214 In ethertype IPv4 (0x0800), length 89: 1.1.1.1.53 > 10.7.213.47.41548: 38651 1/0/0 A 81.17.19.227 (45) 10.7.213.47 is the address of the VPN interface. The request seems to go through VPN to Cloudflare, but for some reason it resolves to lawfilter.ertelecom.ru. This response gets inserted between request and the correct response (the last line). But this doesn't happen every time. Sometimes, after re-establishing VPN connection, tcpdump captures the correct response: 19:53:46.028205 Out ethertype IPv4 (0x0800), length 73: 10.20.213.58.38277 > 1.1.1.1.53: 10615+ A? flibusta.is. (29) 19:53:46.028224 Out ethertype IPv4 (0x0800), length 73: 10.20.213.58.38277 > 1.1.1.1.53: 4978+ AAAA? flibusta.is. (29) 19:53:46.121195 In ethertype IPv4 (0x0800), length 89: 1.1.1.1.53 > 10.20.213.58.38277: 10615 1/0/0 A 81.17.19.227 (45) So, basically, there are two things I can't understand. First, why the browser seems to ignore DOH settings, sending requests via plain UDP. But it is not related to VPN, so, let's not bother ourselves with this one. The second question is how the DNS request sent via VPN gets a spoofed response from the provider's blocker? Am I simply doing something wrong?
  19. Hi, Using Eddie 2.18.9 and the OS Fedora 32 works great. After upgrading to Fedora 33, Eddie 2.18.9 failed to connect to any server with this error : "Checking DNS failed". In the preferences, if I uncheck DNS -> Check AirVPN DNS, then it will connect. BUT this will be unsafe as there will be a DNS leak as tested with ipleak.net . There has been a change in the way Fedora handle DNS in the 33 version : systemd-resolved: introduction to split DNS (fedoramagazine.org) Fedora 33 now use systemd-resolved for DNS queries. IMHO This is the culprit. Please help with this issue : default safe configuration is now broken and disabling AirVPN DNS is not as secure as I could expect using AirVPN. Kind regards.
  20. Every week or so I am finding my connection really slow. After troubleshooting, I find that changing the DNS server fixes the problem. Because I have the VPN configured on my ASUS Merlin router the DNS settings are manual. I select a DNS server from the OpenNIC project, but I would like to avoid having to manually change every couple of weeks. Do the DNS servers periodically experience issues? Is there a way to find a stable DNS server? Could my issue be related to something else?
  21. for the past 2 days IPLeak is resolving DNS verrryyy slowly and getting 0 results with 100 errors, while there are 2 DNS IP one each IPv4 and IPv6. active torrent is not working as the link does not download anything.
  22. Hello, I reconnected to AirVPN and for the first time ipleak.net show me only one DNS server, I have the confirm that is an AirVPN server but all the other times I got over 50 different DNS. Why this difference? Thanks
  23. 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
  24. Lately, I've come across the Pi-Hole, a program for the Raspberry Pi which basically turns the device into an advanced adblocker which you can connect your computer to via DNS. It sounded very fascinating as it could do the work of your typical browser adblocker but potentially freeing the use of one, thus reducing any browser entropy that could uniquely identify you - whether you're using a VPN or not. Pi-Hole website link here. Check it out! What I want to know is whether or not AirVPN would work well with the Pi-Hole if I had to replace the VPN's DNS with the devices. Are there any noteworthy features of AirVPN's DNS I would be giving up in exchange? Thanks.
  25. . 2019.02.09 14:20:39 - Eddie version: 2.16.3 / windows_x64, System: Windows, Name: Windows 10 Pro, Version: Microsoft Windows NT 10.0.17134.0, Mono/.Net: v4.0.30319 . 2019.02.09 14:20:39 - Reading options from D:\Programs\AirVPN\default.xml . 2019.02.09 14:20:39 - Command line arguments (0): . 2019.02.09 14:20:39 - Profile path: D:\Programs\AirVPN\default.xml . 2019.02.09 14:20:40 - OpenVPN Driver - TAP-Windows Adapter V9, version 9.21.2 . 2019.02.09 14:20:40 - OpenVPN - Version: 2.4.6 - OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 (D:\Programs\AirVPN\openvpn.exe) . 2019.02.09 14:20:40 - SSH - Version: plink 0.67 (D:\Programs\AirVPN\plink.exe) . 2019.02.09 14:20:40 - SSL - Version: stunnel 5.40 (D:\Programs\AirVPN\stunnel.exe) . 2019.02.09 14:20:40 - curl - Version: 7.54.1 (D:\Programs\AirVPN\curl.exe) . 2019.02.09 14:20:40 - Certification Authorities: D:\Programs\AirVPN\res\cacert.pem . 2019.02.09 14:20:41 - Updating systems & servers data ... I 2019.02.09 14:20:41 - Ready . 2019.02.09 14:20:42 - Systems & servers data update completed I 2019.02.09 14:20:49 - Session starting. I 2019.02.09 14:20:49 - Checking authorization ... . 2019.02.09 14:20:50 - IPv6 disabled with packet filtering. ! 2019.02.09 14:20:50 - Connecting to Sculptor (United States, Atlanta, Georgia) . 2019.02.09 14:20:50 - OpenVPN > OpenVPN 2.4.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 27 2018 . 2019.02.09 14:20:50 - OpenVPN > Windows version 6.2 (Windows 8 or greater) 64bit . 2019.02.09 14:20:50 - OpenVPN > library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 . 2019.02.09 14:20:50 - Connection to OpenVPN Management Interface . 2019.02.09 14:20:50 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2019.02.09 14:20:50 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2019.02.09 14:20:50 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2019.02.09 14:20:50 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2019.02.09 14:20:50 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2019.02.09 14:20:50 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]64.42.179.37:443 . 2019.02.09 14:20:50 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144] . 2019.02.09 14:20:50 - OpenVPN > UDP link local: (not bound) . 2019.02.09 14:20:50 - OpenVPN > UDP link remote: [AF_INET]64.42.179.37:443 . 2019.02.09 14:20:50 - OpenVPN > TLS: Initial packet from [AF_INET]64.42.179.37:443, sid=4831c8cf c4c42820 . 2019.02.09 14:20:50 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2019.02.09 14:20:50 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2019.02.09 14:20:50 - OpenVPN > VERIFY KU OK . 2019.02.09 14:20:50 - OpenVPN > Validating certificate extended key usage . 2019.02.09 14:20:50 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2019.02.09 14:20:50 - OpenVPN > VERIFY EKU OK . 2019.02.09 14:20:50 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Sculptor, emailAddress=info@airvpn.org . 2019.02.09 14:20:50 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2019.02.09 14:20:50 - OpenVPN > [sculptor] Peer Connection Initiated with [AF_INET]64.42.179.37:443 . 2019.02.09 14:20:51 - OpenVPN > SENT CONTROL [sculptor]: 'PUSH_REQUEST' (status=1) . 2019.02.09 14:20:51 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.23.90.1,dhcp-option DNS6 fde6:7a:7d20:135a::1,tun-ipv6,route-gateway 10.23.90.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:135a::10b9/64 fde6:7a:7d20:135a::1,ifconfig 10.23.90.187 255.255.255.0,peer-id 0,cipher AES-256-GCM' . 2019.02.09 14:20:51 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2019.02.09 14:20:51 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:135a::1' . 2019.02.09 14:20:51 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2019.02.09 14:20:51 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:135a::10b9/64 fde6:7a:7d20:135a::1' . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: peer-id set . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2019.02.09 14:20:51 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2019.02.09 14:20:51 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2019.02.09 14:20:51 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2019.02.09 14:20:51 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2019.02.09 14:20:51 - OpenVPN > interactive service msg_channel=0 . 2019.02.09 14:20:51 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=2 HWADDR=e0:d5:5e:af:74:93 . 2019.02.09 14:20:51 - OpenVPN > open_tun . 2019.02.09 14:20:51 - OpenVPN > TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{2D318BED-776D-427C-94CD-FF14B83FB719}.tap . 2019.02.09 14:20:51 - OpenVPN > TAP-Windows Driver Version 9.21 . 2019.02.09 14:20:51 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.23.90.0/10.23.90.187/255.255.255.0 [sUCCEEDED] . 2019.02.09 14:20:51 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.23.90.187/255.255.255.0 on interface {2D318BED-776D-427C-94CD-FF14B83FB719} [DHCP-serv: 10.23.90.254, lease-time: 31536000] . 2019.02.09 14:20:51 - OpenVPN > Successful ARP Flush on interface [9] {2D318BED-776D-427C-94CD-FF14B83FB719} . 2019.02.09 14:20:51 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2019.02.09 14:20:56 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up . 2019.02.09 14:20:56 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 64.42.179.37 MASK 255.255.255.255 192.168.1.1 . 2019.02.09 14:20:56 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4 . 2019.02.09 14:20:56 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2019.02.09 14:20:56 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.23.90.1 . 2019.02.09 14:20:56 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4 . 2019.02.09 14:20:56 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2019.02.09 14:20:56 - OpenVPN > C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.23.90.1 . 2019.02.09 14:20:56 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4 . 2019.02.09 14:20:56 - OpenVPN > Route addition via IPAPI succeeded [adaptive] . 2019.02.09 14:20:56 - Interface Ethernet 2 metric changed from Automatic to 3, layer IPv4 . 2019.02.09 14:20:56 - DNS leak protection with packet filtering enabled. . 2019.02.09 14:20:57 - DNS IPv4 of a network adapter forced (Ethernet 2, from manual (10.23.56.1) to 10.23.90.1) W 2019.02.09 14:20:57 - Routes, add 64.42.179.35 for gateway 10.23.90.1 failed: The screen cannot be set to the number of lines and columns specified . 2019.02.09 14:20:57 - Unable to compute route for 2605:9f80:6000:77:3824:245d:eb3b:b055: IPv6 VPN gateway not available. . 2019.02.09 14:20:57 - Flushing DNS I 2019.02.09 14:20:57 - Checking route IPv4 I 2019.02.09 14:20:57 - Checking DNS . 2019.02.09 14:21:09 - Checking DNS failed: . 2019.02.09 14:21:09 - Checking DNS (2° try) . 2019.02.09 14:21:23 - Checking DNS failed: . 2019.02.09 14:21:23 - Checking DNS (3° try)
×
×
  • Create New...