Jump to content
Not connected, Your IP: 54.173.43.215

Staff

Staff
  • Content Count

    10486
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1747

Everything posted by Staff

  1. Hello! We're very glad to know it! Alas, it is still inexplicable that previously it worked only for a limited time or it did not work at all, and now it works reliably. It could be something to do with how Plex picks the preferred network interface, who knows, but from lsof it was clear that it listens on all interfaces. Maybe their support team can shed some light on this strange incident. Kind regards P.S. The new lsof output is consistent with the previous one, no changes.
  2. @dalesd Hello! Please see here, it should solve the problem you reported: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/?do=findComment&comment=229914 sudo apt install mono-runtime-common Please follow the above linked thread when you have time and feel free to post any further bug you find. @user972512 reported that Eddie 2.24.1 runs fine in Pop!_OS 22.04 LTS. We will be glad to know from you as well. Kind regards
  3. Hello! The main differences between today's OVPN files and those of a few years ago: RSA key size is 4096 bit and not 2048 bit default generated profile is compatible with 2.5, 3 and 2.6 without DCO default TLS mode is tls-crypt and not tls-auth About points 2 and 3, you may force the CG to generate files for different OpenVPN versions: enable "Advanced" mode select the proper OpenVPN version, according to the one you run, on the "OpenVPN profile" combo box consider that you may select entry-IP address 1 (in place of 3) if your OpenVPN version does not support tls-crypt If the problem is related to the key size (unlikely, but we remember a similar problem some years ago on a different system, which was promptly fixed) you will need to contact the customer service. Kind regards
  4. @matteoar1 Hello! We're very sorry, we have nothing else to suggest you. Please consider to contact Plex support and community and provide them with all the information you gave us and include Plex log which can contain some precious information. Kind regards
  5. @matteoar1 Hello! Plex ignores your setting (port 63162 does not appear anywhere). From the documentation, we can infer that the "public port" is only used to announce it through Plex centralized system to clients to facilitate connections, authentication and other purposes, and then it is required that some Plex upstream (the router or system packet mangling tool) re-directs incoming packets to port 32400. Try to re-map port 63162 to your port 32400. If Plex announces to clients public port 63162, clients will contact AirVPN server IP address on port 63162 and the server will forward the packets to your Mac utun interface port 32400. Since Plex listens to port 32400 of all interfaces in IPv4 and IPv6: Plex\x20M 728 matteo 18u IPv6 0x5e8f1037afa692f5 0t0 TCP *:32400 (LISTEN) (about why lsof in BSD and Linux shows an IPv4 and IPv6 socket only as IPv6 see here) then your Plex should become reachable. In order to do so just add "32400" to the "Local" field of your remote port 63162, in your AirVPN account port panel. Kind regards
  6. Please open a new thread, this is outdated and caused by Windows and the TAP adapter driver, not Eddie. Specifically, the problem was partially reproducible with old Eddie version using TAP adapter driver and interface instead of the Wintun driver. If you find this problem with Windows 10 or 11 and Wintun driver chances are that it's a different issue, therefore worth of a new thread. If the problem occurs when you run Eddie 2.24 please feel free to add it on the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards
  7. Hello! While the system is connected to the VPN and Plex is running please open a terminal and enter the following command: sudo lsof -i -n -P | grep -i plex Then copy and paste in your next message the whole output. The method suggests enabling IP forwarding and redirecting all packets destined for Plex to the physical network interface port 32400, as if Plex were a very peculiar server unable to listen on the VPN interface. If that's the case yes, you will need that, but we refuse to think that Plex is so junky with this basic feature. Furthermore the method uses pf for packet mangling and therefore it may interfere with Network Lock, which uses pf too. According to other customers (but please note that we do not use Plex) this method is not applied in recent Plex releases and everything works as it should. Kind regards
  8. @matteoar1 Hello! At least you now know that your VPN and system settings are correct and that the VPN remote inbound port forwarding system works properly. We would like to see, while the system is connected to the VPN and Plex is running, which interface(s):port Plex listens to. How to print such info varies from system to system: can you tell us your Operating System name and version? Kind regards
  9. @matteoar1 Hello! We get a "connection refused" (error 111) when a packet is sent to your VPN client port 63162. The packet reaches your node and the connection is actively reset. It's possible that a firewall rejects the packet (instead of silently dropping it) or that nothing listens to port 63162 and the system is configured to reset any attempted connection when the destination port doesn't exist. This fact seems to confirm that the problem is with Plex. Unfortunately we can't see a reason, with the current information, to explain how it's possible that Plex works fine for some time and then stops working (maybe some firewall rule which is enforced with some delay? but this sounds like a wild speculation...). Can you please run anything else listening to VPN interface port 63162, while the system is connected to the VPN, and check what happens? Kind regards
  10. @v0e#nuy Hello! When Bluetit connection mode is set to country, Bluetit calls on domain names to get the destination server IP address (this feature is being completely rewritten and in the next versions domain names will not be used anymore). When a domain name can't be resolved the connection attempt unavoidably fails. In your situation the name resolution is impossible as the system DNS seems unreachable, and actually the DNS server address is private; it is perhaps a spurious remnant from some previous session: You can restore proper DNS settings and/or consider not relying on domain names by creating a white list of your favourite servers in Japan. When a white list of servers is created and the connection mode is set to quick (e.g. airconnectatboot quick in the run control file), Bluetit will select the best rated server in the white list. Example for bluetit.rc: airconnectatboot quick airwhiteserverlist Ainalrami,Albaldah,Bharani,Biham,Fleed,Iskandar,Okab,Taphao Kind regards
  11. @Jimmyboy52 Hello! Apparently Eddie does not follow your settings (you ordered a connection in TCP and Eddie keeps trying in UDP) therefore we suspect that the configuration file is corrupt. Please try the following procedure: make sure that Eddie is not running delete the file C:\Users\Joey\AppData\Local\Eddie\default.profile: from a command prompt enter the command del C:\Users\Joey\AppData\Local\Eddie\default.profile re-start Eddie and test again connections both in UDP and TCP Also, please test WireGuard, no matter whether the problem got resolved or not: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards
  12. @OhioStateHack Hello! Apparently either UDP or OpenVPN is/are blocked: Please check any packet filtering tool both on your router and system and make sure they do not block UDP. Also test a connection over WireGuard. WireGuard works in UDP too so you can have a first discernment. In order to switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. The line will be highlighted. click "Save" and re-start a connection to apply the change Please make sure to test a few servers in different locations around your node. Kind regards
  13. @BettyIsBoop @mnzx and anyone with the error "System.TypeInitializationException" Confirmed, hopefully this will be fixed in the next release. As a workaround for now, please install mono-runtime-common: sudo apt install mono-runtime-common @svenmaninov : Hi, it's expected. There shouldn't be any Mono dependency theoretically as it's bundled now. However, there is an issue that is being investigated.
  14. Confirmed, will be fixed in 2.24.2.
  15. Hello! Does the problem persist with the new 2.24.1 (upgrade if you haven't already done so), released after you posted the issue? If it persists, please feel free to add on the mentioned thread your report. Kind regards
  16. Version 2.24.1 with some bugfixes released. In some packages, WireGuard was not the default, fixed in 2.24.1. As soon as possible. Tray icon should be fixed in 2.24.1 Fixed in 2.24.1, same issue also for @drum Both under investigation, thank you for your tests and patience! Under investigation, thank you for your tests and patience! Kind regards
  17. @BettyIsBoop Can you please post your message in the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ It's the thread followed by devs for bug reports on 2.24. Thank you in advance! Kind regards
  18. @Tavvy This error related to the virtual interface tun0 did not occur with Eddie 2.21.8, can you confirm? Please feel free to add your message (or we can do it for you) to the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ where bugs discovered by the community are reported, thank you very much. In any case we will highlight your report to developers. Kind regards
  19. @Moneytinker Hello! For an explanation and a quick solution please see here: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 Kind regards
  20. Hello! Currently, we have no plans for Obsfproxy: throughout the years we have been very focused on leaving the need for this kind of obfuscation to the Tor network (in which we have invested a lot of time and resources), but we may consider it in the future. Kind regards
  21. Hello! The explanation that comes to mind is that you ran OpenVPN without DNS management (in Linux and FreeBSD OpenVPN doesn't manage DNS by itself), while Eddie by default works to avoid any possible DNS leak (outside the VPN tunnel) and use VPN DNS only. If you accessed shares or any other local resource via hostnames unknown to VPN DNS but known to your local DNS the described problem is explained. It is anyway possible to configure Eddie to use any DNS you like or not to touch the DNS settings of the machine. Kind regards
  22. Hello! Please test Eddie 2.24: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Eddie features support with proper DNS management for every systemd-resolved (a ramshackle systemd component that would have the ambition to offer name resolution to applications) mode from version 2.23.2. Previous versions do not handle correctly a specific systemd-resolved working mode which will cause DNS leaks. If you're running some older Eddie version, including the current stable release, and your Mint has systemd-resolved running and working in on-link mode bypassing /etc/resolv.conf, we may have a rational explanation of the situation. However, the discrepancy between https://ipleak.net and the web site you mention remains unexplained. Kind regards
  23. Hello! Chances are that your system DNS settings are incorrect. Please check and make sure that, while Eddie or any VPN program is not running, the system can use publicly available DNS servers. We recommend Quad9 (9.9.9.9) and OpenNIC for their commitment to privacy and neutrality. Kind regards
  24. Hello! We were easy prophets in this case. The catastrophic blackout referred to in the article is a concrete example of the risk we denounced, a violation of fundamental rights, a confirmation of the wisdom of our decision and a demonstration of the irresponsible and odious frivolity of decisions taken by private actors. Our infrastructure must not be polluted by repugnant decisions taken by private entities that seem to have little or no technical competence and that, so far, enjoy impunity for any mistake, no matter how serious. Kind regards
  25. Thank you for your tests! @Clodo may clarify this event. Also, does Eddie keep connecting over OpenVPN when you log your account out and in again? Kind regards
×
×
  • Create New...