Two suggestions for OpenVPN Client Settings

[routerguy]

Hi and thanks for all the hard work you are putting into this firmware!

I am very happy with the strict settings that are possible with the OpenVPN clients to make sure connections are protected at all times and the VPN tunnel doesn't just die in silence. Two ideas for improvement, though:

(1) "Block routed clients if tunnel goes down"

Obviously, this setting is very important, but from my experience, routed clients are also blocked if I disable the VPN manually. That doesn't make much sense to me, and it would probably be very easy for the firmware to recognize that I have hit the "OFF" switch (as opposed to the connection dying on its own). This adds convenience but also safety, because if this feature doesn't need to be deativated when people surf without VPN, they also can't forget to reactivate it when they turn the VPN back on.

At least to me, a single, general switch would be perfect: If any tunnel currently active goes down, block routed clients. If tunnels are shut down by users, don't block. A setting like that could be ON all the time, and nobody would ever need to worry. Convenient and safe at the same time!

(2) "Start with WAN"

This is somewhat similar to the above. Can't speak for others, but at least for me, I switch VPNs ever so often, and if WAN is restarted, I'd be happiest if the router would simply remember the VPN that was on before the restart, and turn it on again. There are probably also users who would like the router to use a different VPN after the restart, but my guess is it's probably a vast (?) minority.

For this, one general switch would suffice as well - "once activated, start all VPNs with WAN, until deactivated". The current switch where individual VPNs can be set to ALWAYS start with WAN (even if previously deactivated) could be kept, of course - that way, nobody has a disadvantage.

Thanks again!

 

[RMerlin]

(1) "Block routed clients if tunnel goes down"

Obviously, this setting is very important, but from my experience, routed clients are also blocked if I disable the VPN manually. That doesn't make much sense to me, and it would probably be very easy for the firmware to recognize that I have hit the "OFF" switch (as opposed to the connection dying on its own). This adds convenience but also safety, because if this feature doesn't need to be deativated when people surf without VPN, they also can't forget to reactivate it when they turn the VPN back on.

It doesn't if you turn it off manually, and I actually had another user complaining about it.

(2) "Start with WAN"

This is somewhat similar to the above. Can't speak for others, but at least for me, I switch VPNs ever so often, and if WAN is restarted, I'd be happiest if the router would simply remember the VPN that was on before the restart, and turn it on again. There are probably also users who would like the router to use a different VPN after the restart, but my guess is it's probably a vast (?) minority.

That would require some quite complicated logic to remember too many different scenarios. I prefer to keep things simple, less likely to cause conflicts down the road.

The OpenVPN implementation already has far, far too many options for my taste. Asuswrt probably has 5 times more settings already than any other router or VPN-enabled NAS out there. I don't want to add any more unless really necessary. People with very specific usage scenario still have the option of going down the road of using user scripts to manage their tunnels.

 

[Forerunner]

It doesn't if you turn it off manually, and I actually had another user complaining about it.



That would require some quite complicated logic to remember too many different scenarios. I prefer to keep things simple, less likely to cause conflicts down the road.

The OpenVPN implementation already has far, far too many options for my taste. Asuswrt probably has 5 times more settings already than any other router or VPN-enabled NAS out there. I don't want to add any more unless really necessary. People with very specific usage scenario still have the option of going down the road of using user scripts to manage their tunnels.

The implementation is great Merlin I think its just right. Do you have any Plans to have PPTP manual routing or IKEv1 or 2 Implemented? as OpenVPN is slower on the router.

 

[routerguy]

It doesn't if you turn it off manually

To me it does. I turn service state "ON" to service state "OFF" on the currently active VPN - internet connection dies.
I turn "Block routed clients if tunnel goes down" off, and it is back immediately.

I've tested this throughly, and upgraded to the latest Merlin version before posting here.

The OpenVPN implementation already has far, far too many options for my taste.

In that case, I propose to get rid of the manual "start with WAN" options for each VPN and simply replace it by a single switch in the general settings - that would reduce the total number of dials by four.

All the switch in the general settings would really do is determine if "start with WAN" is automatically activated when an indiviual VPN is switched on, or not.

But if it's too much work for something not (high) on your priority list, I perfectly understand.

 

[Forerunner]

To me it does. I turn service state "ON" to service state "OFF" on the currently active VPN - internet connection dies.
I turn "Block routed clients if tunnel goes down" off, and it is back immediately.

I've tested this throughly, and upgraded to the latest Merlin version before posting here.


