Jump to content
Not connected, Your IP: 52.3.228.47

Clodo

Staff
  • Content Count

    397
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    23

Everything posted by Clodo

  1. This is a known incompatibility problem between Eddie and the latest beta of OpenVPN2.5, it will be fixed in the next beta release, sorry you can only wait for now, we have other issues under investigation before releasing.
  2. It is not mandatory to wait for next Debian version: we are already testing up to date WireGuard version. When we'll make WireGuard available to customers, it will be on all servers. Exactly, it's unavoidable. With OpenVPN that's currently correct. However, with WireGuard we need to keep it, because it's written in .conf file generated via Config Generator and stored by users. See below for users' option to change or invalidate it. Some of our competitors do this. Some accept only their official client software because of the issue. That's neither good nor acceptable for us, as we don't want to lock user into our software. Therefore the change you mention might be an Eddie's additional feature but we will try to make Wireguard main branch as secure as Eddie's, whenever possible. Yes, we still use ifconfig-pool-persist in OpenVPN. It's very different than Wireguard's addresses binary mapping, especially under a legal point of view. When a client is connected, OpenVPN daemon necessarily needs to link clients' public and VPN IP addresses. As soon as the client disconnects the link is lost. One of WireGuard controversies is that client's real IP address remains visible with 'wg show' even after client's disconnection. The issue is resolved by removing and re-adding the peer after a disconnection (disconnection in WireGuard is basically a handshake timeout). Some current testing implementation features are: Unique WireGuard IPv4 and IPv6 subnets across servers which don't conflict with OpenVPN subnets Assigning a non-conflicting, pseudo-random, local IP address for each customer's device (for AllowedIPs), similar to remotely forwarded port assignments Users can renew a local IP address for a device anytime. WireGuard .conf manually used in official client would become invalid. Eddie will automatically update. The same happens when a user regenerates OpenVPN client certificate and key pair: the action invalidates any previously stored OpenVPN profile. We will offer an API to automate the above, letting users write a script that performs HTTPS calls to change local IP address, download updated .conf, and then wg-quick. An API to obtain a .conf file (Config Generator without UI) is already in production for OpenVPN and it will be of course available for WireGuard too. When a device's WireGuard local IP address changes, up to a 10 seconds wait is required. It's the time required to propagate device key onto all VPN servers, in order to update the AllowedIPs peer node. No other solution allowing us to let our customers use the official WireGuard client with a simple .conf file and, at the same time, preserve their privacy currently exists. Please keep the above information as a proposal: we are currently studying pros and cons and something may change before WireGuard public beta support in our VPN servers is available.
  3. This was an already resolved bug, does it still occur in 2.19.3?
  4. Yes thanks, if it is reproducible, enable in Preferences -> Logs both 'Log Debug' and 'Log on File'. Here or open a ticket if you prefer, thanks.
  5. Can you provide the exact message error? During development, sometimes we encounter a mystic "error -47", but it can't be related to Eddie because it disappears with a reboot. Still under investigation. Same as above, when you reboot does the issue disappear? Thx
  6. @Maggie144 has a specific macOS bug that will be fixed soon. @colorman, Linux, If you tick Preferences -> Advanced -> Use Hummingbird, Eddie will search for Hummingbird executable in environment paths. Otherwise a path can be set with option "--tools.hummingbird.path=/path/to/...". Sorry, no UI right now, it will be available in 2.19.3. But remember: you need to ensure "chmod +x /path/to/hummingbird" AND "chown root /path/to/hummingbird". An Eddie security protection requires root ownership.
  7. We hope to release 2.19.3 probably tomorrow, it fixes the "Unable to obtain elevated privileges (required): Object reference not set to an instance of an object" issue. Of course with Hummingbird updated. Please be patient, thx.
  8. Can you post a screenshot of the error by 2.19.2? Thx If you want to test, older 2.19.0 portable version for macOS is here
  9. linux .deb x64 resolved, thx, my apologies, an issue in deployment system.
  10. We cleaned the above post on Linux build crash for simplicity's sake. We have detected the issue and we are working to resolve it.
  11. Version 2.19.1 (Sat, 18 Apr 2020 11:14:36 +0000) [bugfix] Linux - Fix issue with Network Lock IPv6-only incoming whitelist [bugfix] - http-100-continue issue [bugfix] - Special condition elevation checks (may resolve "Unable to start (no-socket)" issues). [change] - Removed curl binary dependencies [new] Linux - New Network Lock with nftables (if nft is present, it is used by default in "Automatic" mode) [new] Windows - New option "Use wintun driver (OpenVPN>=2.5)" under "Preferences -> Advanced" automates ovpn directive
  12. Without, "windows-driver wintun" without quotes. The stable 2.18 includes the same tapctl.exe of OpenVPN, and runs automatically the "tapctl.exe create --hwid wintun" if no wintun adapter is available. But we know there are some issues under investigation.
  13. A new beta version released here addresses an urgent issue on older macOS and Custom DNS under Windows. Other feedback is under investigation. Thanks to all.
  14. No, sorry. You need to be able to download the 2.18.9. What package? .deb ? what you mean with "18%", apt-get ? curl? your browser download? You can try other kind of package, like portable or AppImage? Thx
  15. The download 2.4.8 installer for Windows 7/8/8.1 from OpenVPN website has exactly the same tap-windows.exe (575288 bytes) of Eddie 2.18.9 Windows 7/8. The issue is anyway under investigation, thanks
  16. Confirmed, will be fixed as soon as possible.
  17. Yes, my fault, forgotten to update when deploy an urgent fix, hash recomputed now. Thx.
  18. Honestly, no... We use the original wintun packaging/deployment, and the original tunctl.exe from OpenVPN for creating adapter, but there are a lots of issues in a lots of Win version (never uninstall, fail to create adapter etc).... We are working on testing to identify all the issues related to new wintun driver, please be patient.
  19. Cannot reproduce. Maybe you clicked the "Name" column header? Try to click the "Score" column header. If the issue still occurs, please provide a screenshot to understand, it's the first time we see this issue. Thx.
  20. I personally tested 2.18.8 with rPI4-raspbian-buster without any issue (with sudo or without). I think your issue is somehow specific, so i write to you a private-message to understand and fix. Please continue in PM, thx.
  21. OT: Thank you 😘. I live in Lombardia, the epicenter. It's a disaster here.
  22. Great to know it works as expected. I think you also manually add the directive "windows-driver wintun", in next version this will be automatic if wintun driver is detected. Thx of the feedback, i will check this.
  23. We updated the Windows build (without changing version number) to identify better the following issues (Windows only): - Unable to find driver path 'C:\WINDOWS' - Fixed - VCRUNTIME140.dll (reported by @rdbrn) - Fixed - Options error: Unrecognized option (reported by @Telos , @kiwi, @blaHbluBB) - Fixed
  24. I confirm this issue. It doesn't happen every time. When it happens, it's infinite and you need to manually press key N. It will be fixed soon, sorry.
  25. Hi to all, the latest Eddie 2.18.8 experimental released today, works with wintun, please test if interested. Go to https://openvpn.net/community-downloads/, at bottom "OpenVPN 2.5_git wintun technology preview", click the "here" link and install. If you already have the right "openvpn.exe", use it directly: Eddie will install the wintun driver when needed, and also create the adapter. Eddie -> Settings -> Advanced -> OpenVPN Custom Path -> choose your "openvpn.exe" from 2.5, if already installed probably it is "C:\Program Files\OpenVPN\bin\openvpn.exe". At this point, Eddie will use OpenVPN 2.5 (but still with standard TUN driver). Eddie -> Settings -> OVPN directives -> Custom directives, add "windows-driver wintun". At this point, Eddie will use the OpenVPN 2.5 with the newest Wintun driver.
×
×
  • Create New...