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