Jump to content
Not connected, Your IP: 54.174.225.82

Staff

Staff
  • Content Count

    9294
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1398

Posts posted by Staff


  1. Hello!

    We inform you that the following servers in Latvia:

    • Meissa
    • Phact
    • Schedir
    • Shaula

    have become suddenly nonoperational because the upstream of our provider blocked all traffic. They should come back online within a couple of days, due to new deals with a new transit provider. However, all IP addresses will change. We have decided that this is a good moment to switch to new lines and servers: we are changing the previous 100 Mbit/s lines with 1 Gbit/s lines and ports, and replacing the hardware with more powerful CPU. The four 100 Mbit/s servers will be replaced by three 1 Gbit/s servers. Location will not change, the new servers will be in Riga.

    We should be able to announce the new servers in the next days.

    Kind regards and datalove
    AirVPN Staff
     

  2. @organicchocolate

    Hello!

    Thank you very much for the good feedback, we're glad to hear it.

    About Network Lock, the status is reported by the padlock on the main window. If it's closed, Network Lock is enabled. A connection must be possible even with Network Lock disable, so the green token you mention is appropriate. Maybe you'd prefer to have Network Lock on by default. You can configure Eddie to enable Network Lock when the app starts. AirVPN Suite enables Network Lock by default.

    Kind regards
     

  3. 16 hours ago, traffic_22 said:
    Indeed that seems to be the case. Looking forward in time, I guess this could be something AirVPN could improve/add in the future.
    My use case is the following: The VM is running on a server at a hoster. The hoster does not provide free IPV4s, only IPV6 /64 subnets. I did not want to have to pay for an extra IPV4 anymore (and this problem won't get better due to the increasing scarcity of IPV4 addresses) - so I had to assign the VM an IPV6 only.

    Hello!

    You are definitely right. Historically, this is a consequence of the fact the our bootstrap servers were not given by the respective datacenters IPv6 support and we did not insist on that. We will ask our providers to add IPv6 support to the bootstrap servers if possible, and then adapt our software accordingly when IPv6 layer is preferred over IPv4.

    Kind regards

    P.S. You applied a smart workaround!
     

  4. @TheHellSite

    Hello!

    A dedicated forum might be excessive, but dedicated threads are surely appropriate. The official thread followed by staff members can be found in the "News" forum, which is not a community forum. Any other thread can be created by the community in the proper community forum ("Troubleshooting" is fine) and followed by the community as usual.

    Kind regards
     

  5. @hartfieldsbane

    Hello!

    Can you please check the content of directory /etc/airvpn and post here?
    sudo ls /etc/airvpn

    A plausible explanation of the wrong behavior is that the lock file doesn't exist in /etc/airvpn, while some backup file related to firewall rules or DNS settings does. EDIT: bug confirmed, we will work to fix it.

    You can resolve immediately the problem by deleting the whole directory content, but first please publish its content to let us check and reproduce the issue, thank you! A bug causing a similar problem was already detected by @misam in this thread in late 2020. It was fixed in your version 1.1.2, but maybe something is still wrong. Please post text and not screenshots when possible.

     
    sudo rm /etc/airvpn/*
    Kind regards
     

  6. @eburom

    Thank you very much!

    The problem you found and kindly reported has been fixed and you'll see the fix in the next, imminent version.

    From the developer: you can't build the Suite now because OpenVPN3 has recently changed ClientAPI::Config definition. They replaced member ipv6 with allowUnusedAddrFamilies which is basically used for the very same purpose. The change has been already imported into OpenVPN3-AirVPN 3.7.1 fork and Bluetit/Hummingbird code has been updated accordingly in the development branch which is to be released very soon, along with some other minor fixes and changes [including the aforementioned one}.

    Kind regards
     

  7. 2 hours ago, spinmaster said:
    Just wondering: did you ever find out anything new to this error? I saw this error (or is it more a "Warning" ?) already on Big Sur and was hoping it would vanish under Monterey, but it's still there. Can you confirm that from a user perspective, these messages in the Log can simply be ignored?

    Hello!

    No news, we're sorry, but let's evaluate whether the default buffer size of the UDP/IP stack is insufficient for OpenVPN3-AirVPN needs. Can you please give us the output (from a terminal) of the command:
    sysctl kern.ipc.maxsockbuf
    It will show the buffer size in bytes. We would like to compare it with our systems (Big Sur and Catalina, M1 and x86-64) where the problem doesn't occur, and check whether increasing the buffer mitigates it.

    Kind regards
     

  8. @Xuebit

    Hello!

    We tried to reproduce the problem you reported but we failed. After we activated "cryptojacking" block list and entered getmonero.org among the allowed exceptions, we could determine that it was resolved correctly. Please try again, maybe your system and/or system browser cached DNS. You can debug with
    dig getmonero.org 

    We rarely edit a list; "curated by us" doesn't necessarily imply that we edit a list, but that we select and propose it or a merge of different lists, aiming at covering all the most requested categories. Therefore you might like to ask the original compiler the reason why getmonero.org was included. We see that also bitcoin.com is included in the same block list. That said, we can of course edit those "curated by us" lists: while a regular review of each list by us is not realistic at all, we keep this option open for your and other users observations.

    Kind regards
     

  9. @mrbert

    Hello!

    Unfortunately we don't understand the issue, therefore we recommend you open a ticket. About your last question, the DNS query should be tunneled so it should not go straight to Google, but anyway make sure that Network Lock is enabled. Anyway, you should not pick Google DNS in any case. Good DNS which respect your privacy are OpenNIC https://www.opennic.org and Quad9 (9.9.9.9).

    Kind regards
     

  10. @Xuebit

    Hello!

    Thank you very much for the head up. The fact that the exception you entered doesn't work is unexpected, we will start an investigation because it might be a bug. The potential error about getmonero.org will be investigated as well.

    Kind regards
     

  11. Hello everybody,

    can you please re-perform all of your tests and report back? We have found a bug which potentially might have caused the reported names resolution failures and we have fixed the code. Please let us know whether the problems keeps occurring or not, as our automated DNS testing sentinels deployed on several flag servers have stopped reporting resolution failures since when the fix was applied. A couple of hours ago the fix has been deployed on all the VPN servers.

    We are looking forward to hearing from you.

    Kind regards
     


  12. 2 hours ago, apero said:

    So just to be clear; this still doesn't work for the Android "TV" versions for v10+, correct?

    At least, I can't get it to work, unfortunately.

    Hello!

    We confirm that it's not possible for Eddie to start during the bootstrap of any un-rooted device running Android TV 10, 11 and 12, and this is not an Eddie-specific limitation, simply because "Always on VPN" has become mandatory for the purpose, but at the same time Android TV has always had this feature removed.  Should we find a solution to circumvent this deliberate limitation on un-rooted devices, we will be willing to implement it, but at the moment we are not aware of any solution. OpenVPN connect, OpenVPN for Android and other apps undergo the very same limitation.

    Kind regards
     

  13. @rubicon789

    Hello!

    From the Android settings pertaining to apps, please review your OpenVPN app permission and make sure that access to storage is granted (do the same with WireGuard app if necessary).

    Also consider that when you run Eddie Android edition you are not forced to generate and import ovpn files to connect to our service (ovpn files remain optional). https://airvpn.org/forums/topic/29660-using-airvpn-with-eddie-client-for-android/

    Kind regards
     

  14. @PortlyNinja
    @tgiby3

    Hello!

    Each time you renew your client key and certificate in your account "Devices" panel you need to log your account out and in again from Eddie main window, as you might have read in the instructions. In this way you force Eddie  to download the new pairs. If Eddie sends an expired certificate you will get AUTH_FAILED from the VPN server, and not form the infrastructure, so no message is visible in the Client Area, in spite of the wrong suggestion by Eddie, we're sorry.

    The TAP driver is the driver which handles the virtual network interface used by OpenVPN. Only administrators, according to system default settings and ordinary practice in the last decades, can install system drivers. Windows lacks any such driver so it needs this additional installation of some third-party tun/tap driver for the tun/tap interfaces .The wintun driver, which is supported by OpenVPN 2.5 and higher versions, and by Eddie, is a more modern driver to drive the tun/tap interfaces. If you have issues caused by the TAP driver, including poor performance, try the wintun driver. You can activate it from Eddie's "Preferences" > "Advanced" window: check "Use wintun driver", click "Save" and re-start Eddie.

    Kind regards
     

  15. @UndeN

    Hello!

    Please check your ticket before going on with the discussion, it looks like you ignored the answer by the support team member who should have found the fault in your configuration (executive summary: you did not forward remotely port 44158 form your AirVPN account control panel). Also, as a moderator already told you, please do not hijack threads, you already opened your own on the matter, keep the discussion there. By following simple rules and moderator directions you will improve forum readability. Thanks in advance.

    Kind regards
     

  16. @Karmatron

    Hello!

    You failed to follow the guidelines in your last messages. When you do so you don't help us effectively. Please follow the guidelines before publishing in this thread, thank you in advance.

    About asnbank.nl we agree, the situation is probably caused by a block by the bank against VPN, Tor etc. and this event is alien to the topic issue.

    Kind regards
     

  17. Hello everybody!

    Some guidelines to help us investigate, as we have failed to reproduce the issue. When you experience the problem please report here all the following information:

    • the fully qualified domain name you could not resolve
    • the server you were connected to
    • the connection mode and protocol (some OpenVPN mode or WireGuard)
    • the DNS block lists you had active, if any
    • the complete output of the command dig or nslookup pertaining to the "problematic" domain name
    Kind regards
     

  18. @mariusffm

    Hello!

    Which is exactly the prime time you mention, when you notice higher round trip times? This is what we currently see from various NL servers (cut to the first entries) to and from a bunch of our servers (even non-VPN servers) in other datacenters served by different transit providers. It's very good for a Saturday night in Europe (ignore the duplicates like "Dublin" and "Ireland", it's just how our monitoring system organizes the outcome). Consider that such tests are performed every other minute so we can have a fine grained report and if you point us to the prime time we can see whether something is wrong (so far we have not detected peculiar problems).

    Kind regards
     
     
    nl.png Alblasserdam 0 ms
    nl.png Noord-Holland 1 ms
    nl.png Amsterdam 1 ms
    nl.png Haarlem 1 ms
    fr.png France - Roubaix 6 ms
    fr.png Ile-de-France 6 ms
    de.png Berlin 7 ms
    fr.png France - Gravelines 7 ms
    de.png Germany 7 ms
    de.png Frankfurt 8 ms
    gb.png London 10 ms
    de.png Munich 14 ms
    ch.png Bern 15 ms
    gb.png Manchester 15 ms
    ch.png Zurich 15 ms
    ie.png Dublin 17 ms
    ie.png Ireland 17 ms
    lv.png Riga 18 ms
    cz.png Prague 19 ms
    at.png Vienna 22 ms
    se.png Stockholm 22 ms
    rs.png Belgrade 24 ms
    se.png Uppsala 27 ms
    es.png Madrid 27 ms
    es.png Barcelona 27 ms
    no.png Oslo 28 ms
    lt.png Siauliai 29 ms
    ro.png Bucharest 30 ms
    it.png Arezzo 31 ms
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
×
×
  • Create New...