Jump to content
Not connected, Your IP: 44.215.110.142

Staff

Staff
  • Content Count

    10486
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1747

Posts posted by Staff


  1. 7 minutes ago, matteoar1 said:

    Thank you @Staff for your support. I was writing a support request to Plex staff and I noticed that now it seems to work. I didn't change any setting in Plex and in AirVPN port forwarding panel. Maybe I only had to wait (?) 😅. I'm hoping that now will it work properly "forever" but in the case it will not I'll know that it doesn't depend on AirVPN.


    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. 20 hours ago, blaqreign said:

    've tried all kinds of ways to try to get it working, but it just won't accept the .ovpn file. What's odd is that I found an ovpn file from several years back and it worked just fine, but the vpn server is no longer active.


    Hello!

    The main differences between today's OVPN files and those of a few years ago:
    1. RSA key size is 4096 bit and not 2048 bit
    2. default generated profile is compatible with 2.5, 3 and 2.6 without DCO
    3. 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!

    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
     

  5. 1 hour ago, sinthome said:

    It seems this issue is still unresolved. I had the same problem this morning with the most recent version of Eddie on Win11. I did the cmd prompt reset, restarted and it is working again.


    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
     

  6. 1 hour ago, matteoar1 said:

    I'm running on a Mac mini with M2. My OS is macOS 14.3.1 (23D60) (Sonoma).
    Thanks for your help.


    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.
     
    1 hour ago, matteoar1 said:

    I see that someone suggest to use this method. I'm not a pro user, I don't know what these steps do. Do you suggest to follow this method?


    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
     

  7. @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
     

  8. @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.
     
    2 hours ago, matteoar1 said:

    I can access to my library externally with no problems but after a few seconds It won't work.


    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
     

  9. @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:
    Quote

    Mar 02 13:54:41 bluetit[715]: Allowing system DNS 10.26.126.1 to pass through the network filter
    Mar 02 13:54:43 bluetit[715]: AirVPN Manifest successfully retrieved from server
    Mar 02 13:54:51 bluetit[715]: ERROR: Cannot resolve jp3.vpn.airdns.org (Temporary failure in name resolution)


    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
     

  10. @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
     

  11. @OhioStateHack

    Hello!

    Apparently either UDP or OpenVPN is/are blocked:
    Quote

    . 2024.03.02 16:33:16 - OpenVPN > write UDP: Unknown error (code=10065)
    . 2024.03.02 16:33:16 - OpenVPN > write UDP: Unknown error (code=10065)
    . 2024.03.02 16:33:16 - OpenVPN > write UDP: Unknown error (code=10065)
    . 2024.03.02 16:33:16 - Above log line repeated 10 times more


    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
     


  12. @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.


  13. On 2/27/2024 at 7:36 PM, Viaica said:

    On Xubuntu LTS 22.04 the log is getting spammed with "DNS of the interface 'Eddie' switched to VPN DNS - via systemd-resolved" message. Same thing happened on the previous beta which I posted on the older thread:


    Confirmed, will be fixed in 2.24.2.

  14. Version 2.24.1 with some bugfixes released.

     

    On 2/26/2024 at 6:46 PM, spinmaster said:

    Thanks for clarifying! I made a few tests on a few different servers with connection mode "Automatic" and for all them, the previous default protocol & port (OpenVPN 443) was chosen. In which cases uses the bootstrap server manifest file WireGuard over OpenVPN?


    In some packages, WireGuard was not the default, fixed in 2.24.1.
     

    On 2/26/2024 at 6:53 PM, ersatzzz said:

    Any idea on when there will be a new STABLE release? Assuming you're using semantic versioning, we've skipped past a 2.22 and 2.23 stable release, and we're still stuck at 2.21.8.


    As soon as possible.
     

    On 2/27/2024 at 2:31 AM, MarkDubya said:

    I installed the Arch package and there is no tray icon. It seems the PNG icons are missing from /usr/share/eddie-ui/.


    Tray icon should be fixed in 2.24.1
     

    On 2/27/2024 at 1:33 PM, zsam288 said:

    1.png.af860a93e6f5ca1a6b650e23d8a06a41.png
     


    Fixed in 2.24.1, same issue also for @drum
     

    22 hours ago, Viaica said:

    On Xubuntu LTS 22.04 the log is getting spammed with "DNS of the interface 'Eddie' switched to VPN DNS - via systemd-resolved" message.
    Another issue is that minimize to tray still does not work like it hasn't worked for a while.


    Both under investigation, thank you for your tests and patience!
     

    5 hours ago, BettyIsBoop said:

     

    
    $ eddie-ui 
    [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception.

    Under investigation, thank you for your tests and patience!

    Kind regards

     

  15. @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
     

  16. 15 hours ago, cspr said:

    Thank you for your answer and informative article, I am new to VPNs so am not sure what to expect performance-wise.
    Any plans on integrating Obfsproxy? :D


    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
     

  17. 6 hours ago, Zarkov said:

    Edit: All good now.  I figured out how to do this through my router.  Generated the OpenVPN file and all connected.  No more Mr Eddie.


    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
     

  18. 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


  19. 10 hours ago, tranquivox69 said:

    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
     

  20. 1 minute ago, spinmaster said:
    Thanks for clarifying! I made a few tests on a few different servers with connection mode "Automatic" and for all them, the previous default protocol & port (OpenVPN 443) was chosen. In which cases uses the bootstrap server manifest file WireGuard over OpenVPN?

    I may leave it on WireGuard personally in Eddie as it feels a little faster than OpenVPN, but overall stability is more important for me than speed or a few extra MBit and as I said, OpenVPN worked also just fine so far.

    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...