Clodo

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.

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.

This was an already resolved bug, does it still occur in 2.19.3?

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.

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

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

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.

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

linux .deb x64 resolved, thx, my apologies, an issue in deployment system.

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.

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

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.

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.

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

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