WG Server test with flowcache bypass

[Morris]

1Gbps availability IS the new normal- my local cable provider has been offering 1Gb/30Mb FTTN at the same price as my 50/10 DSL for the past 6mo, and I can't say I've not struggled with temptation...but while my DL speed would 20x, why is my upload only 3x?

if you think 4k-HDR-Atmos is too much, wait until you've tried AR...the bubbles are coming for you, and AI will customize it to you. Soma would say it's a Brave New World...

The reason cable providers use a slower upload is the way traditional coax cable TV works. The system is tuned to deliver in the direction of the customer with all components optimized in that direction. Returns signals used to be mostly noise before cable started carrying internet and amplifying noise is very bad so they maintained the slower upload. To provide an upload at high speed requires allocating another channel in the ISP direction cutting available bandwidth and channels and this is not desirable. Most people's bandwidth consumption is mostly download. There are similar issues for DSL and it's cousins.

 

[tarzan2000]

Hi guys!
I ask for advice in a situation with WG. (388.1)
I have AX86U (10.7.0.1) with WG client\server (both)
WG server at the provider's site with a 500Mbps channel, AX86U as a client WG

- On AX86 I start iperf3 -s- D and test from a wired client (10.7.0.4) over a 1gbit network the speed FROM the wired client (10.7.0.4) inside the local network(1gbit network) TO the iperf 3 server on AX86U ....
- On NAS Synology DS218+(10.7.0.6) connected to 2.5Gbit port on AX86U I start iperf3 -s and test from a wired client (10.7.0.4) over a 1gbit network the speed FROM the client inside the local network TO the iperf 3 server on NAS ....

Explain to me how a running WG client or server affects the throughput of the LAN segment on the router?

1. WG client or server on AX86U starting

Spoiler: Wired Client

2. WG client or server on AX86U stoping

Spoiler: Wired Client

 

[tarzan2000]

At the same time, the situation with the speed drop is exactly the same on the AX210 wireless client (10.7.0.230).
Without a running WG client\server (on AX86U), the speed of iperf3 is about 1.2-1.3Gbps up to AX86U from AX210 (10.7.0.230) client, and with an active WG client / server, the speed drops to 600-700Mbps.

1. WG client or server on AX86U starting

Spoiler: Wireless Client

C:\Users\user\Downloads\iperf3>iperf3.exe -c 10.7.0.1 -P 4
Connecting to host 10.7.0.1, port 5201
[ 4] local 10.7.0.230 port 64826 connected to 10.7.0.1 port 5201
[ 6] local 10.7.0.230 port 64827 connected to 10.7.0.1 port 5201
[ 8] local 10.7.0.230 port 64828 connected to 10.7.0.1 port 5201
[ 10] local 10.7.0.230 port 64829 connected to 10.7.0.1 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 115 MBytes 96.2 Mbits/sec sender
[ 4] 0.00-10.01 sec 115 MBytes 96.1 Mbits/sec receiver
[ 6] 0.00-10.01 sec 90.4 MBytes 75.8 Mbits/sec sender
[ 6] 0.00-10.01 sec 90.2 MBytes 75.6 Mbits/sec receiver
[ 8] 0.00-10.01 sec 95.8 MBytes 80.3 Mbits/sec sender
[ 8] 0.00-10.01 sec 95.6 MBytes 80.1 Mbits/sec receiver
[ 10] 0.00-10.01 sec 132 MBytes 110 Mbits/sec sender
[ 10] 0.00-10.01 sec 131 MBytes 110 Mbits/sec receiver
[SUM] 0.00-10.01 sec 432 MBytes 363 Mbits/sec sender
[SUM] 0.00-10.01 sec 432 MBytes 362 Mbits/sec receiver

C:\Users\user\Downloads\iperf3>iperf3.exe -c 10.7.0.6 -P 4
Connecting to host 10.7.0.6, port 5201
[ 4] local 10.7.0.230 port 65126 connected to 10.7.0.6 port 5201
[ 6] local 10.7.0.230 port 65127 connected to 10.7.0.6 port 5201
[ 8] local 10.7.0.230 port 65128 connected to 10.7.0.6 port 5201
[ 10] local 10.7.0.230 port 65129 connected to 10.7.0.6 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 258 MBytes 216 Mbits/sec sender
[ 4] 0.00-10.00 sec 258 MBytes 216 Mbits/sec receiver
[ 6] 0.00-10.00 sec 249 MBytes 209 Mbits/sec sender
[ 6] 0.00-10.00 sec 249 MBytes 208 Mbits/sec receiver
[ 8] 0.00-10.00 sec 215 MBytes 181 Mbits/sec sender
[ 8] 0.00-10.00 sec 215 MBytes 181 Mbits/sec receiver
[ 10] 0.00-10.00 sec 211 MBytes 177 Mbits/sec sender
[ 10] 0.00-10.00 sec 211 MBytes 177 Mbits/sec receiver
[SUM] 0.00-10.00 sec 933 MBytes 782 Mbits/sec sender
[SUM] 0.00-10.00 sec 933 MBytes 782 Mbits/sec receiver

