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

    OpenVPN multiple site-to-site problem

    Scheduled Pinned Locked Moved OpenVPN
    16 Posts 2 Posters 1.6k 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.
    • M
      M0L50N
      last edited by

      Hi,

      I've setup a multi-sites vpn with 3 pfsense. 1 server and 2 on other sites (site A and Site B)

      My tunnels are mounted in TLS/SSL and connect correctly. Before setup the Site B, Site A with server communicated number 1, ping PC from server side to Site A and vice-versa = OK

      Since I added Site B, I have a routing problem. I'm almost certain the problem is with my IPV4 Tunnel VPN adressing. When I check my routes at server's side, I see that route to Site A and Route to site B have the same Gateway IP, I dont think it's normal.

      On server, in each client specific override setting for each site, I've put the same IPV4 Tunnel Network 192.168.130.0/28 (same as OpenVPN Tunnel server) ... server took the 192.168.130.1 and Site A and B took the 192.168.130.2 ?!?!?!? how can I correct that?

      THanks!

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @M0L50N
        last edited by

        @M0L50N said in OpenVPN multiple site-to-site problem:

        On server, in each client specific override setting for each site, I've put the same IPV4 Tunnel Network 192.168.130.0/28 (same as OpenVPN Tunnel server)

        You must set a different subnet for each client.
        For client A set the tunnel to 192.168.30.34/30
        and for client B to 192.168.30.38/30

        On the clients leave the tunnel box blank.

        1 Reply Last reply Reply Quote 1
        • M
          M0L50N
          last edited by

          OK. I tried but not working ... maybe I misunderstood something

          Server side IPV4 Tunnel Network : 192.168.130.0/28
          Modify my "client specific override" on server for : Site A 192.168.130.34/30, site B 130.38/30
          Client Side : blank the IPV4 Tunnel network (I assume with that setup, client connect to server and check for the IP Tunnel setup on the server in the client specific override)

          My site A is on local network 192.168.2.0/24, and Site B network 192.168.31.0. A route is missing on the server, dunno why it is not create itself with setting I've made?!?!?

          I joined a screenshot for the routes on my server. Thanks to help me understand.routes.JPG

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @M0L50N
            last edited by

            @viragomann said in OpenVPN multiple site-to-site problem:

            For client A set the tunnel to 192.168.30.34/30
            and for client B to 192.168.30.38/30

            These aren't network addresses. Can't believe that I suggusted this. Sorry, my mistake, must have been tired.
            There must be stated correct network addresses in the tunnel network box.

            @M0L50N said in OpenVPN multiple site-to-site problem:

            Site A 192.168.130.34/30, site B 130.38/30

            These are also not networks.
            Use 192.168.130.32/30 and 192.168.130.36/30 instead.

            Establish a connection from the client and see if it gets the correct IP (192.168.130.34 respectively 192.168.130.38 if using above networks).

            1 Reply Last reply Reply Quote 1
            • M
              M0L50N
              last edited by

              I tried what you said and same problem. I decide to change my tunnel IP address server Side to 192.168.130.0/24. In same time, on server pfsense, I delete the Tunnel IPV4 Network from "Client Specific override" for Network A and Network B.

              Then I deleted the Tunnel IPV4 Network from client OpenVPN config in pfsense Network A and and pfsense Network B.

              That works, but something is missing I think
              Network B (192.168.31.0) can ping network A (192.168.2.0) and Server Side (192.168.1.0)
              Network A can ping server side, but no Network B
              Server Side can ping Network A, but no Network B
              (Network B PC Firewall is disable and pfsense network B can ping PC on network B side)

              OpenVPN virtual address client Network A : 192.168.130.2
              OpenVPN virtual address client Network A : 192.168.130.3

              I joined route's screen shot for my 3 pfsense. On server's side route, it's anormal that gateway for the route to join network B (192.168.31.0) is 192.168.130.2 (same as route to network A 192.168.2.0) ?!?!?!? I think that's my problem but I dont know how to resolve that.

              Thanks for your suggestion or correct me if I'm far from best practice, I want to be sur everything will be ok before put these routers in production!

              Thanks!routes-Server Side.JPG routes-NetworkA.JPG routes-NetworkB.JPG

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @M0L50N
                last edited by

                @M0L50N said in OpenVPN multiple site-to-site problem:

                OpenVPN virtual address client Network A : 192.168.130.2
                OpenVPN virtual address client Network A : 192.168.130.3

                You mean B in the second line.

                So the client specific overrides are not applied.

                Check again if the configuration is correct. Since you are using TLS, the "Common Name" in the CSO has to match the common name in the respective clients certificate.
                Also "Username as Common Name" in the server settings should be unchecked.

                M 1 Reply Last reply Reply Quote 0
                • M
                  M0L50N @viragomann
                  last edited by

                  @viragomann Yes sorry ... second line is Network B.

                  Is Client specific Override really "override" the client open vpn configured on the client pfsense?!?! ... does it mean OpenVPN Client configuration on client pfsense have no influence?

                  I check my config so many times ... CN is ok, no tunnel IPV4, remote network and local network are OK ...

                  V 1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @M0L50N
                    last edited by

                    @M0L50N said in OpenVPN multiple site-to-site problem:

                    s Client specific Override really "override" the client open vpn configured on the client pfsense?!?! ... does it mean OpenVPN Client configuration on client pfsense have no influence?

                    No. It overrides only the server settings for the specified client.

                    But the CSO is obviously not applied.
                    Are there spaces in the CN?

                    Check the OpenVPN log on the server for hints. Maybe increase the log level.

                    1 Reply Last reply Reply Quote 0
                    • M
                      M0L50N
                      last edited by

                      I re-recheck my setup ... eveything seem to be good.

                      Check this log on server while I connect the OpenVPN client from Network B

                      Nov 17 14:24:20 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 WRITE [62] to [AF_INET]206.133.45.45:1196: P_ACK_V1 kid=0 pid=[ #9 ] [ 6 ]

                      pid=6 DATA len=283

                      Nov 17 14:24:20 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 READ [62] from [AF_INET]206.133.45.45:1196: P_ACK_V1 kid=0 pid=[ #12 ] [ 6 ]
                      Nov 17 14:24:20 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 READ [180] from [AF_INET]206.133.45.45:1196: P_DATA_V2 kid=0 DATA len=179
                      Nov 17 14:24:20 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 MULTI: bad source address from client [::], packet dropped
                      Nov 17 14:24:20 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 READ [132] from [AF_INET]206.133.45.45:1196: P_DATA_V2 kid=0 DATA len=131
                      Nov 17 14:24:20 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 MULTI: bad source address from client [::], packet dropped
                      Nov 17 14:24:23 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 READ [180] from [AF_INET]206.133.45.45:1196: P_DATA_V2 kid=0 DATA len=179
                      Nov 17 14:24:30 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 WRITE [84] to [AF_INET]206.133.45.45:1196: P_DATA_V2 kid=0 DATA len=83
                      Nov 17 14:24:33 openvpn 55959 Tunnel-Client-ARE/206.133.45.45:1196 UDPv4 READ [84] from [AF_INET]206.133.45.45:1196: P_DATA_V2 kid=0 DATA len=83

                      1 Reply Last reply Reply Quote 0
                      • V
                        viragomann
                        last edited by

                        These shows some packets of an existing connection, but not the initialization sequence.

                        Try verbosity level 4, to avoid to much details.

                        1 Reply Last reply Reply Quote 1
                        • M
                          M0L50N
                          last edited by

                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Re-using SSL/TLS context
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Control Channel MTU parms [ L:1622 D:1172 EF:78 EB:0 ET:0 EL:3 ]
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-128-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-server'
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-client'
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 TLS: Initial packet from [AF_INET]207.134.134.179:1196, sid=204e18b6 43b5d67d
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 VERIFY SCRIPT OK: depth=1, CN=RPFSayabec-Tunnels-CA, C=CA, ST=Quebec, L=Sayabec, O=GroupeRPF
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 VERIFY OK: depth=1, CN=RPFSayabec-Tunnels-CA, C=CA, ST=Quebec, L=Sayabec, O=GroupeRPF
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 VERIFY SCRIPT OK: depth=0, CN=Tunnel-Client-ARE, C=CA, ST=Quebec, L=Amqui, O=ARE
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 VERIFY OK: depth=0, CN=Tunnel-Client-ARE, C=CA, ST=Quebec, L=Amqui, O=ARE
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_VER=2.4.9
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_PLAT=freebsd
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_PROTO=2
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_LZ4=1
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_LZ4v2=1
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_LZO=1
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_COMP_STUB=1
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_COMP_STUBv2=1
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 peer info: IV_TCPNL=1
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
                          Nov 17 18:57:44 openvpn 2941 207.134.134.179:1196 [Tunnel-Client-ARE] Peer Connection Initiated with [AF_INET]207.134.134.179:1196
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn-csc/server3/Tunnel-Client-ARE
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI_sva: pool returned IPv4=192.168.130.2, IPv6=(Not enabled)
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI: Learn: 192.168.130.2 -> Tunnel-Client-ARE/207.134.134.179:1196
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI: primary virtual IP for Tunnel-Client-ARE/207.134.134.179:1196: 192.168.130.2
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI: internal route 192.168.31.0/24 -> Tunnel-Client-ARE/207.134.134.179:1196
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI: Learn: 192.168.31.0/24 -> Tunnel-Client-ARE/207.134.134.179:1196
                          Nov 17 18:57:44 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 REMOVE PUSH ROUTE: 'route 192.168.31.0 255.255.255.0'
                          Nov 17 18:57:45 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 PUSH: Received control message: 'PUSH_REQUEST'
                          Nov 17 18:57:45 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 SENT CONTROL [Tunnel-Client-ARE]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.2.0 255.255.255.0,route 192.168.4.0 255.255.255.0,route-gateway 192.168.130.1,topology subnet,ping 10,ping-restart 60,route 192.168.1.0 255.255.255.0,ifconfig 192.168.130.2 255.255.255.0,peer-id 0' (status=1)
                          Nov 17 18:57:46 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI: bad source address from client [::], packet dropped
                          Nov 17 18:57:46 openvpn 2941 Tunnel-Client-ARE/207.134.134.179:1196 MULTI: bad source address from client [::], packet dropped

                          1 Reply Last reply Reply Quote 0
                          • M
                            M0L50N
                            last edited by

                            I miss something. I really think my problem is with IPV4 Tunnel adressing, but I can't put the finger on it.

                            OpenVPN server, client specific ovewrride and client setup have the same IPV4 tunnel network : 192.168.130.0/24

                            I know the server took the first IP of the tunnel (192.168.130.1) and client will take .2 and .3. How does it work for the decision who take .2 who take .3? Client Virtual Address network client A is 192.168.130.3 and client B is on 192.168.130.2. If you check Routing screenshot I sent before, never you will see a route on server with Gateway 192.168.130.3 ... then it's normal server side can't access the network on the openVPN client side with virtual address 192.168.130.3 ??!?!

                            How can I correct that? Add manually the route? That's not what I want, I want the system to be setup in the best pratices!

                            Thanks for your suggestions!

                            1 Reply Last reply Reply Quote 0
                            • M
                              M0L50N
                              last edited by M0L50N

                              Ok! I answer to myself, but I want to let you know what's happen and maybe someone will have suggestion! :)

                              I think my IPV4 tunnel adressing is ok. I've put server on 192.168.130.0/24 and client A to 192.168.130.3/24 client B 192.168.130.5/24. Tunnel are correct. I understand that my openvpn server always use the same gateway to connect to a specifi OVPN. Whatever network on the same Tunnel. If I understand correctly, routes in OpenVPN routing table are not the same than Status/routes. OpenVPN have his own soute subsystem.

                              Something is weird : Network A and Network B have any problem ping server side, but server can only ping Network A. Server can ping Network B only if I start a ping from network B to server side?!?!?!?! If I stop pinging each other, wait 30 seconds, start to ping from server to Network B = nothing pass ... start one ping from network B to server; = ping from server to network B restart to pass!?!? :)

                              Another thing. On my openVPN server, I dont have option "Allow communication between clients connected to this server" enable, however, Network B can pinb Network A but not the other way.

                              Maybe the bug is related to all of this?!?!?

                              Thanks all to try to give me any idea to help my resolve this!

                              V 1 Reply Last reply Reply Quote 0
                              • V
                                viragomann @M0L50N
                                last edited by

                                @M0L50N
                                So the CSO is applied, but nevertheless the clients get wrong virtual IPs. So presumably you didn't configure them correctly.

                                M 1 Reply Last reply Reply Quote 0
                                • M
                                  M0L50N @viragomann
                                  last edited by

                                  @viragomann is it good practice in the CSO to force the client virtual IP by putting 192.168.130.3/24 client A, 130.5/24 client B? Is this way logical? Or it's better to not specifie any IP for client et let the OpenVPN server manage that and give good IP?"!!?

                                  V 1 Reply Last reply Reply Quote 0
                                  • V
                                    viragomann @M0L50N
                                    last edited by

                                    @M0L50N
                                    I suggested above to set the tunnel for A to 192.168.130.32/30 and for B to 192.168.130.36/30.
                                    Additional I would use a net /30 topology in the server settings. So each client gets its own /30 subnet with an IP for the server and one for the client.

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