-
Hello.
There is the possibility to cascade OpenVPN clients by specifying the client from the next hop in the OpenVPN Client menu in Remote Network(s).
Unfortunately I cannot determine the order. If a VPN server is down, then the cascade will probably not work properly.
I have thought of a script that uses the data from "Gateway Groups".
If an OpenVPN server should fail, then the script could stop all OpenVPN clients and restart the order until the order is correct again.
Is it possible to implement something like this or does something like this already exist?
I would like to discuss in this thread what is possible and what not and would be willing to pay from 300€ for a script.
Greetings
John
Edit:
Cascade setup description:
https://forum.netgate.com/post/946943Configuration for a manual OpenVPN cascade start:
https://forum.netgate.com/post/946944Configuration for an automatic cascade start:
https://forum.netgate.com/post/946945 -
I'm not sure exactly what you mean by this.
You can already specify multiple remote server IPs on a client. Just add additional
remoteentries to the custom config field.
By default the client will try each on in turn but you can also set to to try them in random order.Steve
-
Ok, I found your ticket and can see what you're trying to do.
Have you actually tried to configure and test this?
There is a chance it will just work fine since if, for example, tunnel 3 went down when it came back up it would restart tunnel 2 since that is running on it. That in turn would restart tunnel 1.
I will say that this is definitely not a configuration that is covered by support though.
Steve
-
@stephenw10 said in OpenVPN Client Cascade:
Have you actually tried to configure and test this?
Unfortunately I don't even know how to configure this theoretically on pfSense. Until now I could configure a cascade with pfSense via virtual machines.
There is a chance it will just work fine since if, for example, tunnel 3 went down when it came back up it would restart tunnel 2 since that is running on it. That in turn would restart tunnel 1.
This is good news for me. Now I just need to know how.
I will say that this is definitely not a configuration that is covered by support though.
Maybe I get forum support here or maybe I get support from you?
Greetings
John
-
My first question here is why you are trying to do this? But that's probably an aside for another day!
So, yeah, try configuring and see what happens. Create the client for tunnel 3, assign it as an interface. Create the client for tunnel 2 and use the tunnel 3 interface to run it on. Assign the client 2 interface and create the tunnel 1 client on it.
It might just work.
I could also see it restarting all the tunnels every time meaning it just repeatedly restarts.
Steve
-
Cascades are used by many people. Just connect Router1-> Router2-> Router3-> in between. Why the others use cascades are reasons like day and night. My reason is because I am interested in the technology, even if I am not an expert.
Create the client for tunnel 2 and use the tunnel 3 interface to run it on. Assign the client 2 interface and create the tunnel 1 client on it.
How to configure it? What happens when Tunnel1 goes offline? How is it restarted automatically?
A security measure is still necessary.
If Tunnel1 goes offline, a firewall rule could block everything. Exactly the same way you would need such a rule for Tunnel2->Tunnel3->Internet. So that the order is always correct.Maybe I could solve this with floating rules.
Unfortunately I could only implement this for one tunnel.
One problem with this rule (for Tunnel3) is that if Tunnel3 is online and Tunnel1 and Tunnel2 are offline, the traffic still flows through Tunnel3. Unfortunately I don't know how to create a firewall rule for this.
-
Running 3 tunnels inside each other is not the same as just having a route that goes through 3 routers.
All ip traffic goes through multiple routers, that's how the internet works.
A tunnel within a tunnel within a tunnel is a very different thing. I have never seen that (except by accident!).The cannot come up in the wrong order because, for example, tunnel 1 (the inner most tunnel) cannot connect until tunnel 2 is UP because it's running on the tunnel 2 interface.
Tunnel 1 will continually try to establish as long as tunnel 2 is up.
An outbound block rule with a gateway like that is invalid. The gateway will not be applied and it will simply block all.
When you need to block there is traffic from the source subnet you're using.
You could also remove the outbound NAT rule that allows traffic from the internal subnet you're using to use the WAN.Your policy routing rule on LAN should send traffic across the inner tunnel, tunnel 1 here.
If you check 'Skip rules when gateway is down' in Sys > Adv > Misc that that will be omitted if Tunnel 1 goes down. If you don't have any other pass rules then traffic from LAN will be blocked when tunnel 1 is down.
Also 'Kill Switch' is a bad term to use there, it implies something you need to manually activate which is the last thing you want. Fail Safe would be much better.
Steve
-
@stephenw10 said in OpenVPN Client Cascade:
Running 3 tunnels inside each other is not the same as just having a route that goes through 3 routers.
All ip traffic goes through multiple routers, that's how the internet works.Is there a simple image diagram in Internet, like VPN-router1->VPN-router2->VPN router3->Internet to compare to a tunnel in tunnel connection for illustration?
The cannot come up in the wrong order because, for example, tunnel 1 (the inner most tunnel) cannot connect until tunnel 2 is UP because it's running on the tunnel 2 interface.
Tunnel 1 will continually try to establish as long as tunnel 2 is up.This makes sense, as you have explained. So the "protection" is already there, right?
The question is only how to configure tunnel in tunnel. The theoretical explanation usually always looks different than the practical pfSense configuration.
-
Maybe this might help you:
https://www.perfect-privacy.com/en/manuals/linux_openvpn_terminal_cascading -
@Pippin said in OpenVPN Client Cascade:
Maybe this might help you:
...I already know the link, but I am looking for a pfSense solution.
stephenw10 has already written that it could work:
@stephenw10 said in OpenVPN Client Cascade:
Create the client for tunnel 3, assign it as an interface. Create the client for tunnel 2 and use the tunnel 3 interface to run it on. Assign the client 2 interface and create the tunnel 1 client on it.
Unfortunately I do not know how to configure this.
-
Maybe now I understand what stephenw10 meant:
Create the client for tunnel 3, assign it as an interface. Create the client for tunnel 2 and use the tunnel 3 interface to run it on. Assign the client 2 interface and create the tunnel 1 client on it.
I would probably have to configure these interfaces in the OpenVPN client:
If I configure it like this:
VPN-Client1 - Interface (VPN-Client2)
VPN-Client2 - Interface (VPN-Client3)
VPN-Client3 - Interface (WAN)Then it does not work properly. Probably I would have to activate additional options.
For example:
If VPN-Client3 goes offline, then VPN-Client1 and 2 go offline. The connection is closed.
If VPN-Client3 is online and VPN-Client2 goes offline, then VPN-Client1 goes offline. The connection remains established via VPN-Client3.However, the connection should only work if VPN-Client 1,2 and 3 are online.
Does anyone have an idea how this can be adapted?
-
That's correct behaviour for the tunnels. You are probably routing the traffic incorrectly.
All of your unencrypted should go across tunnel 1.
Only encrypted traffic from the tunnel 1 client goes across tunnel 2 and the double encrypted traffic from the tunnel 2 client goes across tunnel 3.
You should not be routing anything from any internal interface to anywhere except the tunnel 1 gateway.
Steve
-
Somehow I can't get rid of the feeling that basic settings are missing.
Here is an example configuration with a VPN provider:
@stephenw10 said in OpenVPN Client Cascade:
You should not be routing anything from any internal interface to anywhere except the tunnel 1 gateway.
Can you show me an example of how the rule should look like?
I have the following behavior now:
If VPN-Client1 is online and the others are offline, then there is an internet connection, which should not be the case.
The reason is probably that the local address is almost always set to (pending).
If all 3 VPN-Clients are online and I restart them several times, then they are not set to (pending), but then the internet connection does not work either.
In short, there is a leak at (pending), and with a local address the client connections are terminated as intended, only with 3 local addresses there is no internet connection.
-
That looks to be configured as I would expect. The routing from LAN is correct, all policy routed to the tunnel 1 gateway.
I agree though tunnel 1 should not be able to come up until tunnel 2 is up becasue it is running on that interface.
Maybe the interface assignments are wrong?
Steve
-
@stephenw10 said in OpenVPN Client Cascade:
Maybe the interface assignments are wrong?
No, the interfaces seem to be correct.
If you have Tunnel1 up after Tunnel2 is up, then I suspect that I am missing basic settings.
-
Can we see the assignments? I'm not sure how tunnel 1 can be UP when it doesn't have a local address because tunnel 2 is DOWN and that's what it's running on.
Steve
-
-
Hmm, check the OpenVPN logs. Check the state table. What is tunnel 1 actually running on if tunnel 2 is down?
Steve
-
I cannot interpret the logs. Here are the logs, if only Tunnel1 is up:
-
It looks like you have the OpenVPN logging options set waaay too high. All of that is just the config it's using not the actual connection process. Set it logging level back to the defaults ot just get the logs covering the connection process.
Though what I am seeing there is that the local side of the connection shows as not bound to an IP. That's probably what allows it to connect when T2 is down. Without a T2 address it probably omits the local statement from the config. You could check that in /var/etc/openvpn/client1.conf
I'm not sure you can force that in pfSense. What you could do would be to add floating outbound block rules on WAN for the T1 and T2 server IPs so only T3 can connect directly.
I still expect T2 and T3 to be trying to connect in that situation though and it appears they are not.
If you can copy/paste the actual logs into replies using he code tags it's much, much easier to search than pictures on the logs.
Steve
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.