VPN Director Bug?

[JohnD5000]

I should add that the 10%-25% slowdown in upload speed is above and beyond the wireguard slowdown speed that would be expected.

For my system, I would expect
On WAN, upload speeds around 570-575
With Wireguard upload speeds around 500

Whenever a wgc1-5 setting is set in the "All devices" rule, the 10-25% slow down in speed is in addition to the Wireguard's expected 10% is speed slowdown.

 

[JohnD5000]

As a temporary test, change the “All Devices” rule to be 192.168.81.0/25 and see if the performance changes for LG Gram. The goal is to avoid overlapping rules.

I will give this a try and report back with results

 

[JohnD5000]

I will give this a try and report back with results

That appears to have worked!!!! Can you explain what is going on here?

 

[dave14305]

That appears to have worked!!!! Can you explain what is going on here?

My hypothesis was that the All Devices rule that covered the whole subnet was disabling hw acceleration for all devices, even though you had a separate routing rule for the laptop. By changing it to /25, we changed All Devices to stop at 192.168.81.127, so the laptop would not be included in the hw acceleration bypass rule.

I don’t know how it is designed to work in this scenario (can you unbypass a single IP from a CiDR?). That’s a Merlin question.

 

[JohnD5000]

My hypothesis was that the All Devices rule that covered the whole subnet was disabling hw acceleration for all devices, even though you had a separate routing rule for the laptop. By changing it to /25, we changed All Devices to stop at 192.168.81.127, so the laptop would not be included in the hw acceleration bypass rule.

I don’t know how it is designed to work in this scenario (can you unbypass a single IP from a CiDR?). That’s a Merlin question.

Ah, OK. I see what you did there. Essentially, you shut the "All devices" rule off for my device while keeping the rule on. If my device had a .127 or lower at the end of its DHCP IP address, it would have had the upload speed slowdown bug.

Essentially, you showed that the above bug exists in a more techy way!

>>I don’t know how it is designed to work in this scenario (can you unbypass a single IP from a CiDR?). That’s a Merlin question.<<

This is essentially what VPN Director is supposed to do (if I understand it correctly). It is a system that determines the rule for a specific device's CIDR address, and applies the interface (whether it is WAN or one of the VPN configs).

Hopefully, Merlin will take a look at it when he has time, but he obviously has a lot on his plate.

 

[dave14305]

Essentially, you showed that the above bug exists in a more techy way!

I don’t necessarily agree it’s a bug, however. It may just be an inherent limitation of HW acceleration and Wireguard on Asus routers.

This is essentially what VPN Director is supposed to do (if I understand it correctly). It is a system that determines the rule for a specific device's CIDR address, and applies the interface (whether it is WAN or one of the VPN configs).

I’m not sure if you’re catching that there are 2 separate activities at work here. Primarily, there is the routing decision of whether to send the traffic to WAN or a VPN Client. But when Wireguard is the VPN client, VPN Director also has to tell the firmware to bypass HW acceleration for any devices that need to go via a Wireguard tunnel, because WG is incompatible with the acceleration. This is the “WG blog bypass” that was implemented a few years ago.

When you have a rule sending the whole subnet through a WG client, you also get HW acceleration disabled for that subnet.

While you can fine-tune your routing rules to create an exception for a single IP, it’s unclear how granular the underlying bypass rules can be, since that relies on a lot of the closed source stuff.

I could be very wrong, since I am not a VPN user.

 

[JohnD5000]

Hey dave14305,

First, you know a lot more than me about networking and programming. And, you are right. It could be a limitation of Asus software or hardware, it could be a limitation of Wireguard when run that way, or it could be a bug. I guess only Merlin could figure that out.

I do know that download speeds and the VPN director behaves 100% the way that I would expect it to. And, download is what affects me (and I'm sure most users) 99% of the time. Up until this week, under perfect conditions, my upload speed was only in the 30s. Now, it is close to 600. Even if there is a 50% decrease in upload speed due to the above issue, I would still be 1000% faster than I was last week.

It doesn't really affect me, still, if any testing is needed, I'm willing to do it for the project.

 

[ZebMcKayhan]

I don’t know how it is designed to work in this scenario (can you unbypass a single IP from a CiDR?). That’s a Merlin question.

The bypass was designed by Asus/Broadcom and likely to match VPNFusion. @RMerlin ported this to the more capable VPNDirector but the options are limited. You simply add source ip to bypass to a file

admin@RT-AX86U_Pro-BBC8:/tmp/home/root# cat /proc/blog/skip_wireguard_network
192.168.100.128/25
192.168.100.2/32
192.168.100.0/24
192.168.128.1/32
192.168.128.100/32
192.168.128.120/32
192.168.128.110/32
aaff:a37f:fa75:100:0:0:0:100/120
aaff:a37f:fa75:100:0:0:0:2/128
admin@RT-AX86U_Pro-BBC8:/tmp/home/root#

For one thing, it does not handle destinations ip, so by adding those rules the fw bypasses the entire network.

There is no file to un-bypass ip so adding all lan except 1 ip, one would have to breakup the cidr into multiple rules. I don't think that is being done.

You can add/remove entries in this file yourself if you know the commands to do it (it is somewhere in the wgm threads)

Edit: here it is https://www.snbforums.com/threads/session-manager-4th-thread.81187/post-830466