What's new

Wireguard Session Manager - Discussion thread (CLOSED/EXPIRED Oct 2021 use http://www.snbforums.com/threads/session-manager-discussion-2nd-thread.75129/)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Martineau

Part of the Furniture
Thanks to @Odkrys, WireGuard as an alternative to established VPN tunnel protocols OpenVPN and IPSec has been available on some specific ASUS Routers for a while, although the instructions posted by the OP


are quite straight forward with only a few steps, they only provide static information for either a single 'client' Peer or 'server' (or both) and managing more than one concurrent Peer (either a 'client' or 'server') is more complex hence this script.

As with any Beta, this script shouldn't be deployed in mission critical environments in case it does cause undue disruption but hopefully this script can be easily quickly removed if it happens to do so.

Whilst I have used different names for the support scripts, I have currently chosen S50wireguard but any existing /opt/etc/init.d/S50wireguard script will be backed up during the install.

Once the script is running, existing interfaces 'wg0/wg1' should validly remain as-is, as my script uses interface names 'wg11'-'wg15' for 'client' Peers and 'wg21'-'wg22' for the two 'server' Peers.

Seven interfaces should be adequate, although more could/can easily be defined.

The script is based on my use of using Mullvad's WireGuard servers for remote 'client' Peer connections - so if you don't have access to a remote WireGuard server then this script is pointless in terms of outbound WireGuard connections.

However, the script does set up a WireGuard 'server' Peer on the router and the script can be used to assist with basic auto-definition of say mobile devices to allow remote Peer inbound connections.

Very basic rules are added, but RPDB Routing Policy rules can be manually applied in much the same way as OpenVPN rules are currently used.

Hopefully this script may open the door a little wider for those that need performance (albeit with the caveat/numerous posts that WireGuard may not yet be fully ratified from a security view point) although it largely depends on how the comparison is made between OpenVPN and WireGuard throughput so YMMV.

i.e. Is WireGuard measurably say 3 X faster than OpenVPN?

In summary, the point of this initial Beta is to assist in managing existing/multiple WireGuard interfaces, and isn't intended as a tutorial on how to exploit WireGuard etc.

WireGuard session Manager

Regards,
 
Last edited:
Reserved
 
Last edited:
Known Issues
 
Last edited:
Q&A
 
Last edited:
Next-level thinking, this...clear skies and fair winds, @Martineau !
 
Interesting. I wonder when NordVPN will make it easy to locate WireGuard (aka NordLynx) servers and config files.
 
i.e. Is WireGuard measurably say 3 X faster than OpenVPN?
On an openwrt router limited by CPU, I have found a connection to a VPN Unlimited node to increase from around 21mbps over openvpn to about 55mbps on wireguard, and on one not quite so limited, from around 30 to 95mpbs. In the first case, the router was acting as a repeater (travel router) on 2.4G, and in the second case, as a repeater on 5G. Also, the connection was made almost instantaneously, as opposed to 3 or 4 seconds for openVPN. So I think wired throughput could be much greater.

Looking forward to trying. Great addition!
 
How can I use Cloudflares WARP with this scipt?
I'm a noob.

During the S50wireguard script install, it will create a template 'client' Peer configuration 'wg11.conf'

So if you follow this post


You will then need to identify/retrieve the necessary appropiate Private/Public key-pair for Cloudflare Warp+
(As noted in the thread above, you need a Warp+ subscription to use the Cloudflare Confiigurator...if the FREE service is no longer available)

You can either clone the wg0.conf to '/opt/etc/wireguard/wg0.conf', or since the query is specifically about using my script, you need to customise the default 'client' Peer template wg11.conf

Of course you can use the editor of your choice nano/WinSP etc., or use the SSH command line
Code:
PUB_KEY="This_is_the_Public_Cloudflare_key"
PRIV_KEY="This_is_the_Private_key"

sed -i "/^PrivateKey/ s~[^ ]*[^ ]~$PRIV_KEY~3" ${CONFIG_DIR}wg11.conf
sed -i "/^PublicKey/ s~[^ ]*[^ ]~$PUB_KEY~3"   ${CONFIG_DIR}wg11.conf

sed -i "/^Endpoint/ s~[^ ]*[^ ]~engage.cloudflareclient.com:2408~3" /opt/etc/wireguard/wg11.conf


cat /opt/etc/wireguard/wg11.conf

Once there is a valid Peer config file (either wg11.conf or wg0.conf), use either the full path command /opt/etc/init.d/S50wireguard start client 1 or use the convenient wgm shortcut
Code:
wgm start client 1

or

wgm start client 0

wgm check
 
Last edited:
Great addition to the "toolbox" - thank you @Martineau!
I'm mostly interested in the client configuration on the router. As with your previous scripts, it was easy to follow along and make it work... One issue at my end - after configuring the interface, connecting to the server and all that... The connection latency is higher and the speed is lower compared to the OVPN client.

Here's a connection debug report:
Code:
(S50wireguard): 17229 v1.05 WireGuard VPN Peer Status check.....

        interface: wg11         ('client' # Torguard US, Atlanta (?))
                 public key: P7+KSchrmw6/nBhEjvHIoDY6GeidvZAIz+PC0xamyWU=
                 private key: (hidden)
                 listening port: 39876

                peer: vLGtUBDzDTbNw7+aSfvKsFeDBL4dFHtc3khlSjo5b2w=
                 endpoint: so.me.i.p:1443
                 allowed ips: 0.0.0.0/0
                 latest handshake: 59 seconds ago
                 transfer: 1.62 KiB received, 5.88 KiB sent
                 persistent keepalive: every 25 seconds

        DEBUG: Routing Table main

10.13.77.0/24 dev wg11  proto kernel  scope link  src 10.13.77.249

        DEBUG: Routing Table 121
0.0.0.0/1 dev wg11  scope link
10.13.77.0/24 dev wg11  proto kernel  scope link  src 10.13.77.249
128.0.0.0/1 dev wg11  scope link
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

        DEBUG: RPDB rules
0:      from all lookup local
9911:   from 192.168.2.245 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
10101:  from 192.168.2.244 lookup ovpnc1
10102:  from 192.168.2.234 lookup ovpnc1
10103:  from 192.168.2.249 lookup ovpnc1
10104:  from 192.168.2.254 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

Anything that looks odd, or out of sequence and may cause the slower connection as compared to OVPN to the same endpoint? I appreciate any suggestion.
 
Great addition to the "toolbox" - thank you @Martineau!
I'm mostly interested in the client configuration on the router. As with your previous scripts, it was easy to follow along and make it work... One issue at my end - after configuring the interface, connecting to the server and all that... The connection latency is higher and the speed is lower compared to the OVPN client.

Here's a connection debug report:
Code:
(S50wireguard): 17229 v1.05 WireGuard VPN Peer Status check.....

        interface: wg11         ('client' # Torguard US, Atlanta (?))
                 public key: P7+KSchrmw6/nBhEjvHIoDY6GeidvZAIz+PC0xamyWU=
                 private key: (hidden)
                 listening port: 39876

                peer: vLGtUBDzDTbNw7+aSfvKsFeDBL4dFHtc3khlSjo5b2w=
                 endpoint: so.me.i.p:1443
                 allowed ips: 0.0.0.0/0
                 latest handshake: 59 seconds ago
                 transfer: 1.62 KiB received, 5.88 KiB sent
                 persistent keepalive: every 25 seconds

        DEBUG: Routing Table main

10.13.77.0/24 dev wg11  proto kernel  scope link  src 10.13.77.249

        DEBUG: Routing Table 121
0.0.0.0/1 dev wg11  scope link
10.13.77.0/24 dev wg11  proto kernel  scope link  src 10.13.77.249
128.0.0.0/1 dev wg11  scope link
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

        DEBUG: RPDB rules
0:      from all lookup local
9911:   from 192.168.2.245 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
10101:  from 192.168.2.244 lookup ovpnc1
10102:  from 192.168.2.234 lookup ovpnc1
10103:  from 192.168.2.249 lookup ovpnc1
10104:  from 192.168.2.254 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

Anything that looks odd, or out of sequence and may cause the slower connection as compared to OVPN to the same endpoint? I appreciate any suggestion.
I'm a little concerned but not totally surprised (given my shonky scripting skills) by the ominous statement "it was easy to follow along and make it work... " sounds like a frustrating experience?, but there is a Beta S50wireguard v1.07b available using wgm uf dev

So, in my defence, I've been focussed on making the process of configuring a WireGuard 'server' Peer on the router, allowing very very easy configuration of 'client' Peer devices such as Cell-phone/Mobile etc.

As far as 'client' Peer connections are concerned, then I may (being lazy) have mangled the RPDB rules, but the contents of the wg1x.conf files would be outside of my control - generated by the WireGuard ISP.

Your rules shown above indicate you have configured Policy routing for one LAN device?

Only thing that may be redundant is the use of the 0.0.0.0/0 and 128.0.0.0/1 entries in routing table 121. What happens if you delete them?

EDIT: What is the MTU?
 
Last edited:
I'm a little concerned but not totally surprised (given my shonky scripting skills) by the ominous statement "it was easy to follow along and make it work... " sounds like a frustrating experience?, but there is a Beta S50wireguard v1.07b available using wgm uf dev

So, in my defence, I've been focussed on making the process of configuring a WireGuard 'server' Peer on the router, allowing very very easy configuration of 'client' Peer devices such as Cell-phone/Mobile etc.
I meant what I said - I'll leave it at that :).

v1.07b and removing those entries in the routing table 121 did not make a difference. However, I configured the WireGuard ISP's own application with the content of their generated config file. The latency was higher and speed lower than what I used to have (but much better than the beta client peer altogether).

So, I have opened a ticket with them - will update with any relevant information.

The MTU is 1500.
 
I meant what I said - I'll leave it at that :).

v1.07b and removing those entries in the routing table 121 did not make a difference. However, I configured the WireGuard ISP's own application with the content of their generated config file. The latency was higher and speed lower than what I used to have (but much better than the beta client peer altogether).

So, I have opened a ticket with them - will update with any relevant information.

The MTU is 1500.
Is 1500 the MTU of the WireGuard interface wg11?

Don't know why, but I apparently use 1380 :rolleyes: in the Beta when initialising the interface rather than 1420 or 1440.

It will be interesting to see what the ISP puts in the ticket when they close it...ether a standard "try a different server" or hopefully a more fulfilling resolution/reply.

Thanks for the feedback.
 
I just updated to wgm 1.08 + uf dev... something is missing (probably a left over from the previous version)

Code:
#============================================================================================ © 2021 Martineau v1.08b
#
#       S50wireguard   {start|stop|restart|check|create} [ [client [policy] |server]} [wg_instance] ]
#
#       S50wireguard   start 0
#                      Initialises remote peer 'client' 'wg0'
#       S50wireguard   start client 0
#                      Initialises remote peer 'client' 'wg0'
#       S50wireguard   start 1
#                      Initialises local peer 'server' 'wg1'
#       S50wireguard   start server 1
#                      Initialises local peer 'server' 'wg21'
#       S50wireguard   start client 1
#                      Initialises remote peer 'client' 'wg11' uses interface naming convention as per OpenVPN e.g. tun11
#       S50wireguard   start client 1 policy
#                      Initialises remote peer 'client' 'wg11' in 'policy' Selective Routing mode
#       S50wireguard   stop client 3
#                      Terminates remote peer 'client' 'wg13'
#       S50wireguard   stop 1
#       S50wireguard   restart SGS8
#                      Restart legacy-named Peer and auto-detect if it's a 'client' or 'server'
#

v1.08b v1.05 S50wireguard WireGuard Session Manager

        ***ERROR Invalid/missing arg 'check'
 
I just updated to wgm 1.08 + uf dev... something is missing (probably a left over from the previous version)

Code:
#============================================================================================ © 2021 Martineau v1.08b
#
#       S50wireguard   {start|stop|restart|check|create} [ [client [policy] |server]} [wg_instance] ]
#
#       S50wireguard   start 0
#                      Initialises remote peer 'client' 'wg0'
#       S50wireguard   start client 0
#                      Initialises remote peer 'client' 'wg0'
#       S50wireguard   start 1
#                      Initialises local peer 'server' 'wg1'
#       S50wireguard   start server 1
#                      Initialises local peer 'server' 'wg21'
#       S50wireguard   start client 1
#                      Initialises remote peer 'client' 'wg11' uses interface naming convention as per OpenVPN e.g. tun11
#       S50wireguard   start client 1 policy
#                      Initialises remote peer 'client' 'wg11' in 'policy' Selective Routing mode
#       S50wireguard   stop client 3
#                      Terminates remote peer 'client' 'wg13'
#       S50wireguard   stop 1
#       S50wireguard   restart SGS8
#                      Restart legacy-named Peer and auto-detect if it's a 'client' or 'server'
#

v1.08b v1.05 S50wireguard WireGuard Session Manager

        ***ERROR Invalid/missing arg 'check'
Whoops, I've omitted to correctly update the help function comment to reflect the commit where I decided to rename some of the commands/aliases

https://github.com/MartineauUK/wire...3cd7f4fe44d70ba2bdbfaed862410249e0581043ba67e

wgshow or wgm show replaces wgm check

and

wgdiag or wgm diag replaces wgm checkdebug

Thanks for the feedback - I'll fix it in v1.09

i.e. the official command wg show dictates that wgshow conveniently assists in tolerating my sloppy far better than wgm check
 
It looks like the VPN provider sorted out any potential issues (without changing the dedicated IP.) To take their client out of the picture I downloaded the WireGuard client peer. I loaded into it the configuration generated on the provider's website. The result can't get much better - it runs at 220/12 Mbps on a Comcast cable 200/10 connection.
Now back to the current S50wireguard 1.10. The same configuration as loaded into the WireGuard client peer yields results in the range of 2.7-3.1/3.3-3.8 Mbps.

As you suggested I deleted the 128.0.0.0/1 entry from the 121 routing table. That improved the outcome to 5.8-7.1/7.1-8.4 Mbps. Deleting the 0.0.0.0/1 entry from the same table basically breaks the client - the IP reverts to the WAN IP.

Side note: I added the line "ListenPort = 51820" under the [Interface] section in wg11.conf to keep in sync with the working generated configuration.

Here is the debug info:
Code:
(S50wireguard): 22047 v1.10 WireGuard VPN Peer Status check.....

        interface: wg11         ('client' # Torguard USA, Miami (maybe!))
                 public key: 39LFwwxR7QPtp/8T2pXycqXCSXFoadPxcpJz/1/ohmA=
                 private key: (hidden)
                 listening port: 51820

                peer: o7zt+ulipyJaxjumz8LqjnaLjAE2hZMlwKvnOI1zA0Y=
                 endpoint: so.me.i.p:1443
                 allowed ips: 0.0.0.0/0
                 latest handshake: 31 seconds ago
                 transfer: 202.83 MiB received, 44.91 MiB sent
                 persistent keepalive: every 25 seconds

        DEBUG: Routing Table main

10.13.98.0/24 dev wg11  proto kernel  scope link  src 10.13.98.81

        DEBUG: Routing Table 121
0.0.0.0/1 dev wg11  scope link
10.13.98.0/24 dev wg11  proto kernel  scope link  src 10.13.98.81
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

        DEBUG: RPDB rules
0:      from all lookup local
9911:   from 192.168.2.254 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
10101:  from 192.168.2.245 lookup ovpnc1
10102:  from 192.168.2.244 lookup ovpnc1
10103:  from 192.168.2.249 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

        DEBUG: Routing info MTU etc.

37: wg11: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.13.98.81/24 scope global wg11
       valid_lft forever preferred_lft forever
 
Last edited:
It looks like the VPN provider sorted out any potential issues (without changing the dedicated IP.) To take their client out of the picture I downloaded the WireGuard client peer. I loaded into it the configuration generated on the provider's website. The result can't get much better - it runs at 220/12 Mbps on a Comcast cable 200/10 connection.
Now back to the current S50wireguard 1.10. The same configuration as loaded into the WireGuard client peer yields results in the range of 2.7-3.1/3.3-3.8 Mbps.

As you suggested I deleted the 128.0.0.0/1 entry from the 121 routing table. That improved the outcome to 5.8-7.1/7.1-8.4 Mbps. Deleting the 0.0.0.0/1 entry from the same table basically breaks the client - the IP reverts to the WAN IP.

Side note: I added the line "ListenPort = 51820" under the [Interface] section in wg11.conf to keep in sync with the working generated configuration.

Here is the debug info:
Code:
(S50wireguard): 22047 v1.10 WireGuard VPN Peer Status check.....

        interface: wg11         ('client' # Torguard USA, Miami (maybe!))
                 public key: 39LFwwxR7QPtp/8T2pXycqXCSXFoadPxcpJz/1/ohmA=
                 private key: (hidden)
                 listening port: 51820

                peer: o7zt+ulipyJaxjumz8LqjnaLjAE2hZMlwKvnOI1zA0Y=
                 endpoint: so.me.i.p:1443
                 allowed ips: 0.0.0.0/0
                 latest handshake: 31 seconds ago
                 transfer: 202.83 MiB received, 44.91 MiB sent
                 persistent keepalive: every 25 seconds

        DEBUG: Routing Table main

10.13.98.0/24 dev wg11  proto kernel  scope link  src 10.13.98.81

        DEBUG: Routing Table 121
0.0.0.0/1 dev wg11  scope link
10.13.98.0/24 dev wg11  proto kernel  scope link  src 10.13.98.81
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

        DEBUG: RPDB rules
0:      from all lookup local
9911:   from 192.168.2.254 lookup 121
9990:   from all fwmark 0x8000/0x8000 lookup main
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
10101:  from 192.168.2.245 lookup ovpnc1
10102:  from 192.168.2.244 lookup ovpnc1
10103:  from 192.168.2.249 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

        DEBUG: Routing info MTU etc.

37: wg11: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.13.98.81/24 scope global wg11
       valid_lft forever preferred_lft forever
Ahhhh, thanks for the continued interest, I see you keep up to date with my script! :D, so I'll take a break from coding and see if I can replicate your issue.

NOTE: Given my UK location, my Fibre ISP WAN download speed is 1/10th of yours so my expections are relatively low.

For testing, I have three concurrent WireGuard 'client' Peers connected to Mullvad's servers, one of which is currently in New York (and two 'server' Peers that aren't currently hosting any inbound remote 'client' Peer connections)

Code:
wgdiag

(S50wireguard): 10713 v1.10b WireGuard VPN Peer Status check.....

    interface: wg11     ('client' # Mullvad USA, New York)
         public key: BAM+9SUqhEAYgzFUbaYnL5jKK9h1jzpwadGH7G4Z3U4=
         private key: (hidden)
         listening port: 49989
    
        peer: ru9aQRxYBkK5pWvNkdFlCR8VMPSqcEENBPGkIGEN0XU=
         endpoint: xxx.xxx.xxx.xxx:51820
         allowed ips: 0.0.0.0/0
         latest handshake: 5 seconds ago
         transfer: 107.76 MiB received, 7.73 MiB sent
         persistent keepalive: every 25 seconds
    
    interface: wg21     ('server' # Martineau RT-AC86U Host Peer 1)
         public key: j+aNKC0yA7+hFyH7cA9gISJ9+Ms05G3q4kYG/JkBwAU=
         private key: (hidden)
         listening port: 1151
    
        peer: wML+L6hN7D6wx+E1SA0K675x1cMjlpYzeTOPYww2WSM=     ('server client' # Unidentified)
         allowed ips: 10.123.1.88/32
    
    
    interface: wg12     ('client' # Mullvad China, Hong Kong)
         public key: BAM+9SUqhEAYgzFUbaYnL5jKK9h1jzpwadGH7G4Z3U4=
         private key: (hidden)
         listening port: 35564
    
        peer: oS4vR1RHoFtpevzl2KLUjqDH9AiLwnh9GHBMiB5FVgM=
         endpoint: xxx.xxx.xxx.xxx:51820
         allowed ips: 0.0.0.0/0, ::/0
         latest handshake: 2 seconds ago
         transfer: 184 B received, 2.39 KiB sent
         persistent keepalive: every 25 seconds
    
    interface: wg13     ('client' # Mullvad Oz, Melbourne)
         public key: BAM+9SUqhEAYgzFUbaYnL5jKK9h1jzpwadGH7G4Z3U4=
         private key: (hidden)
         listening port: 44905
    
        peer: D2ltFd7TbpYNq9PejAeGwlaJ2bEFLqOSYywdY9N5xCY=
         endpoint: xxx.xxx.xxx.xxx:51820
         allowed ips: 0.0.0.0/0, ::/0
         latest handshake: 58 seconds ago
         transfer: 312 B received, 744 B sent
         persistent keepalive: every 25 seconds

Just to clarify, what criteria are you using for your throughput testing? - perhaps @RMerlin could be petitioned to allow Wireguard 'wg*'' to be detected and chosen from the Official Speed Test Tab , but on the basis of my crude test probably not!

WireGuard
=======

Code:
./Speedtest.sh --big

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0   595k      0  0:14:20  0:14:20 --:--:-- 1107k
Code:
 wgshow

(S50wireguard): 22875 v1.10b WireGuard VPN Peer Status check.....

    interface: wg11     ('client' # Mullvad USA, New York)
         public key: BAM+9SUqhEAYgzFUbaYnL5jKK9h1jzpwadGH7G4Z3U4=
         private key: (hidden)
         listening port: 49989
      
        peer: ru9aQRxYBkK5pWvNkdFlCR8VMPSqcEENBPGkIGEN0XU=
         endpoint: 86.106.143.93:51820
         allowed ips: 0.0.0.0/0
         latest handshake: 1 minute, 26 seconds ago
         transfer: 641.20 MiB received, 27.94 MiB sent
         persistent keepalive: every 25 seconds


OpenVPN
======

Code:
./Speedtest.sh --big


  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0  1023k      0  0:08:20  0:08:20 --:--:--  546k
Code:
./VPN_Client_Switch.sh status

(VPN_Client_Switch.sh): 8286 v1.11 Request..... [status]

    VPN Client Status:

        Client 3 Connected session duration 00 hours 08 minutes 39 seconds
                 Connection 1196:udp to (Mullvad New York)        VPN STUN tunnel end-point I/P: 86.106.121.121
        Checking response (max 5secs) from 'http://ipecho.net/plain' to verify    VPN tunnel end-point I/P: 86.106.121.121
                                            VPN tunnel end-point I/P: 86.106.121.121

        Inter-|   Receive                                                |  Transmit
         face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
         tun13: 544729660  390493    0    0    0     0          0         0 10971424  204230    0    0    0     0       0          0

        NOTE: OpenVPN Statistics logged to Syslog
 
Last edited:
I only have one client peer configured for the closest server peer. I rebooted the router in between tests. First I activated the wireguard client peer software from WireGuard and ran fast.com and speedtest.net. After reboot I've done the same thing but instead of the software client peer I ran 'wgstart client 1 policy' (pointing the the laptop). Again the same fast.com and speedtest.net.
I posted the results - they were very close between the 2 test sites.

EDIT: @Martineau, it looks like you're getting more than double the throughput on wg - good for you :). Then I'll have to dig deeper at my end...
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top