Jump to content
Not connected, Your IP: 54.227.97.219

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
    • Mirrors

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 182 results

  1. 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?
  2. 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/
  3. 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.
  4. 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
  5. Could you provide step by step guide to remove DNS leaks for openvpn on Fedora 33 with terminal?
  6. 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!
  7. 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
  8. 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?
  9. 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.
  10. 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?
  11. 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.
  12. 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
  13. 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
  14. 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.
  15. 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.
  16. . 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)
  17. Can anyone explain to me, how the website support explained here is working: https://airvpn.org/forum/10-websites-support/ ? I thought, that when i'm connected to any AirVPN server, the internal dns server will reroute the traffic for those specific sites to a supported server in another country. Isn't this the case? Because i'm connected to Prague and everytime i'm visiting Zattoo for example, im getting the message, that my country is not supported. So Zattoo is still seeing the Prague IP i guess...And yes, my DNS is not leaking and i'm using the DNS servers of AirVPN.
  18. Hey, I got this since a while now. Sometimes I try to resolve airvpn.org it fails. After some trys or minutes it works fine. I use a Pi-Hole as DNS Server running a local unbound (127.0.0.1) and as said I only got issues with this domain here.. real strange. Luckily today I was able to grab some logs, maybe someone can read them and tell me if the dnssec-query request tell something useful ? Jan 4 19:19:07 dnsmasq[31678]: query[PTR] 44.1.168.192.in-addr.arpa from 192.168.1.15 Jan 4 19:19:07 dnsmasq[31678]: /etc/pihole/local.list 192.168.1.44 is pi-hole Jan 4 19:19:07 dnsmasq[31678]: query[A] airvpn.org.localdomain from 192.168.1.15 Jan 4 19:19:07 dnsmasq[31678]: cached airvpn.org.localdomain is NXDOMAIN Jan 4 19:19:07 dnsmasq[31678]: query[AAAA] airvpn.org.localdomain from 192.168.1.15 Jan 4 19:19:07 dnsmasq[31678]: cached airvpn.org.localdomain is NXDOMAIN Jan 4 19:19:07 dnsmasq[31678]: query[A] airvpn.org from 192.168.1.15 Jan 4 19:19:07 dnsmasq[31678]: forwarded airvpn.org to 127.0.0.1 Jan 4 19:19:09 dnsmasq[31678]: query[AAAA] airvpn.org from 192.168.1.15 Jan 4 19:19:09 dnsmasq[31678]: forwarded airvpn.org to 127.0.0.1 Jan 4 19:19:16 dnsmasq[31678]: dnssec-query[DS] airvpn.org to 127.0.0.1 Jan 4 19:19:16 dnsmasq[31678]: dnssec-query[DS] airvpn.org to 127.0.0.1 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DS keytag 55882, algo 8, digest 1 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DS keytag 57919, algo 8, digest 1 Jan 4 19:19:16 dnsmasq[31678]: dnssec-query[DNSKEY] airvpn.org to 127.0.0.1 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DS keytag 55882, algo 8, digest 1 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DS keytag 57919, algo 8, digest 1 Jan 4 19:19:16 dnsmasq[31678]: dnssec-query[DNSKEY] airvpn.org to 127.0.0.1 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 57919, algo 8 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 55882, algo 8 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 59298, algo 8 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 38193, algo 8 Jan 4 19:19:16 dnsmasq[31678]: validation result is SECURE Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is 5.196.64.52 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 57919, algo 8 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 55882, algo 8 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 59298, algo 8 Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is DNSKEY keytag 38193, algo 8 Jan 4 19:19:16 dnsmasq[31678]: validation result is SECURE Jan 4 19:19:16 dnsmasq[31678]: reply airvpn.org is 2001:41d0:a:6034:: Please note that I was running a nslookup airvpn.org here and at the end it was working. Same command 2 minutes earlier failed. So till 19:19:07 I had a DNS timeout when querying airvpn.org and on 19:19:16 it started to work just fine Any help is much appreciated.
  19. Been having trouble with Audible the last few days. I sometimes can and sometimes can't log in to audible.com while using a VPN (and sometimes only certain pages will load when I can), but I can never download any of the titles in my library - either the page times out after clicking the download button or redirects me to audible.com/howtolisten. (Yes, the option to check for Audible software was disabled.) At first all I had to do was log in using my real IP, but then later I found that I couldn't download even then: it would keep redirecting me again to the "howtolisten" page. So... to make a long story short, I had to download using my real IP via Audible Manager. I'm mentioning the latter problem because I'm not quite sure at this point if the inability to download was caused by using a VPN, or if Amazon/Audible is trying to force everyone now to use their Manager, or if it's a couple of issues occurring simultaneously - or if something in their system just isn't working right at the moment. BUT.... I also have an Audible UK account, which I can usually log-in to using just a UK IP, but now I could not log in to audible.co.uk after repeated attempts and trying several UK servers - the site would just not load at all. I did finally manage it by also using a UK dns, something I've never had to do before. By the way, Amazon.com and Amazon.co.uk: no problems logging into those sites, and so far I haven't found any pages not loading on either, although I haven't yet tried to purchase anything while using a VPN.
  20. Hello everyone, new AirVPN user here. On my Macbook Pro, I use OpenVPN CLI client from Homebrew package manager instead of Eddie or Tunnelblick. I can connect to AirVPN server but can't browse any thing. From the terminal I can ping IP addresses but can't ping any website. This led me to think that something wrong with DNS. Some excerpts from CLI log: Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16) Opened utun device utun1 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 /sbin/ifconfig utun1 delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure sudo route flush after turning off Wifi on my machine does not solve the problem. I can fix this by manually adding Google DNS (8.8.8.8 and 8.8.4.4) to my network preference. It is weird because I already set these DNS servers on my home router. In contrast, on my Windows machine, with official OpenVPN GUI client, I have no problem at all. And I don't need to manually config DNS server on the network adapter as I have to with my Mac. As far as I know, all AirVPN exit nodes enforce their own DNS server on their side, so I don't know why not setting DNS servers on my network interface causes the problem. Would using public DNS servers in my fix undermine my privacy, such as DNS leak? Also, is there any other fix for my Mac that does not require me to change DNS server on the network interface?
  21. Over the past few weeks, I have been finding that attempts to connect to yelp.com through airvpn servers, from Eddie on Windows or from Viscosity on MacOS, are landing at yelp.de, where the default language offered is German. When the language choice is switched to English (American) at yelp.de, the page reloads as yelp.com in English. So, for example, if I attempt right now to connect to yelp.com using airvpn's Chalawan (US, Phoenix, Arizona) portal, it lands at yelp.de/phoenix, with information displayed in German. If I attempt to connect to yelp.com/nyc using Chalawan, it lands at yelp.de/nyc, in German. However, if I attempt to connect instead to yelp.com directly, without using the vpn, it goes to English-language yelp.com. (Several months back, all attempts to connect to yelp.com through airvpn were being blocked. That problem has been resolved, but it has recently been replaced, it seems, with the new one I am describing here.) Has anyone else experienced this?
  22. Hi, I'm using airvpn with eddie-ui over linux in firefox 63, settings->proxy an option is present DNS over HTTPS, it is cloudflare DNS is it recommended to use over airvp dns or not? thanks
  23. AirVPN, I'm having trouble connecting to certain sites using the VPN service. For example, I'm trying to connect to DesignShack.net but I can't seem to do it with the AirVPN Client running. I have no problem connecting to the site if I'm not running the AirVPN Client. I've tried the following trouble shooting steps. 1) Add other DNS Servers to the airvpn client - Error went from DNS_PROBE_FINISHED_NXDOMAIN to Connection Timeout error 2) Turn on/off IPv6 3) Add other DNS Servers to Wifi network adapter settings. - Same as 1) 4) Added AirVPN Dns servers on top of the previously added DNS Servers on both AirVPN Client & Wireless adapter. - Same as 1) 5) Ping Designshack.net - Request Timeout errors. I would say this happens to 3-5% of the sites I'm visiting. I'm running OS X 10.10.5. I have Network lock turned on, not running any proxies. Any ideas or suggestions would be heartily welcomed. Thanks in advance. ---------------------- Log file entries follows : I 2016.05.12 13:25:16 - AirVPN client version: 2.10.3 / x86, System: OSX, Name: 10.10.5 / x64. 2016.05.12 13:25:17 - Reading options from /Users/FrancisChung/.airvpn/AirVPN.xml. 2016.05.12 13:25:17 - Data Path: /Users/FrancisChung/.airvpn. 2016.05.12 13:25:17 - App Path: /Applications/AirVPN.app/Contents/MacOS. 2016.05.12 13:25:17 - Executable Path: /Applications/AirVPN.app/Contents/MacOS/AirVPN. 2016.05.12 13:25:17 - Command line arguments (0):. 2016.05.12 13:25:17 - Updating systems & servers data .... 2016.05.12 13:25:17 - Operating System: Unix 14.5.0.0 - Darwin GAMBIT.local 14.5.0 Darwin Kernel Version 14.5.0: Mon Jan 11 18:48:35 PST 2016; root:xnu-2782.50.2~1/RELEASE_X86_64 x86_64. 2016.05.12 13:25:17 - Systems & servers data update completedI 2016.05.12 13:25:18 - OpenVPN Driver - ExpectedI 2016.05.12 13:25:18 - OpenVPN - Version: OpenVPN 2.3.8 (/Applications/AirVPN.app/Contents/MacOS/openvpn)I 2016.05.12 13:25:18 - SSH - Version: OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 (/usr/bin/ssh)I 2016.05.12 13:25:18 - SSL - Version: stunnel 5.17 (/Applications/AirVPN.app/Contents/MacOS/stunnel)! 2016.05.12 13:25:18 - Activation of Network Lock - OS X - PF. 2016.05.12 13:25:19 - OS X - PF rules updated, reloadingI 2016.05.12 13:25:19 - Session starting.I 2016.05.12 13:25:20 - IPv6 disabled on network adapter (Wi-Fi)I 2016.05.12 13:25:20 - IPv6 disabled on network adapter (SAMSUNG_Android)I 2016.05.12 13:25:20 - IPv6 disabled on network adapter (Bluetooth DUN 2)I 2016.05.12 13:25:21 - IPv6 disabled on network adapter (Thunderbolt Ethernet Slot 1)I 2016.05.12 13:25:21 - IPv6 disabled on network adapter (Bluetooth PAN)I 2016.05.12 13:25:21 - IPv6 disabled on network adapter (Thunderbolt Bridge)I 2016.05.12 13:25:21 - Checking authorization ...! 2016.05.12 13:25:22 - Connecting to Velorum (Germany, Frankfurt). 2016.05.12 13:25:22 - OpenVPN > OpenVPN 2.3.8 x86_64-apple-darwin14.4.0 [sSL (OpenSSL)] [LZO] [MH] [iPv6] built on Aug 13 2015. 2016.05.12 13:25:22 - OpenVPN > library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.08. 2016.05.12 13:25:22 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3111. 2016.05.12 13:25:22 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file. 2016.05.12 13:25:22 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication. 2016.05.12 13:25:22 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication. 2016.05.12 13:25:22 - OpenVPN > Socket Buffers: R=[196724->131072] S=[9216->131072]. 2016.05.12 13:25:22 - OpenVPN > UDPv4 link local: [undef]. 2016.05.12 13:25:22 - OpenVPN > UDPv4 link remote: [AF_INET]46.165.208.69:443. 2016.05.12 13:25:22 - OpenVPN > TLS: Initial packet from [AF_INET]46.165.208.69:443, sid=2509709c 0cdbc1e1. 2016.05.12 13:25:22 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org. 2016.05.12 13:25:22 - OpenVPN > Validating certificate key usage. 2016.05.12 13:25:22 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0. 2016.05.12 13:25:22 - OpenVPN > VERIFY KU OK. 2016.05.12 13:25:22 - OpenVPN > Validating certificate extended key usage. 2016.05.12 13:25:22 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication. 2016.05.12 13:25:22 - OpenVPN > VERIFY EKU OK. 2016.05.12 13:25:22 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org. 2016.05.12 13:25:23 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key. 2016.05.12 13:25:23 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication. 2016.05.12 13:25:23 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key. 2016.05.12 13:25:23 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication. 2016.05.12 13:25:23 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA. 2016.05.12 13:25:23 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]46.165.208.69:443. 2016.05.12 13:25:25 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1). 2016.05.12 13:25:25 - OpenVPN > ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address. 2016.05.12 13:25:25 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,comp-lzo no,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.6.105 255.255.0.0'. 2016.05.12 13:25:25 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified. 2016.05.12 13:25:25 - OpenVPN > OPTIONS IMPORT: LZO parms modified. 2016.05.12 13:25:25 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified. 2016.05.12 13:25:25 - OpenVPN > OPTIONS IMPORT: route options modified. 2016.05.12 13:25:25 - OpenVPN > OPTIONS IMPORT: route-related options modified. 2016.05.12 13:25:25 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified. 2016.05.12 13:25:25 - OpenVPN > Opened utun device utun0. 2016.05.12 13:25:25 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0. 2016.05.12 13:25:25 - OpenVPN > /sbin/ifconfig utun0 delete. 2016.05.12 13:25:25 - OpenVPN > NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure. 2016.05.12 13:25:25 - OpenVPN > /sbin/ifconfig utun0 10.4.6.105 10.4.6.105 netmask 255.255.0.0 mtu 1500 up. 2016.05.12 13:25:25 - OpenVPN > /sbin/route add -net 10.4.0.0 10.4.6.105 255.255.0.0. 2016.05.12 13:25:25 - OpenVPN > add net 10.4.0.0: gateway 10.4.6.105. 2016.05.12 13:25:25 - OpenVPN > /sbin/route add -net 46.165.208.69 192.168.2.1 255.255.255.255. 2016.05.12 13:25:25 - OpenVPN > add net 46.165.208.69: gateway 192.168.2.1. 2016.05.12 13:25:25 - OpenVPN > /sbin/route add -net 0.0.0.0 10.4.0.1 128.0.0.0. 2016.05.12 13:25:25 - OpenVPN > add net 0.0.0.0: gateway 10.4.0.1. 2016.05.12 13:25:25 - OpenVPN > /sbin/route add -net 128.0.0.0 10.4.0.1 128.0.0.0. 2016.05.12 13:25:25 - OpenVPN > add net 128.0.0.0: gateway 10.4.0.1. 2016.05.12 13:25:25 - Starting Management Interface. 2016.05.12 13:25:25 - OpenVPN > Initialization Sequence CompletedI 2016.05.12 13:25:25 - DNS of a network adapter forced (Wi-Fi)I 2016.05.12 13:25:26 - DNS of a network adapter forced (SAMSUNG_Android)I 2016.05.12 13:25:26 - DNS of a network adapter forced (Bluetooth DUN 2)I 2016.05.12 13:25:26 - DNS of a network adapter forced (Thunderbolt Ethernet Slot 1)I 2016.05.12 13:25:27 - DNS of a network adapter forced (Bluetooth PAN)I 2016.05.12 13:25:27 - DNS of a network adapter forced (Thunderbolt Bridge)I 2016.05.12 13:25:27 - Flushing DNS. 2016.05.12 13:25:28 - OS X - PF rules updated, reloadingI 2016.05.12 13:25:28 - Checking route! 2016.05.12 13:25:30 - Connected.. 2016.05.12 13:25:30 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3111. 2016.05.12 13:25:30 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
  24. dnsguy

    DNS Confusion

    I'm a little confused. IPLeak.net is showing 50 DNS servers, none of which are in the UK (where I am) and many are labeled as being in Russia. Is this all legitimate or is could there be a problem? (at least one domain is also resolving incorrectly from this connection) dnsleak shows this: 208.69.35.19 m9.ams.opendns.com OpenDNS, LLC Netherlands 208.69.35.17 m7.ams.opendns.com OpenDNS, LLC Netherlands 208.69.35.75 m57.ams.opendns.com OpenDNS, LLC Netherlands 208.69.35.65 m45.ams.opendns.com OpenDNS, LLC Netherlands 208.69.35.72 m49.ams.opendns.com OpenDNS, LLC Netherlands 208.69.35.73 none OpenDNS, LLC Netherlands 172.68.15.10 none Cloudflare Russian Federation 208.69.35.67 m17.ams.opendns.com OpenDNS, LLC Netherlands 172.68.14.207 m25.ams.opendns.com Cloudflare Russian Federation 172.68.15.34 none Cloudflare Russian Federation 172.68.14.213 none Cloudflare Russian Federation 172.68.15.94 none Cloudflare Russian Federation 172.68.15.112 none Cloudflare Russian Federation 208.69.35.76 none OpenDNS, LLC Netherlands 172.68.14.183 m29.ams.opendns.com Cloudflare Russian Federation 208.69.35.68 m61.ams.opendns.com OpenDNS, LLC Netherlands 173.194.98.10 none Google Finland 74.125.74.9 none Google Finland 172.68.14.237 none Cloudflare Russian Federation 172.68.14.231 none Cloudflare Russian Federation
  25. Hi, is there any way of setting eddie up so that it will change severs for me automatically every hour or 3 hours or to a schedule that I choose? Thanks.
×
×
  • Create New...