VPN Director Rules

[Kal1975]

Question about VPN director rules. I have the following rules set up in VPN director. I have 5 VPN clients defined and all are set to use a kill switch, as shown. What happens if there are no VPN clients active, using these rules?

When I check other devices not listed here, they seem to use the WAN interface, which is not what I want. What should I add so that if all VPN clients are down, those not specified in the list do not go through the WAN/have no route through the WAN?

 

[eibgrad]

By default, anything NOT defined in the VPN Director is routed over the WAN. You have to define explicit rules to force devices over the VPN. So if devices are NOT bound to the VPN and you want them blocked over the WAN, that makes no sense. Those devices effectively has no internet access AT ALL!

 

[Kal1975]

So, if I understand what you're saying, I have to explicitly create a rule for each device that I want to go over one of the VPN connections. That would be five rules for each device in case I switch from one VPN client to another. When all VPN clients are down, because there is a specific rule for a device, it would not default to go over the WAN.

So, the last rule that specifies all of the 192.168.1.x IP addresses would not be used? However, when you specify a specific IP address it is used? If that's the case, it's probably better to specify for each IP address in your network, whether it goes over the WAN or any/all VPN clients you have defined.

 

[eibgrad]

You might be overthinking this a bit.

Again, if you do NOT have a rule specified to route a given IP (source and/or destination) over the VPN, those packets get routed over the WAN. That does NOT mean you necessarily have to create a rule for each and every device. You can group them into ranges and use CIDR notation to cut down on the number of required rules.

For example, a valid rule that would route everything on the local network over the VPN could use 192.168.1.0/24. Or some range within that network. For example, 192.168.1.32 thru 192.168.1.63 could be represented as 192.168.1.32/27. How do I know that?

CIDR to IPv4 Address Range Utility Tool | IPAddressGuide

Free IP address tool to translate IPv4 address range into CIDR (Classless Inter-Domain Routing) format and vice-versa.

www.ipaddressguide.com

For any device bound to the VPN and for which the killswitch is active for that OpenVPN client, those packets will be blocked from the WAN should it fail.

In your diagram above, you've bound the entire network (192.168.1.0/24) to all the VPNs, then defined exceptions for the WAN, which is fine. It works because the WAN rules always take precedence over the VPN rules.

 

[Kal1975]

OK. So with my rules where everything is bound to the VPNs, that would mean when all VPN clients are down, then those devices that are not defined to go through the WAN should not be able to access the internet.

However, what's happening is when all the VPN clients are down, is that the one device I'm testing with get's my WAN public IP address. I'm using

curl https://icanhazip.com

to get the WAN IP address on the one device I'm testing with. When one of the VPN clients is running, I get the public IP address for that VPN connection.

 

[eibgrad]

We have to be careful in the use of our terms here. When you say the VPN is down, what does that mean? If YOU manually shutdown the VPN, the killswitch is turned OFF! The killswitch will only be maintained should it fail by itself, unexpectedly. But when YOU turn it OFF, that's NOT an unexpected situation. The router interprets that to mean you want the VPN *and* the killswitch disabled.

P.S. If you want to simulate a failure, kill the OpenVPN client's process (based on its process ID) in the process table.

kill <process-id>

 

[eibgrad]

You can using the following one-liner to kill a given OpenVPN client from the shell.

kill $(ps | grep [v]pnclient1 | awk '{print $1}')

If you're using a different OpenVPN client than #1, adjust accordingly.

If the killswitch is active, then you'll see a special route called "prohibit default" appear in that OpenVPN client's routing table.

ip route show table ovpnc1

That's what actually prevents access to the WAN, or more precisely, prevents access to any default gateways (WAN or VPN) unless and until the VPN is reestablished.

 

[Kal1975]

That would be what I probably have been experiencing then. I'd imagine that also includes if a VPN client wasn't even started in the first place...such as if there was no VPN client set to automatically start on a reboot.

Thanks.

 

[eibgrad]

That would be what I probably have been experiencing then. I'd imagine that also includes if a VPN client wasn't even started in the first place...such as if there was no VPN client set to automatically start on a reboot.

Thanks.

If you set the OpenVPN client to autostart, and have the killswitch enabled, it will enforce the killswitch immediately upon reboot, and maintain it indefinitely. But as before, if you manually turn OFF the OpenVPN client, then this disables the killswitch too.

So it just comes down to whether you want the killswitch enforced from a bootup, or only on demand.

 

[DMcD-EMS-USMC]

If you set the OpenVPN client to autostart, and have the killswitch enabled, it will enforce the killswitch immediate upon reboot, and maintain it indefinitely. But as before, if you manually turn OFF the OpenVPN client, then this disables the killswitch too.

So it just comes down to whether you want the killswitch enforced from a bootup, or only on demand.

Being new here, I am truly impressed with your patience and breadth of knowledge-just reading your replies to different issues exposes a wealth of information which has helped me personally and I am sure the rest of the community-my hat is off to you and all on this board that try and lift us up by our bootstraps. Bravo Zulu eibgrad.

 

[Kal1975]

@eibgrad You mentioned that I should see "prohibit default" in the OpenVPN client's routing table.

I was changing my VPN Director rules and was checking the active OpenVPN client's routing table using:

ip route show table ovpnc1

I did not see "prohibit default" in the list. I have killswitch set to on for that and all OpenVPN clients.

FYI, I flipped my rules around. Instead of specifying that .0/24 goes through the VPN and specifying individual clients that go through the WAN, I now only specify individual clients that go through the VPN and all others use the default, without any rules, to go through the WAN.

Any ideas about why "prohibit default" is not in the routing table for the active VPN client?

 

[eibgrad]

Any ideas about why "prohibit default" is not in the routing table for the active VPN client?

The "prohibit default" only appears in the routing table once the OpenVPN client fails! IOW, when it actually needs it. You can simulate a failure by killing the process ID for the OpenVPN client in the process table.

Using ssh and the following command will do the trick.

kill $(ps | grep [v]pnclient1 | awk '{print $1}')