1. WG client or server on AX86U stoping

Spoiler: Wireless Client

C:\Users\user\Downloads\iperf3>iperf3.exe -c 10.7.0.1 -P 4
Connecting to host 10.7.0.1, port 5201
[ 4] local 10.7.0.230 port 49614 connected to 10.7.0.1 port 5201
[ 6] local 10.7.0.230 port 49615 connected to 10.7.0.1 port 5201
[ 8] local 10.7.0.230 port 49616 connected to 10.7.0.1 port 5201
[ 10] local 10.7.0.230 port 49617 connected to 10.7.0.1 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 104 MBytes 87.6 Mbits/sec sender
[ 4] 0.00-10.01 sec 104 MBytes 87.5 Mbits/sec receiver
[ 6] 0.00-10.01 sec 89.4 MBytes 74.9 Mbits/sec sender
[ 6] 0.00-10.01 sec 89.2 MBytes 74.8 Mbits/sec receiver
[ 8] 0.00-10.01 sec 99.5 MBytes 83.4 Mbits/sec sender
[ 8] 0.00-10.01 sec 99.3 MBytes 83.3 Mbits/sec receiver
[ 10] 0.00-10.01 sec 85.8 MBytes 71.9 Mbits/sec sender
[ 10] 0.00-10.01 sec 85.5 MBytes 71.7 Mbits/sec receiver
[SUM] 0.00-10.01 sec 379 MBytes 318 Mbits/sec sender
[SUM] 0.00-10.01 sec 378 MBytes 317 Mbits/sec receiver


C:\Users\user\Downloads\iperf3>iperf3.exe -c 10.7.0.6 -P 4
Connecting to host 10.7.0.6, port 5201
[ 4] local 10.7.0.230 port 49224 connected to 10.7.0.6 port 5201
[ 6] local 10.7.0.230 port 49225 connected to 10.7.0.6 port 5201
[ 8] local 10.7.0.230 port 49226 connected to 10.7.0.6 port 5201
[ 10] local 10.7.0.230 port 49227 connected to 10.7.0.6 port 5201

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 333 MBytes 279 Mbits/sec sender
[ 4] 0.00-10.00 sec 333 MBytes 279 Mbits/sec receiver
[ 6] 0.00-10.00 sec 320 MBytes 268 Mbits/sec sender
[ 6] 0.00-10.00 sec 319 MBytes 268 Mbits/sec receiver
[ 8] 0.00-10.00 sec 296 MBytes 248 Mbits/sec sender
[ 8] 0.00-10.00 sec 296 MBytes 248 Mbits/sec receiver
[ 10] 0.00-10.00 sec 278 MBytes 233 Mbits/sec sender
[ 10] 0.00-10.00 sec 278 MBytes 233 Mbits/sec receiver
[SUM] 0.00-10.00 sec 1.20 GBytes 1.03 Gbits/sec sender
[SUM] 0.00-10.00 sec 1.20 GBytes 1.03 Gbits/sec receiver

it is solved my problems https://www.snbforums.com/threads/flow-cache-bypass-for-wireguard.83084/post-817545 ?

 

[juanantonio]

Following this thread, I thought that I could enable Flow caché on my AX-86U. I am running Asus Wrt Merlin 388.2 with Martineau's Wireguard Session Manager.

I did so, but registry log starts throwing a lot of kernel errors:

