Also: holy hell, that's fast! I'm connecting to the AzireVPN wireguard server in the UK. www.speedtest.net results are a 10ms ping with 368Mb/s downstream speed, and 20.17 upstream. With no VPN connection I can hit 390Mb/s downstream, but that kind of slow-down is essentially invisible. Ping and upstream are unaffected.
By contrast, using OpenVPN over TCP, I get around 150Mb/s downstream, with a 16ms ping. (And for some reason OpenVPN over UDP is even slower, my ISP doesn't seem to like it).
Router CPU core 1 hits 94% during the speed test, core 2 gets to about 75%; so I'm not sure if it's even quite hit the router's limit. Very impressive.
It really would be great if there were a more "official" way of doing this.
Curious how this is working out for you.
Have you tried the script someone over on the Merlin side came up with to further tweak QoS, and if so, has it made any difference for you?
I'd be interested to see what %age of their customers are running it...5 VPNs now, and some of the top/best/most popular ones at that, but it's probably still a niche/cool kids thing
Hmm.. well then you have finally got the same problem as I had. I'm wondering whether this problem has to do with a firewall restart? Did you see anything in your router logs whats going on at the time the VPN stopped working? I was thinking about entering the commend written in the first post, as a script so Wireguard is restarted once the firewall is restarted. Don't know whether this helps.
I'd be interested to see what %age of their customers are running it...5 VPNs now, and some of the top/best/most popular ones at that, but it's probably still a niche/cool kids thing
1) OpenVPN is probably the most in use by a long shot - mostly due to heavy advertising by the VPN Service Providers and the portable nature of the OVPN stack... and even OVPN seems to be working to commercialize/monetize the stack there..
Just too bad that performance is a bit of a challenge with OVPN, but it is damn secure, no doubt, properly configured and all..
2) Shadowsocks - probably number 2 - because of the Great Firewall - size matters, and the mainland is what it is...
3) Wireguard - creeping up, as we get more client platforms now...
4) ZeroTier - this might be the one to keep an eye on - concept wise it's a bit different, as it's an SD-WAN approach - which is a different step, and takes a mind readjustment perhaps to understand what their doing...
Obviously we have legacy and proprietary approaches as well - legacy like PPTP (should just go away, except that's it fast, and private enough for some uses (not everyone in a coffee shop is a blackhat)), and then the business oriented stuff like AnyConnect from Cisco (and similar from Juniper, etc...)
Standalone stuff like L2TP/IPSec - which is supported by many OS's on the client side, is still relevant...
Most interesting stuff to me these days is Wireguard and ZeroTier...
Shouldn't really make any differences. There are no big changes between Merlin's BETA and Stable firmware versions, mainly just small bugfixes.
Will try to update during the next days and make some new tests then.
Then I activated WireGuard again, and was running the same test. - You see the speed is even faster then without VPN/WireGuard. Also it is hitting again over 600 Mbit/s several times.
The transfer speed is even faster while having WireGuard activated than while running with just my native internet connection without VPN/WireGuard.
So I think the results are very much related to the performance of the iperf3 servers as well.
For using Route=policy, wg-policy script has some rules.
Adjust to your situation.
Default table is 117.
nano /opt/etc/wireguard/wg-policy
Code:
#
##For ipset based Policy Routing
#
#ipset -N $Nipset hash:ip
#ip rule del prio 9997 2>/dev/null
#ip rule add fwmark 0x7000 table 117 prio 9997
#iptables -t mangle -D PREROUTING -m set --match-set $Nipset dst -j MARK --set-mark 0x7000/0x7000 2>/dev/null
#iptables -t mangle -A PREROUTING -m set --match-set $Nipset dst -j MARK --set-mark 0x7000/0x7000
#service restart_dnsmasq
4. as Server configuration setting.
Code:
(umask 077 && printf "[Interface]\nPrivateKey = " | tee /opt/etc/wireguard/wg1.conf > /dev/null)
wg genkey | tee -a /opt/etc/wireguard/wg1.conf | wg pubkey | tee /opt/etc/wireguard/server-publickey
Generator script will generate QRcode image for Android or iOS.
You need to install qrencode first.
Code:
opkg install qrencode
If you want to use your host address (192.168.50.1) as DNS server,
you have to add wg interface to Dnsmasq listening interface list.
Code:
sed -i '1s/^/interface=wg* \n/' /jffs/configs/dnsmasq.conf.add
service restart_dnsmasq
This script will ask you 3 options.
1. client name 2. client address 3. client DNS server
-------------------------------------------------------------------------
WireGuard use iptables so when the firewall is restarted, the rules will gone.
Please add this in nat-start script.
nano /jffs/scripts/nat-start
Code:
WVPNROUTE=`ip route show | grep -i -a "dev wg"`
logger -s -t "($(basename $0))" $$ "Checking if Wireguard is UP...."$WVPNROUTE
if [ "$WVPNROUTE" != "" ];then
logger -s -t "($(basename $0))" $$ "**Warning Wireguard is UP.... restarting Wireguard"
/opt/etc/init.d/S50wireguard restart
fi
Scripts are not beautiful. They just work. Sorry, this is my best.
They have some rules to prevent duplicate.
The error messages (e.g. iptables) are not real error.
Don't worry.
Edit: iperf benchmark result.
WireGuard server on RT-AC86U. Windows 10 Tunsafe client. (https://tunsafe.com/download)
WireGuard author does not assure Tunsafe security. I just used it for benchmark purpose.
C:\iperf-2.0.9-win64>iperf -c 192.168.50.246 -N -M 1400 -t 20 -w 2M -P 5
WARNING: attempt to set TCP maximum segment size to 1400, but got 1281
WARNING: attempt to set TCP maximum segment size to 1400, but got 1281
WARNING: attempt to set TCP maximum segment size to 1400, but got 1281
WARNING: attempt to set TCP maximum segment size to 1400, but got 1281
WARNING: attempt to set TCP maximum segment size to 1400, but got 1281
------------------------------------------------------------
Client connecting to 192.168.50.246, TCP port 5001
TCP window size: 2.00 MByte
------------------------------------------------------------
[ 5] local 10.50.50.2 port 1911 connected with 192.168.50.246 port 5001
[ 7] local 10.50.50.2 port 1913 connected with 192.168.50.246 port 5001
[ 4] local 10.50.50.2 port 1910 connected with 192.168.50.246 port 5001
[ 6] local 10.50.50.2 port 1912 connected with 192.168.50.246 port 5001
[ 3] local 10.50.50.2 port 1909 connected with 192.168.50.246 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-20.0 sec 220 MBytes 92.4 Mbits/sec
[ 7] 0.0-20.0 sec 205 MBytes 86.1 Mbits/sec
[ 4] 0.0-20.1 sec 230 MBytes 96.1 Mbits/sec
[ 6] 0.0-20.0 sec 227 MBytes 95.2 Mbits/sec
[ 3] 0.0-20.0 sec 212 MBytes 89.1 Mbits/sec
[SUM] 0.0-20.1 sec 1.07 GBytes 457 Mbits/sec
I'm a TorGuard subscriber. They currently support four WireGuard servers in NYC. They have instructions on how to install on the gl-inet travel router. I currently own the AR-300M model.
Once, I upgraded the firmware, the configuration was a snap.
Unfortunately, I can't report great speeds when compared to the AC86U. The travel router is probably constrained by the Qualcomm QCA9531 SoC, 650MHz CPU along with the location of the servers in NYC, which is half way across the globe from my location. However, notable difference when compared to OpenVPN.
Code:
WireGuard OVPN aes-128-gcm
Down 32.97 5.96
Up 18.59 8.27
Latency 316.00 305.00
Still, good to see some progress being made and it will be interesting to see how things progress.
Unfortunately, I can't report great speeds when compared to the AC86U. The travel router is probably constrained by the Qualcomm QCA9531 SoC, 650MHz CPU along with the location of the servers in NYC, which is half way across the globe from my location. However, notable difference when compared to OpenVPN
Your numbers seem low for the AR300M - are you using WiFi as the WAN connection? The numbers you're seeing are similar to what I see with USB150 (review soon) using WiFi as the WAN side...
I host WG internally on a NUC7i5 (Kaby Lake NUC running Ubuntu 18.06) as the host, and AR300M cabled up...
Your numbers seem low for the AR300M - are you using WiFi as the WAN connection? The numbers you're seeing are similar to what I see with USB150 (review soon) using WiFi as the WAN side...
I host WG internally on a NUC7i5 (Kaby Lake NUC running Ubuntu 18.06) as the host, and AR300M cabled up...
I did the test using a CAT 5e cable Ethernet connection. I will do another test using a CAT 7 cable. The CAT 5e may have been the issue. Also, I am a very long way from the servers in New York.
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
