VPN policy routing management: per client versus centralized?

[RMerlin]

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.

 

[octopus]

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

 

[cplay]

A. Providing you could also have the option to associate all current and new lan devices with a certain vpn client unless set otherwise.

 

[GSpock]

I would go for "b".
Thx.

 

[Yota]

I have two OpenVPN clients running
The first one is only for my TV, so it will be able to watch Netflix in other regions.
The second one is for my son’s PS4, because it brings less latency and a more stable network through a dedicated server.

So, I think if All-in-one I will lose some functions.

So I choose B.

Change mind, because A does not make me lose any existing features.

BTW, at 386.1, I can add the subnet 192.168.101.0/24 of my guest network to the OpenVPN client, but 386.2_4 of RT-AC86U is no longer available.

 

[Sonyrolfy]

Always great thinking ahead of the game. Maybe you can show a example how it would look with both (screenshot) How do we change the DNS policy ? Tnx!

 

[CaptainSTX]

I would prefer (A) a centralized location where LAN devices could be assigned to a particular client. I currently run two clients.

 

[tobifr34k]

B

 

[Zulgrib]

I would keep both :
Being able to add devices to a specific VPN client from it's VPN client configuration, and have another page where I could see everything.

Being able to add exceptions for specific routes (for example, always route 192.15.20.20 to VPN client 1, 170.10.90.1/31 to VPN client 2) would be fantastic too.

Thank you for your valuable time maintaining this for all these years.

 

[maxbraketorque]

I don't see any obvious pros and cons for either setup, but I'll tell you what I need which is that I need per-app resolution rather than per-device resolution. Or to put it another way, I'd like apps on any given device to have the option to select between using a VPN tunnel or going through the regular internet link.

 

[cybrnook]

Not directly related to the question, but if you're rewriting the VPN client, one thing I have often thought in the past that would be a nice to have is being able to select which WAN (in a dual WAN scenario) the VPN client defaults to routing it's traffic, vs just using the default gateway.

 

[Wcyote6]

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.

A

 

[RMerlin]

Maybe you can show a example how it would look with both (screenshot)

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.

How do we change the DNS policy ?

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

o, I think if All-in-one I will lose some functions.

What functions would you lose?

Not directly related to the question, but if you're rewriting the VPN client,

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.

I don't see any obvious pros and cons for either setup, but I'll tell you what I need which is that I need per-app resolution rather than per-device resolution. Or to put it another way, I'd like apps on any given device to have the option to select between using a VPN tunnel or going through the regular internet link.

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.

 

[Hazel]

I think I'd prefer option B, keeping the PBR LAN clients setup with the VPN clients. Knowing myself I'm bound to assign LAN clients to the wrong interface if I can't correlate the setup to them directly, as it is in the current scenario. Though, I can see the benefits for a more centralized solution as well, but a (albeit small) downside to that scenario would be you'd need to set up the VPN clients in a different place compared to the LAN clients you want for PBR.

Feature request: would you please consider implementing a VPN failover solution as well? I'm not familiar with coding so I have no clue how much effort it would take and if it would be along the lines with your vision for Asuswrt-Merlin, but it sure would come in handy. I know there's a script available but it would be so much easier to just specify on the client setup page which client to try next if the first one goes down.

Edit: I think you just answered my question already, while I was typing...

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

 

[Sonyrolfy]

I'm having some trouble to picture it, but if option A is more consolidated/centralized with the same functionality as it has now, Then option A is great! Tnx!

 

[Intrepid2007]

I would choose for B (as it is now).. It gives flexibility which would be lost if method A would be implemented.

I use 2 VPN's (and WAN):
WAN : 192.168.0.0 /24
VPN1: 192.168.1.0 /24
VPN2: 192.168.2.0 /24

As already said, the implementation as it is now gives flexibility... By just changing the client's subnet (0/1/2) you can determine where the LAN client's traffic is routed to...
This makes the routing feature in this firmware so unique compared to the stock firmware.

As far as I understand: with option A you would loose this flexibility because client traffic is always routed to a fixed VPN (or WAN), regardless of the client's IP address.
I assume the GUI would a show a list with LAN clients and their respective routing destination (VPN or WAN). A pro is that it might be easier to configure it for some people...

 

[maxbraketorque]

...

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.

ok. If I have two NICs on a device with both active on the network, can either of your split tunnel setups allow data going through one of the NICs to use a VPN interface to the internet?

 

[fax]

Option A if you have the same options/capability as B

 

[Torson]

a) One single location - if the same level of configuration can be maintained. Also, my wild guess (wg) is that in some undefined future we may see additional VPN client types, and that may simplify overall management/configuration.
May also be more appealing to current AsusWRT VPN Fusion users to switch to Merlin...

 

[Hazel]

Also, my wild guess (wg)

I see what you did there…