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

    pfSense OpenVPN client/server (site to site)

    OpenVPN
    2
    12
    1.2k
    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.
    • W
      wmcneil
      last edited by

      Hello pfSense folks, I have spent a lot of time trying to debug a OpenVPN issue, I think I have a good summary of the issue, and good pictures and screenshots below. Thanks in advance for help on this:

      I have created a pfSense OpenVPN client at one site, which is connecting to a pfSense OpenVPN server at another site. The pfSense client is connecting, and on the client side I can ping server-side local IPs, but I am otherwise unable to access the server-side local IPs, for example I can not connect to the pfSense server-side GUI.

      I created the OpenVPN client using an import of the OpenVPN configuration exported from the pfSense OpenVPN server. On the client side, if I use a windows OpenVPN client instead of the pfSense OpenVPN client, everything works fine.

      I don't see any deny rules causing problems with the server-side local IPs in the pfSense client firewall logs.

      Attached is a picture and routing tables for the setup that is failing:
      beae0163-6be9-4eb6-8941-c9d67299e37d-image.png

      Here are all the rules for the pfSense client:
      1ad3a3a7-efdd-4d39-b30f-c625c5cf4ad0-image.png

      Here are all the rules for the pFsense server:
      237d264d-c087-4090-9f2a-b2cefc8dad2d-image.png

      Finally, here is a picture and routing tables for the same server connected with a windows OpenVPN client:
      0f4493cd-863f-4ed0-8366-9c43d6f07499-image.png

      1 Reply Last reply Reply Quote 0
      • W
        wmcneil
        last edited by

        I figured out how to solve the original problem, and now have one remaining issue:

        Solution to original problem: The client side is enabled to access server side local IPs by adding this Mapping rule on the client pfSense firewall / NAT /outbound (using Hybrid Outbound Nat rule generation):
        c74ab4a4-c7a9-48eb-be63-4bc67eedafe0-image.png

        Remaining issue: The server side can not access client side local IPs. I tried adding this Mapping rule ono the server pfSense firewall / NAT /outbound (using Hybrid Outbound Nat rule generation), but it is not solving the problem:
        aff45da6-5e61-44d1-b0bf-7abe2e811a80-image.png

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

          @wmcneil said in pfSense OpenVPN client/server (site to site):

          Solution to original problem: The client side is enabled to access server side local IPs by adding this Mapping rule on the client pfSense firewall / NAT /outbound (using Hybrid Outbound Nat rule generation):

          That enables you to access the remote site, but you lose the info about the origin clients IP. Would be better to configure the routing properly than doing masquerading. But that's on you.

          Are there multiple clients connecting to this server?
          If not, switch the server into site to site mode and change the tunnel mask to /30.

          W 1 Reply Last reply Reply Quote 0
          • W
            wmcneil @viragomann
            last edited by

            @viragomann
            I have two scenarios for the server side: A case where multiple clients connect to the server (all of those client cases are windows machines), and also a case where the client is a pfSense router. These are all my personal scenarios.

            For the former case, I've go things working as desired as described above.

            For the latter case:

            • With regards to the solution I posted for client-side being able to use server side local IPs, I don't have enough knowledge to comment on your points about limitations. I did use the pfSense OpenVPN configuration import, so if the routing is not set up properly it seems the pfSense import shares some responsibility.
            • With regards to solving the problem for server-side not being able to use client-side IPs, I will have to try setting up site-to-site. That seems less burdensome than other solutions I can think of to try.
            V 1 Reply Last reply Reply Quote 0
            • V
              viragomann @wmcneil
              last edited by

              @wmcneil
              So you have set up an access server allowing multiple clients to connect. But if you need to access a network behind the client you have to tell the server how to reach this network.

              From the point of a client all is clear. He connects to the server, gets the server IP pushed for the gateway and the networks which he should route to the server.
              But since multiple clients connect to the single server, you have to tell the server behind which specific clients IP he can reach a specific network. This can be done by CSO on the server.

              However, I like more to separate access servers from site-to-site connection and set up multiple servers for this purpose.
              When you set up a site-to-site server, you choose a /30 tunnel subnet and enter the networks behind client into the "Remote Networks" field to let the server know the proper route.

              When you want to use the access server for a site-to-site connection as well, you want to set up a "Multi-Purpose OpenVPN server" and add a CSO for the client(s) you want to reach the network behind.

              W 1 Reply Last reply Reply Quote 0
              • W
                wmcneil @viragomann
                last edited by

                @viragomann
                Thank you for the additional information. I have been doing some reading, and getting more educated. For my OpenVPN access server, I added a CSO. For the CSO, I specified a CN as shown in the common name field under status / OpenVPN (there is currently only one OpenVPN client connected), and specified the Remote Network of the client. Despite this, I am still unable to ping or access client side local IPs from the server side. (I did restart the OpenVPN server after I made the changes.) I don't know how to debug this further. Here are some screen shots from the server:

                Status/OpenVPN

                8f6be74d-3e4e-40b5-9797-114d725eccba-image.png

                VPN / OpenPVN / Client Specific Overrides
                2d457929-6bd7-4f40-8455-d1024337f75d-image.png

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

                  @wmcneil
                  Your virtual IP seems very common. Did you even specify any in the CSO? Also possibly that the CSO isn't applied due to not matching common name.
                  In the OpenVPN server advanced settings you can specify if the CSOs should match to the certificates common names or the user names.

                  In the CSO you should specify a very high IP from the tunnel pool to have it unique, cause since there are multiple clients connecting, the server begins the IP assignment from the lowest upwards.
                  Accordingly to the server topology either state a /30 tunnel mask in the CSO if the server uses net30 or a single IP with equal mask as in server settings if the server uses sebnet.

                  If still no joy, enable logging in the vpn server settings, connect and post the log.
                  The log should show if the CSO is properly applied and if the server adds the correct route to the clients network.

                  W 1 Reply Last reply Reply Quote 0
                  • W
                    wmcneil @viragomann
                    last edited by

                    @viragomann said in pfSense OpenVPN client/server (site to site):

                    @wmcneil
                    Your virtual IP seems very common. Did you even specify any in the CSO? "

                    I'm assuming you mean to specify it in the CSO Tunnel Settings / Tunnel network field? If so, I had left that field blank originally, but I did subsequently try filling it in as described further below.

                    Also possibly that the CSO isn't applied due to not >matching common name.
                    In the OpenVPN server advanced settings you can specify if the CSOs should match to the certificates common names or the user names.

                    I do have the server setting configured to match on username, and I do see that the user is authenticated in the openvpn log.

                    In the CSO you should specify a very high IP from the tunnel pool to have it unique, cause since there are multiple clients connecting, the server begins the IP assignment from the lowest upwards.

                    I think I understand your point, but I am currently testing with only a single client connected.

                    Accordingly to the server topology either state a /30 tunnel mask in the CSO if the server uses net30 or a single IP with equal mask as in server settings if the server uses sebnet.

                    The server is set to a subnet topology for the tunnel, and tunnel network setting 10.55.201.0/24 .

                    If still no joy, enable logging in the vpn server settings, connect and post the log.
                    The log should show if the CSO is properly applied and if the server adds the correct route to the clients network.

                    I tried adding a IPV4 Tunnel Network setting of 10.55.201.2/24 to the CSO. From the server OpenVPN log:

                    Jan 23 10:23:13 openvpn 1177 SENT CONTROL [wmcneil]: 'PUSH_REPLY,route 10.55.83.0 255.255.255.0,dhcp-option DNS 10.55.83.10,route-gateway 10.55.201.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.55.201.2 255.255.255.0,peer-id 1' (status=1)
                    Jan 23 10:23:13 openvpn 1177 wmcneil/8.40.57.29:41761 UDPv4 WRITE [257] to [AF_INET]8.40.57.29:41761: P_CONTROL_V1 kid=0 pid=[ #9 ] [] pid=6 DATA len=203
                    Jan 23 10:23:13 openvpn 1177 wmcneil/8.40.57.29:41761 UDPv4 READ [62] from [AF_INET]8.40.57.29:41761: P_ACK_V1 kid=0 pid=[ #11 ] [ 6 ]
                    Jan 23 10:23:13 openvpn 1177 wmcneil/8.40.57.29:41761 UDPv4 READ [164] from [AF_INET]8.40.57.29:41761: P_DATA_V2 kid=0 DATA len=163
                    Jan 23 10:23:13 openvpn 1177 wmcneil/8.40.57.29:41761 MULTI: bad source address from client [::], packet dropped

                    The last entry in the log (bad source address from client) does not look good....I remain unable to access client side local IPs from the server side with this configuration.

                    If I remove the Tunnel Network setting of 10.55.201.2/24 from the CSO (leave field blank), I no longer get the bad source address in the log, however I am still unable to access to client side local IPs from the server side. Here are some log entries from this configuration:

                    Jan 23 10:34:16 openvpn 75989 wmcneil/8.40.57.29:39446 SENT CONTROL [wmcneil]: 'PUSH_REPLY,route 10.55.83.0 255.255.255.0,dhcp-option DNS 10.55.83.10,route-gateway 10.55.201.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.55.201.2 255.255.255.0,peer-id 0' (status=1)
                    Jan 23 10:34:16 openvpn 75989 wmcneil/8.40.57.29:39446 UDPv4 WRITE [257] to [AF_INET]8.40.57.29:39446: P_CONTROL_V1 kid=0 pid=[ #9 ] [] pid=6 DATA len=203
                    Jan 23 10:34:16 openvpn 75989 wmcneil/8.40.57.29:39446 UDPv4 READ [62] from [AF_INET]8.40.57.29:39446: P_ACK_V1 kid=0 pid=[ #11 ] [ 6 ]
                    Jan 23 10:34:17 openvpn 75989 MANAGEMENT: Client connected from /var/etc/openvpn/server1/sock
                    Jan 23 10:34:17 openvpn 75989 MANAGEMENT: CMD 'status 2'

                    Note that the SENT CONTROL command in this latter case is exactly the same as the one in the former, with the one exception being that the latter case contains peer-id 0, and the former contains peer-id 1

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

                      @wmcneil
                      Again, state a high IP out of the tunnel pool at CSO tunnel.

                      In the OpenVPN server settings set the verbosity level to 3.
                      Connect from the client, then take the log section from establishing the client connection.

                      W 1 Reply Last reply Reply Quote 0
                      • W
                        wmcneil @viragomann
                        last edited by

                        @viragomann
                        As requested I changed the CSO tunnel network setting to a high IP out of the tunnel pool: 10.55.201.250/24
                        I am still unable to ping 192.168.2.1 from the server side.
                        Here are the screen shots and the log entries:

                        VPN / OpenVPN / Client Specific Overrides :
                        1d7cccd0-d9b4-41e3-854c-ead1efa905c4-image.png
                        2d2319e0-d087-4e80-a817-369894c56a3c-image.png
                        Status / OpenVPN :
                        1cc42eae-a7c9-47b1-a9ce-08a6fe443a7e-image.png

                        OpenVPN log entries:
                        Jan 23 14:09:02 openvpn 66005 8.40.57.29:1192 TLS: Username/Password authentication deferred for username 'wmcneil' [CN SET]
                        Jan 23 14:09:02 openvpn 66005 8.40.57.29:1192 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
                        Jan 23 14:09:02 openvpn 66005 8.40.57.29:1192 [wmcneil] Peer Connection Initiated with [AF_INET]8.40.57.29:1192
                        Jan 23 14:09:02 openvpn 34416 user 'wmcneil' authenticated
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 MULTI_sva: pool returned IPv4=10.55.201.2, IPv6=(Not enabled)
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn/server1/csc/wmcneil
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_3e9835fc77335d9d220dffa1d79ea122.tmp
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 MULTI: Learn: 10.55.201.250 -> wmcneil/8.40.57.29:1192
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 MULTI: primary virtual IP for wmcneil/8.40.57.29:1192: 10.55.201.250
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 MULTI: internal route 192.168.2.0/24 -> wmcneil/8.40.57.29:1192
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 MULTI: Learn: 192.168.2.0/24 -> wmcneil/8.40.57.29:1192
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
                        Jan 23 14:09:02 openvpn 66005 wmcneil/8.40.57.29:1192 SENT CONTROL [wmcneil]: 'PUSH_REPLY,route 10.55.83.0 255.255.255.0,dhcp-option DNS 10.55.83.10,route-gateway 10.55.201.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.55.201.250 255.255.255.0,peer-id 0' (status=1)
                        Jan 23 14:09:08 openvpn 66005 MANAGEMENT: Client connected from /var/etc/openvpn/server1/sock
                        Jan 23 14:09:08 openvpn 66005 MANAGEMENT: CMD 'status 2'
                        Jan 23 14:09:08 openvpn 66005 MANAGEMENT: CMD 'quit'
                        Jan 23 14:09:08 openvpn 66005 MANAGEMENT: Client disconnected

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

                          @wmcneil
                          Well, so now the CSO is applied and the route is added.

                          Check in pfSense routing table if you can see the route for 192.168.2.0/24 there as well.

                          If so, you may have to ensure that the remote devices are permitting the access.
                          On the client pfSense you also need a firewall on the VPN interface to allow access.

                          W 1 Reply Last reply Reply Quote 0
                          • W
                            wmcneil @viragomann
                            last edited by

                            @viragomann
                            The server routing table was missing the route for 192.168.2.0/24 . I added it in the OpenVPN server Custom Options box:
                            route 192.168.2.0 255.255.255.0

                            The server side is now able to access client-side local IPs. Thanks for your help!

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post