May 19 10:05:05 (wg_manager.sh): 17711 Broadcom Packet Flow Cache learning via BLOG (Flow Cache) ENABLED
May 19 10:05:05 kernel: blog_link:overwriting ct_p=ffffffc0284eee20, new_ct=ffffffc028e3de20 idx=0
May 19 10:05:05 kernel:     NFCT: ct<0xffffffc0284eee20>, master<0x          (null)>
May 19 10:05:05 kernel:         F_NAT<ffffffc0267176f8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
May 19 10:05:05 kernel:         help<0x          (null)> helper<NONE> status=8000018e refcnt=2 zone=0
May 19 10:05:05 kernel: tuple ffffffc0284eeeb8: 17 86.127.246.68:32785 -> 185.183.106.2:1637
May 19 10:05:05 kernel: tuple ffffffc0284eeef0: 17 185.183.106.2:1637 -> 86.127.246.68:32785
May 19 10:05:05 kernel:         STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
May 19 10:05:05 kernel:     NFCT: ct<0xffffffc028e3de20>, master<0x          (null)>
May 19 10:05:05 kernel:         F_NAT<ffffffc0264b8178> keys[0x00000000 0x00000000] dir<DIR_ORIG>
May 19 10:05:05 kernel:         help<0x          (null)> helper<NONE> status=80000198 refcnt=2 zone=0
May 19 10:05:05 kernel: tuple ffffffc028e3deb8: 6 192.168.1.11:62120 -> 78.46.211.155:9443
May 19 10:05:05 kernel: tuple ffffffc028e3def0: 6 78.46.211.155:9443 -> 10.151.13.172:62120
May 19 10:05:05 kernel:         STATUS[ IPS_CONFIRMED_BIT IPS_SRC_NAT_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
May 19 10:05:05 kernel: blog_link:overwriting ct_p=ffffffc0284eee20, new_ct=ffffffc0244684c0 idx=0
May 19 10:05:05 kernel:     NFCT: ct<0xffffffc0284eee20>, master<0x          (null)>
May 19 10:05:05 kernel:         F_NAT<ffffffc0267176f8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
May 19 10:05:05 kernel:         help<0x          (null)> helper<NONE> status=8000018e refcnt=2 zone=0
May 19 10:05:05 kernel: tuple ffffffc0284eeeb8: 17 86.127.246.68:32785 -> 185.183.106.2:1637
May 19 10:05:05 kernel: tuple ffffffc0284eeef0: 17 185.183.106.2:1637 -> 86.127.246.68:32785
May 19 10:05:05 kernel:         STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
May 19 10:05:05 kernel:     NFCT: ct<0xffffffc0244684c0>, master<0x          (null)>
May 19 10:05:05 kernel:         F_NAT<ffffffc0269ba3f8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
May 19 10:05:05 kernel:         help<0x          (null)> helper<NONE> status=8000019e refcnt=2 zone=0
May 19 10:05:05 kernel: tuple ffffffc024468558: 6 192.168.1.11:62694 -> 13.88.181.35:443
May 19 10:05:05 kernel: tuple ffffffc024468590: 6 13.88.181.35:443 -> 10.151.13.172:62694
May 19 10:05:05 kernel:         STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
May 19 10:05:05 kernel: blog_link:overwriting ct_p=ffffffc0284eee20, new_ct=ffffffc028e3de20 idx=0
May 19 10:05:05 kernel:     NFCT: ct<0xffffffc0284eee20>, master<0x          (null)>
May 19 10:05:05 kernel:         F_NAT<ffffffc0267176f8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
May 19 10:05:05 kernel:         help<0x          (null)> helper<NONE> status=8000018e refcnt=16 zone=0
May 19 10:05:05 kernel: tuple ffffffc0284eeeb8: 17 86.127.246.68:32785 -> 185.183.106.2:1637
May 19 10:05:05 kernel: tuple ffffffc0284eeef0: 17 185.183.106.2:1637 -> 86.127.246.68:32785
May 19 10:05:05 kernel:         STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
May 19 10:05:05 kernel:     NFCT: ct<0xffffffc028e3de20>, master<0x          (null)>
May 19 10:05:05 kernel:         F_NAT<ffffffc0264b8178> keys[0x00000000 0x00000000] dir<DIR_ORIG>
May 19 10:05:05 kernel:         help<0x          (null)> helper<NONE> status=8000019e refcnt=3 zone=0
May 19 10:05:05 kernel: tuple ffffffc028e3deb8: 6 192.168.1.11:62120 -> 78.46.211.155:9443
May 19 10:05:05 kernel: tuple ffffffc028e3def0: 6 78.46.211.155:9443 -> 10.151.13.172:62120
May 19 10:05:05 kernel:         STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
May 19 10:05:15 (wg_manager.sh): 17711 Broadcom Packet Flow Cache learning via BLOG (Flow Cache) DISABLED

Am I missing something?

Thank you in advance.

 

[ZebMcKayhan]

I am running Asus Wrt Merlin 388.2 with Martineau's Wireguard Session Manager.

I think you need wgm latest dev version for this to work: uf dev. Also it only works for source rules, not destination rules.

 

[juanantonio]

I think you need wgm latest dev version for this to work: uf dev. Also it only works for source rules, not destination rules.

Correct. After updating WG Session Manager, those awful kernel messages have disappeared.

I have no destination rules as my LAN clients are all redirected to my VPN provider via one IPSET rule.

Nevertheless, I can't see any improvement in connection speed. Anyway, I didn't expect much because I've read only clients outside WG tunnel can benefit from this improvement.

Many thanks.

Edit: Bad news. After getting a correct log all morning, now those strange kernel messages have started to appear againg. Is there any thing I can do?

Of course I updated session manager with the

'uf dev'

command.
Regards