In that case, I propose to get rid of the manual "start with WAN" options for each VPN and simply replace it by a single switch in the general settings - that would reduce the total number of dials by four.

All the switch in the general settings would really do is determine if "start with WAN" is automatically activated when an indiviual VPN is switched on, or not.

But if it's too much work for something not (high) on your priority list, I perfectly understand.

If I turn the VPN off with the Block Routed clients turned to ON the Connection drops and I like it this way as it shows its working well.

 

[routerguy]

If I turn the VPN off with the Block Routed clients turned to ON the Connection drops and I like it this way as it shows its working well.

In which way? The reason I brought this up because to me, there is quite a difference between a dropped (!) tunnel and one that was deliberately closed. To me, this is unexpected behavior.

EDIT: Or rather "goes down". To me, if something goes down, it happens unassisted. Shutting it down on purpose is an entirely different scenario.

 

[Forerunner]

In which way? The reason I brought this up because to me, there is quite a difference between a dropped (!) connection and one that was deliberately closed. To me, this is unexpected behavior.

EDIT: Or rather "goes down". To me, if something goes down, it happens unassisted. Shutting it down on purpose is an entirely different scenario.

If I Turn the VPN off with the slide button it will drop the connection completely and block it.

 

[routerguy]

Re-Edited my previous post and replaced "connection" by "tunnel" to avoid misunderstandings.

 

[RMerlin]

The implementation is great Merlin I think its just right. Do you have any Plans to have PPTP manual routing or IKEv1 or 2 Implemented? as OpenVPN is slower on the router.

No plan on PPTP (I consider this a technnological deadend as PPTP security was broken a few years ago) or L2TP (kernel limitations).

 

[RMerlin]

To me it does. I turn service state "ON" to service state "OFF" on the currently active VPN - internet connection dies.
I turn "Block routed clients if tunnel goes down" off, and it is back immediately.

I've tested this throughly, and upgraded to the latest Merlin version before posting here.

I will have to recheck the different scenarios possible. It's been a long time since I've implemented them, so I don't remember the details of every specific scenarios.

In that case, I propose to get rid of the manual "start with WAN" options for each VPN and simply replace it by a single switch in the general settings - that would reduce the total number of dials by four.

Start with WAN is critical for anyone running a site-to-site tunnel, in case of power failures or router reboots. Not everyone uses clients just to tunnel their Internet connection.

 

[yorgi]

In which way? The reason I brought this up because to me, there is quite a difference between a dropped (!) tunnel and one that was deliberately closed. To me, this is unexpected behavior.

EDIT: Or rather "goes down". To me, if something goes down, it happens unassisted. Shutting it down on purpose is an entirely different scenario.

If you are on a VPN and downloading there is always the case where the VPN can do a hick-up and your ISP IP leaks to everyone.
The fact that we have a feature implemented that if the VPN tunnel goes down the traffic will be blocked is amazing.
Prior to using router VPN with merlin I was using PIA software and then OpenVPN software.
I saw the tunnel hick-up way to many times and I had software to constantly monitoring the tunnel that if it went down to drop the tunnel. its insane having to worry about that service crapping out for a millisecond until it re connects.
So it is a really amazing feature to have the tunnel secure when its not working.

Turning OFF the service is cool when you have 5 clients with different geometric zones its nice to be able to turn them on and off at your convenience.

With the Firmware you can have up to 5 VPN clients all on at the same time and you can switch from one client to another
just by changing IP address using selective routing or as its stated in the cleint firmware by "policy rules"
You can have multiple users on different clients and even local ISP all at the same time.

WAN at startup is great because like Merlin said if there is a power failure and you rely on that VPN then its a good idea to have the feature which will ensure a connected VPN when router reboots.

With a little imagination and scripting you can do anything you want to this router.
The features of Merlin's VPN are much superior to any other router firmware out there.

Keep up the great work Merlin and there is no reason to tamper with the way the VPN clients and servers are setup

 

[yorgi]

(1) "Block routed clients if tunnel goes down"

Obviously, this setting is very important, but from my experience, routed clients are also blocked if I disable the VPN manually. That doesn't make much sense to me, and it would probably be very easy for the firmware to recognize that I have hit the "OFF" switch (as opposed to the connection dying on its own). This adds convenience but also safety, because if this feature doesn't need to be deativated when people surf without VPN, they also can't forget to reactivate it when they turn the VPN back on.

