VPN policy routing management: per client versus centralized?

[SomeWhereOverTheRainBow]

I can't show you an example of a centralized management because I haven't written it. It would look the same as it currently does on each client page, except that the interface dropdown would list all different VPN clients instead of only WAN/VPN, and it would be on its own page.


DNS policy is unrelated to client routing, and remains configured on each individual client pages.


What functions would you lose?


I'm not rewriting the whole VPN client implementation, that was already done last year. Only routing, and policy-routing.

Changing which WAN interface the connection occurs within the VPN client itself wouldn't make sense, as it would potentially conflict with the actual Dual WAN routing configured by the router. Dual WAN routing is its own, separate thing.


Not possible. The only way to do so is through packet marking at the iptables level when marks could be applied based on the destination port, and that would stop working the instant you use hardware-acceleration for NAT.

I prefer the policy based routing as it is more customizable. Having a centralized management means you have a one size fits "most" situation, which we know it never really fits "most". sometimes you may only need a centralized management, but there may be an instance where you need policy based routing. I would rather keep what we have. Option B

 

[DeepAnger]

A

 

[alecmascot]

I would prefer to stay with what we have now. B please

 

[Sumsurfguy]

Just putting in a vote for A, the current implementation is great (the reason I bought an Asus router) and merging into a single location would make it even better.

 

[Nick_J]

Option B, please, is more configurable.
And Would it be possible to increase the Rule for Routing's Max Limit, I can only fit around 30 - 40 rules.

Thank you.

 

[Nick_J]

I would like "B" solution.
I prefers to have more control per vpnclients.

I agree.

 

[Makaveli]

Also prefer B

 

[RMerlin]

And Would it be possible to increase the Rule for Routing's Max Limit, I can only fit around 30 - 40 rules.

The problems are technical limitations.

• Broadcom limits the max length of any undefined (i.e. added by me and not by Asus) nvram to a maximum length of 255 characters
• I already hack things a bit to extend that to roughly 1200 characters, but then you waste a lot of nvram while doing so, and that waste has to be multiplied by 5, for each VPN client
• On older models, you are already limited by having only 64 KB total of nvram - using 4000-5000 just for policy rules is problematic
• Each web page has a limit of around 64 KB of POST-able data, and the VPN client can eat a lot of that due to the key/certificates that are loaded/saved on the VPN pages

Even if I were to store rules to JFFS instead of NVRAM (which would mean that when backing up and restoring your settings, all rules would be lost), the max POST size for the web server could cause data to get truncated.

You should reduce the length of your Descriptions to make more rules fit within the available nvram space, or start using subnets to you can create rules in CIDR format.

 

[Swistheater]

The problems are technical limitations.

• Broadcom limits the max length of any undefined (i.e. added by me and not by Asus) nvram to a maximum length of 255 characters
• I already hack things a bit to extend that to roughly 1200 characters, but then you waste a lot of nvram while doing so, and that waste has to be multiplied by 5, for each VPN client
• On older models, you are already limited by having only 64 KB total of nvram - using 4000-5000 just for policy rules is problematic
• Each web page has a limit of around 64 KB of POST-able data, and the VPN client can eat a lot of that due to the key/certificates that are loaded/saved on the VPN pages

Even if I were to store rules to JFFS instead of NVRAM (which would mean that when backing up and restoring your settings, all rules would be lost), the max POST size for the web server could cause data to get truncated.

You should reduce the length of your Descriptions to make more rules fit within the available nvram space, or start using subnets to you can create rules in CIDR format.

Option B

 

[SomeWhereOverTheRainBow]

Hi folks,

I'd like to hear people's opinion on this. Policy-based routing (AKA split tunnelling) for clients. Which management method do you prefer:

a) One single location where you can configure all your LAN devices, and select through which VPN they go (similar to Asus' VPN Fusion)
b) Each VPN client have their own list of LAN devices for that specific VPN client instance (Asuswrt-Merlin's current method)

I can see pros and cons for each. I've been rewriting the OpenVPN routing implementation these past few days, so now would be the best time to consider maybe switching to a more centralized management method if it made more sense... or otherwise, re-implement the already existing management method with the new architecture.

Maybe you should make a vote survey and list the options or things you are thinking about so people can vote on it from there. I imagine you got alot of ideas on what you think would be great changes.

 

[maghuro]

Centralized. Option A

 

[Alfsu]

I do support option 'A'.
I can see the benefit of having a visual of routing rules in one place: what IPs are going to what VPN client #, its VPN Server description, less opportunity for conflicting configurations, plus potential NVRAM usage optimization.
Being using split tunneling since before there was a UI for them (3 tunnels to be exact), and I do believe option 'A' will be the natural evolution of this great feature.
Definitely option 'A' for me.

 

[litoven]

I've been using option A on the stock firmware of the GT-AXE11000 and I like it for MY implementation, I do miss some of the features a lot but can't deny that Fusion, while looked ugh at the beginning is working nice and super simple.

 

[Tech9]

Option A

 

[Jumpstarter]

Option B

 

[slidermike]

Maybe easier to tally the results if you put a poll/vote in the front of the thread.

 

[RMerlin]

Maybe you should make a vote survey and list the options or things you are thinking about so people can vote on it from there. I imagine you got alot of ideas on what you think would be great changes.

Maybe easier to tally the results if you put a poll/vote in the front of the thread.

The problem with votes is that people expect that the 50% + 1 option will automatically win. That's not necessarily the case, as I often strongly feel one way rather than the other, and it would take a large majority to convince me to change my mind in such cases.

So, I prefer to just gather general feedback like this.

 

[doublehd]

Sounds like B would be more preferable. But I wish Merlin picks the best way for a dummy like me.

 

[SomeWhereOverTheRainBow]

The problem with votes is that people expect that the 50% + 1 option will automatically win. That's not necessarily the case, as I often strongly feel one way rather than the other, and it would take a large majority to convince me to change my mind in such cases.

So, I prefer to just gather general feedback like this.

I am more of a 3/fifths kinda guy, or else nothing gets done.

 

[slidermike]

Not an A or B answer but similar to doublehd, I want it to do what I need it to do but without the headaches.
And as merlin mentioned, in the end he is going to do what he thinks is best for his fork. Makes sense otherwise nothing gets done if your not passionate about what you are doing.