Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN Client Cascade

    Scheduled Pinned Locked Moved OpenVPN
    48 Posts 3 Posters 6.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

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

      Steve

      1 Reply Last reply Reply Quote 0
      • J
        John2893ax
        last edited by

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

        f6270601-f953-4fc1-be4e-e54d980cf13c-grafik.png
        5bf1c82a-1d7b-462a-9fa6-6bca2cebdc11-grafik.png
        c2cdf4de-5d20-484f-9b5a-8d4f6dc8f2aa-grafik.png

        4370b63c-83d6-4e08-8e52-63f67a269414-grafik.png

        49eb4748-e751-47f6-8d2b-9780c64c6899-grafik.png

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by 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

          1 Reply Last reply Reply Quote 0
          • J
            John2893ax
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Like this:

              Screenshot_2020-10-25 2220 stevew lan - Firewall Rules Floating Edit.png
              And the same the T2 server IP. Only the T3 server IP should be seen as an outbound connection on WAN.

              Steve

              1 Reply Last reply Reply Quote 0
              • J
                John2893ax
                last edited by

                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?

                Screenshot_2020-10-25 pfSense localdomain - Firewall Rules Floating.png

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

                Screenshot_2020-10-25 pfSense localdomain - Status OpenVPN.png

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

                I don't know how this is meant.

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by 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

                  1 Reply Last reply Reply Quote 0
                  • J
                    John2893ax
                    last edited by

                    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:

                    3dba7c21-6206-4c70-ada4-2288e24ecd8b-grafik.png

                    556d22d9-48e9-489c-a370-181c71989fb6-grafik.png

                    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?

                    95b8dcea-f476-4c15-a01c-ff0e44da7a4e-grafik.png

                    The same is also for T3.

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

                    1 Reply Last reply Reply Quote 0
                    • J
                      John2893ax
                      last edited by John2893ax

                      Edit:

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

                      I currently have the following servers:

                      Screenshot_2020-10-29 pfSense localdomain - VPN OpenVPN Clients.png

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

                      1. the 2 floating rules work

                      Screenshot_2020-10-29 pfSense localdomain - Firewall Rules Floating.png

                      1. T1 and T2 shows only ICMP protocol.

                      Screenshot_2020-10-29 pfSense localdomain - Diagnostics States States.png

                      Screenshot_2020-10-29 pfSense localdomain - Diagnostics States States(1).png

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

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

                      1 Reply Last reply Reply Quote 0
                      • J
                        John2893ax
                        last edited by

                        Edit2:

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

                        Like for example here?

                        53c77d11-aa12-433b-91fb-15f4c08e5b25-grafik.png

                        Screenshot_2020-10-29 pfSense localdomain - Diagnostics Routes.png

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

                        677121fc-7c4f-449b-9f7a-dac83972f660-grafik.png

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • J
                            John2893ax
                            last edited by 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.

                            1 Reply Last reply Reply Quote 0
                            • J
                              John2893ax
                              last edited by

                              OK. Whether with or without remote network(s) makes no difference.

                              b3e92805-a2b8-4fd5-b461-43d9a72c9744-grafik.png

                              The rules in the image currently do the following after a reboot:

                              1. Under States/WAN I only see T3.

                              Screenshot_2020-10-29 pfSense localdomain - Diagnostics States States.png

                              1. Under States/T2 I see nothing.

                              2. Under States/T3 I see T1 and T2. I do not know if this is correct.

                              Screenshot_2020-10-29 pfSense localdomain - Diagnostics States States(1).png

                              1. There is no internet connection with floating rules.

                              Do I understand correctly that the rules must look like this?

                              • Under States/WAN I should see T3.
                              • Under States/T1 I should see T2.
                              • Under States/T2 I should see T3.
                              • Under States/T3 I should see WAN.

                              Would that be correct?

                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                No. You should see~:

                                States on WAN - T3
                                States on T3 - T2
                                States on T2 - T1

                                So you need a floating outbound reject rule on T3 to reject the T1 destination. It should only be able to create states on T2.

                                Steve

                                1 Reply Last reply Reply Quote 0
                                • J
                                  John2893ax
                                  last edited by

                                  @stephenw10 said in OpenVPN Client Cascade:

                                  So you need a floating outbound reject rule on T3 to reject the T1 destination

                                  Unfortunately I do not know how to configure this.
                                  Also I don't know which rule should be at the top and which at the bottom.

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    The ordering is not important since this will be the only floating rule applied to the T3 interface.

                                    Thinking about it you could just edit your existing floating rule for the T1 server destination and make it apply to WAN an T3 so can only ever open on T2.

                                    Steve

                                    1 Reply Last reply Reply Quote 0
                                    • J
                                      John2893ax
                                      last edited by

                                      It makes no difference whether with these rules

                                      Screenshot_2020-10-30 pfSense localdomain - Firewall Rules Floating(1).png

                                      or with these rules

                                      Screenshot_2020-10-30 pfSense localdomain - Firewall Rules Floating.png

                                      In both cases the T1 client is down and I have no internet connection.

                                      Screenshot_2020-10-30 pfSense localdomain - Status OpenVPN.png

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        But it does prevent the T1 connection coming up in the wrong place?

                                        It just fails entirely?

                                        Steve

                                        1 Reply Last reply Reply Quote 0
                                        • J
                                          John2893ax
                                          last edited by

                                          @stephenw10 said in OpenVPN Client Cascade:

                                          But it does prevent the T1 connection coming up in the wrong place?

                                          Yes.

                                          It just fails entirely?

                                          I do not know how to check it.

                                          Under OpenVPN Log always says after reboot:

                                          Oct 31 18:29:10 	openvpn 	28024 	write UDPv4: Permission denied (code=13)
                                          Oct 31 18:29:10 	openvpn 	28024 	write UDPv4: Permission denied (code=13)
                                          Oct 31 18:29:11 	openvpn 	28024 	write UDPv4: Permission denied (code=13)
                                          Oct 31 18:29:11 	openvpn 	28024 	write UDPv4: Permission denied (code=13)
                                          Oct 31 18:29:12 	openvpn 	28024 	write UDPv4: Permission denied (code=13)
                                          Oct 31 18:29:12 	openvpn 	28024 	write UDPv4: Permission denied (code=13)
                                          Oct 31 18:29:13 	openvpn 	28024 	write UDPv4: Permission denied (code=13) 
                                          

                                          I have:
                                          States on WAN-T3
                                          States on T3-T2
                                          States on T2-nothing

                                          T3-T1 is no longer present.

                                          I can T1 no longer restart manually.

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            Permission denied like that usually means the firewall is preventing it. Which either means it's trying to start on WAN or T3 and getting blocked or the rules are incorrectly blocking it on T2.

                                            If it's the former I'm not really sure what we can do from there. There doesn't appear to be any way to set a specific outbound interface for it to use when that interface is dynamic.

                                            Since you know the destination IPs here you could set a route to each on the correct client.
                                            So try adding it as a remote network (/32). I.e. add the T1 server IP as a remote network on the T2 client. That should add a route to it and the T1 client should then use it.

                                            Steve

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.