OpenVPN Client Cascade

[John2893ax]

@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.

[John2893ax]

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?

[stephenw10]

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

[John2893ax]

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.

[stephenw10]

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

[John2893ax]

@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.

[stephenw10]

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

[John2893ax]

@stephenw10 said in OpenVPN Client Cascade:

Can we see the assignments?

Of course.

[stephenw10]

Hmm, check the OpenVPN logs. Check the state table. What is tunnel 1 actually running on if tunnel 2 is down?

Steve

[John2893ax]

I cannot interpret the logs. Here are the logs, if only Tunnel1 is up:

[stephenw10]

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

[John2893ax]

I have now set verbosity level "default" for all 3 servers.

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.

Just for information.
All 3 servers use the same "CA" and "Cert" certificate. With "Server host or address" I can also use amsterdam.vpn.com, then a server from Amsterdam1-5 is automatically selected.
Instead of amsterdam.vpn.com, I can also specify the following:
amsterdam1.vpn.com
amsterdam2.vpn.com
amsterdam3.vpn.com
amsterdam4.vpn.com
amsterdam5.vpn.com
I'm not sure if this is the reason for conflicts.

I will try to add other servers. For example, Basel, London or Paris and see if there are still conflicts.

You could check that in /var/etc/openvpn/client1.conf

Here is client1.conf:

dev ovpnc1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
inactive 604800
ping 5
ping-restart 120
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-128-GCM
auth SHA512
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
tls-client
client
nobind
management /var/etc/openvpn/client1/sock unix
remote 85.17.28.145 1149 udp4
auth-user-pass /var/etc/openvpn/client1/up
auth-retry nointeract
capath /var/etc/openvpn/client1/ca
cert /var/etc/openvpn/client1/cert 
key /var/etc/openvpn/client1/key 
tls-auth /var/etc/openvpn/client1/tls-auth 1
ncp-disable
comp-noadapt
resolv-retry infinite
route-nopull
hand-window 120
mute-replay-warnings
persist-remote-ip
reneg-sec 3600
resolv-retry 60
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
tun-mtu  1500
fragment 1300
mssfix
remote-cert-tls server

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.

Let's assume for now that pfSense cannot force this. How exactly do I create the rules?

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.

I can't add logs because the VPN provider is reported as spam.

[stephenw10]

Like this:

And the same the T2 server IP. Only the T3 server IP should be seen as an outbound connection on WAN.

Steve

[John2893ax]

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.

And the same the T2 server IP.

Okay. I understood that I should only create two rules.

Like these?

T3 can still connect, but the others are (pending).

Only the T3 server IP should be seen as an outbound connection on WAN.

I don't know how this is meant.

[stephenw10]

I mean if you look at the states for port 1149 (:1149) on WAN you should only see the T3 client.

Check the logs to see what the T2 client is doing. It should be trying to connect on the T3 client interface. If it isn't what is it doing? Did it error out trying to connect before T3 had connected and stop?

Steve

[John2893ax]

Sorry for the stupid questions, but are floating rules for t1 and t2 correct?

Only the T3 server IP should be seen as an outbound connection on WAN.

Does this refer to floating t2 rule or to a new one with t3?

I mean if you look at the states for port 1149 (:1149) on WAN you should only see the T3 client.

Here is the output:

Check the logs to see what the T2 client is doing. It should be trying to connect on the T3 client interface.

At Diagnostics-> States?

The same is also for T3.

Does that mean that all 3 tunnels run parallel and not tunnel through tunnel?

[John2893ax]

Edit:

Different city clients seem to work better than a group of clients from one city.

I currently have the following servers:

When I restart pfSense, I get completely different results than when I start the servers manually.

1. the 2 floating rules work

2. T1 and T2 shows only ICMP protocol.

3. The traffic goes through T3, but there is no internet connection

When I manually restart the clients, the servers do not start again.

[John2893ax]

Edit2:

Maybe I have to set the routes manually in the OpenVPN client under "Remote Network(s)"?

Like for example here?

But which settings would I then have to set for T3?

[stephenw10]

Did you set the direction as OUT on those floating rules?

Did you reset the state table or reboot since you added them?

You have at least one state on WAN that should have been rejected by that outbound floating rule.

You should not see any states on WAN foe OpenVPN tunnels except tunnel 3.

The fact they are up means they are not running tunnel-in-tunnel as you say.

Steve

[John2893ax]

Did you set the direction as OUT on those floating rules?

Yes.

Did you reset the state table or reboot since you added them?

I always enabled "Reset the firewall state table" under Diagnostics/States/Reset States and pressed [Reset]. In any case I assumed that it would work. Only with a reboot the floating rules and the start of the tunnel sequence worked simultaneously.

You should not see any states on WAN foe OpenVPN tunnels except tunnel 3.

Without remote network(s) entries in the OpenVPN client I see all 3 servers under States/WAN. So they are not running tunnel in tunnel.

But I have to test again if with remote network(s) only the third server is visible.