Leaderboard

Hello! On server side, we use OpenVPN 2.5 to support ChaCha20 on the Data Channel, so any server with OpenVPN 2.5 will be marked as "Experimental", to make clear that the OpenVPN running in it is a beta version. As soon as OpenVPN 2.5 stable is released, all the servers will be upgraded to support ChaCha20 on the Data Channel without the "Experimental" warning. Our next, imminent step is releasing Eddie Android edition with OpenVPN 3 supporting ChaCha20-Poly1305 to allow immediate testing from those devices based on Android that need ChaCha20 most, for performance and load reasons (such as any Android tablet, smart phone, Amazon Fire TV and any other Android based mediacenter using a CPU that does not support AES-NI). Kind regards

Hello Staff and All, Is Netflix still working for you, please? Unfortunately it doesn’t work for me. I am using Eddie on Win machine for my connections, VPN DNS and have no leaks which I checked on ipleak.net. I have a Netflix account created in one of EU countries but according to previous comments that should not affect connection. I first used Netflix about a month ago and it was working relatively fine. I got occasional Streaming error due to proxy... but refreshing the page solved it and streaming continued. It is a different story now. I have tried to connect from quite few US, UK, NL, SE… servers but I always get the same known Streaming error: You seem to be using an unblocker or proxy… and no matter what I try I cannot pass that. Interesting is that from some servers it started to stream the content but that worked for only few minutes then it stopped (sorry, I haven’t mark down specific servers). It looks like it is buffering but it never does and once I refresh the page I get the above mentioned error. When I login to Netflix account I can see the following IP addresses as the ones used by my streaming activity: Maryland (US) - 12.139.254.67 Virginia (US) - 65.220.84.18 Maryland (US) - 12.139.254.82 Maryland (US) - 12.139.255.63 Maryland (US) - 12.139.253.52 Does anyone have any suggestions what could be causing this and how to fix it, please? Thank you.

This started happening few months ago on my Mint 19.1 running kernel 4.15.* I thought it was triggered by one of the kernel updates, but could not resolve it. Running Eddie 2.16.3, I updated to 2.17.2, but it was the same behavior and could not get it to apply network lock via new feature (build iptables-save format and apply directly), it just worked the same as 2.16.3. So I downgraded back to 2.16.3 and when playing around with it, I disconnected computer from network (WiFi) which I normally never do. I noticed that in this state, the network lock would be applied in under 10 seconds, compared to 180 seconds when computer is connected to WiFi.

Hello, since 2017 we've been contributing to run about 5-7% of all the worldwide Tor traffic through exit-nodes maintained by Quintex Alliance, please check our mission page. Kind regards

Reporting in with another replication of this error on latest Manjaro (XFCE). Also, due the network lock not working correctly, some of the rules persist after the end of the session, which causes connection issues in the local network.

I can also confirm this problem with a clean (and updated) Manjaro KDE installation. With the Network lock enabled at start-up, Eddie executes a large number (at least 1000) of iptable commands, each taking over 300ms. Whilst it is applying these commands, I cannot connect to a server, I cannot de-activate the network lock, and I cannot close eddie. Basically, eddie becomes unresponsive and unusable, and I have to reboot the system I am using 2.17.2 (but have also tried the latest stable). Thanks for any help/advice. (By the way, all is well on Debian Stable and Mint 19.1).

Yes, this happens to me also, but I didn't notice it until now since I almost never reboot my NAS, and I have reconnect script which detects that VPN isn't working and restart it. I think this is Synology VPN implementation bug, it should be reported to them. Hopefully they can fix it in new updates.

About AsusWRT AsusWRT is a unified firmware developed by Asus for use in their recent routers. The firmware was originally based on Tomato-RT/Tomato-USB, but has since seen many changes. Asus started using this new firmware with their recent routers (RT-AC68U, RT-AC87U), but they also started moving other routers to this new firmware. Prerequisite Asus Router with AsusWRT (native OpenVPN support). Model tested: RT-AC68U but it should work for all Asus routers that have AsusWRT. see Official website for AsusWRT model support list. [Firmware Notes]: Please upgrade the router Firmware to the latest version. "New Asus Firmware supports 4096 bits key and will work with AirVPN." Steps 1. Create configuration files from our Config Generator. Select [Router or others] and choose a server you like. Tick on [Direct, protocol UDP, port 443] and click on [Generate]. Save the openvpn config file .ovpn (Ex: AirVPN__UDP-443.ovpn) anywhere on your computer. 2. Open the Asus router webinterface and click on [VPN]. Click on [Add profile], choose [OpenVPN] tab. Enter a "description", leave username and password EMPTY. Click on [browse] and select the downloaded openvpn config file (.ovpn). Click on [upload]. Click on [OK]. That's it now you can click on [Activate] to connect to AirVPN server. 3. Make sure to setup the AirVPN DNS this way: Click on [WAN] tab. Turn [DNS server] "off" (No) and enter AirVPN's DNS 10.4.0.1 as first DNS IP address (it's DNS for Protocol UDP, Port 443 - see Specs for more details). About the secondary DNS entry, we recommend picking ones from the OpenNIC Project. The AirVPN DNS will enable you to access AirVPN geo-routing services to bypass discriminations based on IP address geo-location. 4. Visit https://ipleak.net and check whether it works. Every client (PC, Smartphone, Console, Smart TV ..) which is connected to the router now is secured by VPN and also has full access to the anti-geo-blocking service. Useful Info A custom firmware for Asus routers based on official AsusWRT called Asuswrt-Merlin is available. AsusWRT-Merlin retains all the features of the original stock AsusWRT firmware with added/enhanced features. More info on AsusWRT-Merlin website http://asuswrt.lostrealm.ca/features

Wow, good idea! Will add it. Not sure why you added other part? If VPN is off, current script will start it (when cronjob runs). If VPN is ON, but it's in error state (not letting traffic trough) it will kill VPN and start it again. EDIT: Added your contribution to tutorial. Changed some parts of tutorial. You no longer need to copy script to /usr/ folder. It's better if it stays in shared folder of your choice since there it will survive system upgrades.

Hi Mikeyy, hope they will fix it. I found a workaround which fixes the problem for me. I deleted those three lines in client_oxxxxxxx file: up /usr/syno/etc.defaults/synovpnclient/scripts/ovpn-up route-up /usr/syno/etc.defaults/synovpnclient/scripts/route-up plugin /lib/openvpn/openvpn-down-root.so /usr/syno/etc.defaults/synovpnclient/scripts/ip-down Now the client starts and connects at startup without any problems. It now looks like this: # -------------------------------------------------------- # Air VPN | https://airvpn.org | Tuesday 12th of July 2016 03:54:03 PM # OpenVPN Client Configuration. # AirVPN_xxxxxxxxxxxx_xxxxxxx_UDP-443 # -------------------------------------------------------- client dev tun proto udp remote xxx.xxx.xxx.xxx 443 script-security 2 redirect-gateway resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server cipher AES-256-CBC comp-lzo no verb 3 explicit-exit-notify 5 rcvbuf 262144 sndbuf 262144 ca ca_oxxxxxxxxxx.crt key client_key_oxxxxxxxxxx.key cert client_crt_oxxxxxxxxxx.crt tls-auth ta_oxxxxxxxxxx.key Greets