if others are on the VPN and you turn it off then they would automatically fall into the Local ISP and thus leaking their Local ISP IP address which would not be a good thing.
The hole purpose of a VPN is to hide your Local ISP IP address.
When the client button is turned OFF it should automatically kill the VPN tunnel period!

The feature where if the tunnel drops due to server hick-up then the firewall rule drops the tunnel until its back up is crucial.
it's not the same as turning the server off via the button. Servers go down sometimes or the server decides to kill your connection for a millisecond and then reconnects you. I would not want to be someone downloading and something like that happens.
It is crucial that if the VPN tunnel drops or the server craps out for any reason that the tunnel traffic be stopped instantaneous!

There is no other firmware or router that does that feature. Just that alone is worth the ASUS router and Merlin firmware.

TomatoUSB and DWRT don't give you this feature, you would have to manually configure the firewall section to do that and its not easy.
Merlin did everyone a huge favor with these features that he implemented.

Both of these features are different from each other but are equally important for security.

Anything else would be a serious security issue!
the way it works now is the right way of doing it !

 

[routerguy]

unsubscribed

(Not giving up hope, though.)

 

[pixeler02]

I love the current "Block routed clients if tunnel goes down" implementation, but I would like to see some option to have "guest network" (wifi) always routed to WAN, while everything else would be set to use VPN.

Currently, it seems that the guest network uses the same DHCP randomization of IP assignment as the rest of the network.

It would be great if I could specify the DHCP range for guest network and then set only that range to bypass VPN under Policy Rules, or elsewhere.

This way I can set all my mobile devices and apple TV, etc to use the guest network, while ensuring my other computers are going through VPN.

 

[yorgi]

I love the current "Block routed clients if tunnel goes down" implementation, but I would like to see some option to have "guest network" (wifi) always routed to WAN, while everything else would be set to use VPN.

Currently, it seems that the guest network uses the same DHCP randomization of IP assignment as the rest of the network.

It would be great if I could specify the DHCP range for guest network and then set only that range to bypass VPN under Policy Rules, or elsewhere.

This way I can set all my mobile devices and apple TV, etc to use the guest network, while ensuring my other computers are going through VPN.

You can still do this easily. put the DHCP range for VPN and have it for guest network
and all your other devices have them as static IP address
this way in policy rules of the VPN you tell it 255.255.255.0 goes to VPN
and then all your static IP address's will go to WAN which would be Local ISP
or you can have specific static IP address's use the VPN as well

This is for all traffic to go to VPN but specific IP address's go to Local ISP
Under source IP put 255.255.255.0 and Destination IP 0.0.0.0 and lface VPN

Under source IP put 192.168.xxx.xxx Destination IP 0.0.0.0 and lface WAN
add as many lines as you have devices that you want to use for Local ISP

Also in LAN basic config in the IP Pool Starting Address put 192.168.1.100
as it is now by default DHCP uses 192.168.1.2-192.168.1.254
get those static IP address's to be out of the DHCP pool

another note
if you use Manually Assigned IP around the DHCP
make sure that the IP address's you use are in the Static Pool 192.168.1.2-192.168.1.99

otherwise it can really screw things up. I never understood why by default the DHCP takes all 254 address's by doing that, Static IP address's will not work properly

 

[BRING GUNS]

(1) "Block routed clients if tunnel goes down"

Obviously, this setting is very important, but from my experience, routed clients are also blocked if I disable the VPN manually. That doesn't make much sense to me, and it would probably be very easy for the firmware to recognize that I have hit the "OFF" switch (as opposed to the connection dying on its own). This adds convenience but also safety, because if this feature doesn't need to be deativated when people surf without VPN, they also can't forget to reactivate it when they turn the VPN back on.

At least to me, a single, general switch would be perfect: If any tunnel currently active goes down, block routed clients. If tunnels are shut down by users, don't block. A setting like that could be ON all the time, and nobody would ever need to worry. Convenient and safe at the same time!

Sorry to resurrect an old thread but I was about to make a thread asking if exactly this could be added and found that someone had already brought it up here!

I use my VPN solely on my PC and would love to be sure the tunnel isn't going down when I have the VPN turned on by using this feature, but I often turn the VPN off to game and it blocks the connection when I manually disable the VPN using the Service State switch. That behavior doesn't really make any sense to me but if some people like the current implementation then perhaps a third radio button could be added. Something along the lines of: Yes (always), Yes (active VPNs only), No
The Yes (active VPNs only) button could block routed clients if the tunnel goes down but not if the VPN has been purposely turned off by the user.