skeal
Part of the Furniture
Thanks for the explanation sir!Node UIs was never directly accessible, because they are centrally managed by the main router. That's the main point of AiMesh.
Thanks for the explanation sir!Node UIs was never directly accessible, because they are centrally managed by the main router. That's the main point of AiMesh.
Oh I read it very carefully I just fail to understand what you imply, technically, by "Not every connection is going to be as impervious as fiber. A similar asymmetric cable connection would easily buckle to the bottleneck produced by the routers insufficient arm processors having to respond without the aid of hardware acceleration." so I tried to guess and obviously failed.No I mean exactly what the reply says. Maybe you should reread it for better understanding because your response to the post is genuinely out of step with what the original message was.
As a software engineering company, I have a contact in Broadcom since they bought LSI/Avago, I will see if an inquiry can bring any fruit otherwise reverse engineering it is. Thanks for pointing out the "fc" tool, it's a great starting point. If support is needed in FC then Broadcom would have to add it themselves indeed but perhaps we can patch the wireguard module in a way that is compatible while not breaking implementation or cripple performance.I have no documentation at all about it. It can be manipulated through the "fc" userspace tool. At least one improvement over CTF is you can enable/disable it without the need to reboot. There are also more finer grained options, but there's no public documentation beyond the description labels shown by the fc tool.
I know that Broadcom does "special" support for IPSEC based on references I've seen in the past within the SDK. I also know that they recently did some CPU interrupt/timing tweaks in a recent SDK update to improve OpenVPN performance. So anyone's best chance is probably for them to eventually decide to support the WG protocol within fc, assuming this is even technically possible.
You don't need a kill switch on WG. The interface does not go down in case the other side is unreachable so no traffic bound for the tunnel can leak. You just get loss of connectivity, like using a kill switch.And also no kill switch on WG, is that even the case with an vpn providers clients software?
"Allowed IPs" in WG terms does 2 things. First it's what is allowed to go through. Subnets not defined there will be discarded on the other end. Secondly it adds routes to the interface for said subnets. So, for example, for routing all traffic through the tunnel, the configuration is "0.0.0.0/0, ::/0"I'm using Wireguard with VPN Director to direct devices I want through the VPN. What does 'Allowed IPs" mean, and does it apply to my basic requirements?
Okay I'm a little confused. If I use a CDIR for a VPN Redirect instruction, is that the same thing as the allowed IPs? Is the way I'm doing it acceptable? When I plugged my CIDR in the allowed IPs field, it stopped the other redirects I have, like it replaced what I was currently doing. Am I right this is a duplication of VPN Redirect?"Allowed IPs" in WG terms does 2 things. First it's what is allowed to go through. Subnets not defined there will be discarded on the other end. Secondly it adds routes to the interface for said subnets. So, for example, for routing all traffic through the tunnel, the configuration is "0.0.0.0/0, ::/0"
This is 2 different things, but I understand its abit confusing.Okay I'm a little confused. If I use a CDIR for a VPN Redirect instruction, is that the same thing as the allowed IPs?
Did you happen to compare the Wireguard vs. OpenVPN client's speed ceiling differences, while keeping everything else (WAN, ISP, VPN provider) constant ? I'm really looking forward to switching to WG with the hope that the speed ceiling will be higher especially for the AX-58U (that's a little low for my liking with OpenVPN, specific to AX-58U).Went straight from 386.7_2 to 388.1_alpha1-g5fb71044da, no unusual errors in the log so far and Wireguard Client works as expected.
Thanks for your effort, RMerlin.
Did you happen to compare the Wireguard vs. OpenVPN client's speed ceiling differences, while keeping everything else (WAN, ISP, VPN provider) constant ? I'm really looking forward to switching to WG with the hope that the speed ceiling will be higher especially for the AX-58U (that's a little low for my liking with OpenVPN, specific to AX-58U).
Thanks for reporting, and to Merlin, of course.
@RMerlin thanks for the AX58U alpha, out of curiosity I've been waiting for it to try wireguard.
Just putting up a few comparison speed tests up.
I have a 500Gb symmetrical fibre connection over PPPoE to my ISP.
I use Astrill VPN as a client to the outside world and all tests are to the same host server.
Win11 PC no VPN
Win11 PC Astrill WG client
AX58U OpenVPN
AX58U WireGuard
So even on this relatively low powered AX58U WireGuard is over 3 times faster than OpenVPN
Thank you for the explanation sir! It makes sense now.This is 2 different things, but I understand its abit confusing.
AllowedIPs are Wireguards internal routing scheme. It should contain which destination ips that is reached over the tunnel. For an internet client it would be 0.0.0.0/0 as all destinations are reachable and this will cause wg to overtake your internet(default) route. For i.e a site-2-site it may only be other side wg interface and other side lan, I.e 10.50.1.2/32, 192.168.51.0/24 and thus only setup routes to these networks.
It also serves as a protection. Other destinations are not allowed over the tunnel.
VPNDirector are policy routing. This is typically source based, like only a specific source ip should use vpn tunnel.
So these are 2 different things and have nothing to do with each other. AllowedIPs will become routes in routing table (which is destination based) and VPNdirector will become routing rules (which is/can be source based).
It depends a bit on the implementation if the router is up and after that the tunnel starts you can have a window where traffic escapes through the WAN before the tunnel is up, and if there is an error in the WG setup the tunnel might not function at all.You don't need a kill switch on WG. The interface does not go down in case the other side is unreachable so no traffic bound for the tunnel can leak. You just get loss of connectivity, like using a kill switch.
Yes, this is the expected behavior.I have ax58u and 1Gbit, is there a way to achieve full bandwith with qos? With qos enabled I get max 600mbit, with disabled 920, and additionally with disabled AIprotection around 960. Is it normal behaviour or mine asus is faulty?
Welcome To SNBForums
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!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!