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

    multiple client sites: which architecture to choose

    Scheduled Pinned Locked Moved OpenVPN
    45 Posts 4 Posters 6.7k 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.
    • S
      sgw @viragomann
      last edited by

      @viragomann thanks for the detailed "draft" ... I have to read through it multiple times and try to understand all the parts of it.
      This is still meant to be realized with OpenVPN, right?

      I wonder about the part with the printer etc ...

      Basically I need a kind of site-to-site behavior:

      site1 (servers): contains the VM(s) with the RDP-server(s) .. plus admin-PCs in the office LAN segment

      site2 (shop number X): contains the shop PC plus maybe the card terminal and a network printer

      site2 should be allowed to only access one specific terminal server

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

        @sgw said in multiple client sites: which architecture to choose:

        This is still meant to be realized with OpenVPN, right?

        Yes, and you would need to state remote networks in the CSO. However, a CSO for each client is necessary anyway, since you need to assign specific VPN IPs to the client to access them.

        I wonder about the part with the printer etc ...

        That's just port forwarding. I have to find out, which port you need to forward though.

        Basically I need a kind of site-to-site behavior:

        Normally you realize a site-to-site with proper routing, not NAT. NAT has drawbacks, especially masquerading (S-NAT), so that you only see the routers IP on the destination device, not the real clients source IP.
        But I think, for these purposes that doesn't matter. On the server you only need to know, which client is connecting, and this is given by the VPN IP. On the client site, for access from the server site the real source should not be relevant.

        site1 (servers): contains the VM(s) with the RDP-server(s) .. plus admin-PCs in the office LAN segment

        site2 (shop number X): contains the shop PC plus maybe the card terminal and a network printer

        In the OpenVPN server settings or even in the CSO, you have to state the server sites local networks, so the servers LAN + the office LAN, to push these routes to the client, since this is not natted at the clients.

        site2 should be allowed to only access one specific terminal server

        Allowing access is done by firewall rules. It depends on your needs if this can be done with a single rule for the whole tunnel subnet on the servers VPN interface or if you need to give a specific client only access to a certain server.

        S 1 Reply Last reply Reply Quote 0
        • S
          sgw @viragomann
          last edited by

          Talked to their internet provider today, I think things get a bit easier:

          I'll be able to set up my pfSense IN PARALLEL to the existing Barracuda appliances. So I will get static IP(s) on WAN and establish an additional gateway in both the server- and the office-LAN.

          I assume that reduces the complexity ...

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

            @sgw
            Easier? Sure?

            As I understood, pfSense should get an interface in both server and office LAN. And how do you think, access to the printer is properly routed?

            Yes, this would work if you add a static route to each device, which you want to access the remote site. This is an option for a handful devices. But otherwise I think, this is much more effort than spawning up a transit network.
            However, if the devices networks are configured via DHCP you could distribute the route by the Server in case, this is supported, of course.

            Getting a WAN IP on the VPN gateway doesn't make things better at all for your purpose. It needs pretty the same effort as if you connect pfSense to the LAN as a "router on a stick".

            S 1 Reply Last reply Reply Quote 0
            • S
              sgw @viragomann
              last edited by

              @viragomann said in multiple client sites: which architecture to choose:

              @sgw
              Easier? Sure?

              hm, I hope so.
              I think I should somehow come up with a drawing or diagram here. Just to show things better.

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

                @sgw
                For sure this would help to evaluate the set up.

                S 1 Reply Last reply Reply Quote 0
                • S
                  sgw @viragomann
                  last edited by

                  Yes. I will try to draw some diagram by hand ... not wasting too much time with some software I can't handle ;-)

                  S 1 Reply Last reply Reply Quote 0
                  • S
                    sgw @sgw
                    last edited by sgw

                    Did a quick drawing, forgive the quality.

                    IMG_20231113_133357.jpg

                    In black the current situation as far as I know.

                    I assume they have some routes in place between LANs "office" and servers, maybe on the barracudas, maybe at provider level.

                    I will have a phone call with the provider admin for details tomorrow, and be on-site on wednesday, to check details.

                    In green my suggested placement of the pfSense as a VPN-gateway:
                    I assume I could get one or more static official IP-adresses to use as WAN-IPs.

                    The servers and/or VMs would need a route: reach all VPN-subnets by using the pfSense as gateway.

                    The "shops" (=external VPN-clients) would connect to WANIP_pfs2 (I forgot to draw pfsense1 in the office, sorry).

                    Isn't that working?

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

                      @sgw
                      So I understood it correctly.

                      Isn't that working?

                      As mentioned, you would need static routes pointing to pfSense for the client sides subnet on all devices, which need to communicate. On the server side this might only be the server and the router (assuming that the router connects to the office network, so that the employees in the office can also access the client side devices).

                      I forgot to draw pfsense1 in the office, sorry

                      As I understood, it is connected to the router and has its own LAN behind.

                      S 1 Reply Last reply Reply Quote 0
                      • S
                        sgw @viragomann
                        last edited by

                        @viragomann

                        they access their server-VMs already, but maybe unprotected: no VPN, no TLS, that's the status quo.

                        So pfsense1 might be a first VPN-client to establish a protected connection between office and servers.

                        And it's a demo-appliance for a first shop.

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

                          @sgw said in multiple client sites: which architecture to choose:

                          they access their server-VMs already

                          I was talking about accessing the clients LAN. I understood, that this is required for troubleshooting.

                          S 1 Reply Last reply Reply Quote 0
                          • S
                            sgw @viragomann
                            last edited by

                            @viragomann said in multiple client sites: which architecture to choose:

                            @sgw said in multiple client sites: which architecture to choose:

                            they access their server-VMs already

                            I was talking about accessing the clients LAN. I understood, that this is required for troubleshooting.

                            Ah, yes.

                            I should add the shops/clients to the drawing, sure.

                            That's what this is all is about in the end: enabling the shops to access the servers over secure channels.

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

                              @sgw
                              No, I was meaning this:

                              Main site: actually it consists of 2 segments:
                              An office with a firewall/router and a server site with a fw/router.

                              S 1 Reply Last reply Reply Quote 1
                              • S
                                sgw @viragomann
                                last edited by

                                I now have done first steps there:

                                as projected I was able to set up a pfSense as a parallel router/firewall:

                                I have a static WAN-IP with routed internet, and LAN has an IP in their server-LAN.

                                By adding a static route to the pfSense I can reach it from the office-LAN.

                                Set up an OpenVPN-server, plus some users, we chose a Test-VM in the server-LAN, added a route ("reach openvpn-subnets via the LAN-IP of pfSense") and I can successfully access that VM via OpenVPN, tested from a Windows 11 laptop from outside, and my linux laptop.

                                I then set up a SG1100, imported the VPN-client-config and established the tunnel. OK.

                                But here I get stuck: per default WAN gets its IP via DHCP. In my "shop scenario" I want to plug the SG1100-WAN-interface into their LAN-switch ... and connect the shop-PC to the SG1100-LAN-interface.

                                That means WAN gets an RFC1918-IP .. which isn't good ... as the default IPv4 deny rules match etc etc

                                Basically I don't need (??) NAT on such a box, I only want a gateway into the established VPN-tunnel. Should/could I disable NAT on the "vpn-client appliance"?

                                Maybe I am just too tired today ... and I overlook the obvious. Thanks for every help here.

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

                                  @sgw said in multiple client sites: which architecture to choose:

                                  But here I get stuck: per default WAN gets its IP via DHCP. In my "shop scenario" I want to plug the SG1100-WAN-interface into their LAN-switch ... and connect the shop-PC to the SG1100-LAN-interface.

                                  That means WAN gets an RFC1918-IP .. which isn't good ... as the default IPv4 deny rules match etc etc

                                  Why not?
                                  There is not any incoming access desired on WAN, as I understood your requirements.
                                  And if it ever was for any reason you could disable RFC1918 blocking.

                                  Basically I don't need (??) NAT on such a box, I only want a gateway into the established VPN-tunnel. Should/could I disable NAT on the "vpn-client appliance"?

                                  As mentioned, it would make things much more complicated.
                                  You would need different client sides LAN subnets for each and the proper routes on the OpenVPN server.
                                  I'm preaching this since my very first post here. So if you want routes, just do it and have fun.

                                  S 1 Reply Last reply Reply Quote 0
                                  • S
                                    sgw @viragomann
                                    last edited by

                                    @viragomann said in multiple client sites: which architecture to choose:

                                    @sgw said in multiple client sites: which architecture to choose:

                                    But here I get stuck: per default WAN gets its IP via DHCP. In my "shop scenario" I want to plug the SG1100-WAN-interface into their LAN-switch ... and connect the shop-PC to the SG1100-LAN-interface.

                                    That means WAN gets an RFC1918-IP .. which isn't good ... as the default IPv4 deny rules match etc etc

                                    Why not?
                                    There is not any incoming access desired on WAN, as I understood your requirements.
                                    And if it ever was for any reason you could disable RFC1918 blocking.

                                    OK, I see. My first tests were done from inside their office-LAN today, that wasn't the best setup. I will test with the SG1100 tmrw, from my LAN.

                                    I'm preaching this since my very first post here. So if you want routes, just do it and have fun.

                                    ok ok ;-) it seems I haven't fully understood yet. I test things tomorrow and maybe things get clearer then anyway. Thanks so far @viragomann

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

                                      @sgw said in multiple client sites: which architecture to choose:

                                      My first tests were done from inside their office-LAN today, that wasn't the best setup.

                                      Not clear, what you're calling office-LAN here. I was thinking about the main office network, but maybe you mean the clients LAN.

                                      As I explained, for accessing devices in the clients network (which might only be one according to your description), I would forward the traffic on the VPN interface to it. So you would have to call the clients virtual IP to access it.

                                      S 1 Reply Last reply Reply Quote 0
                                      • S
                                        sgw @viragomann
                                        last edited by

                                        @viragomann

                                        I was plugging the future "shop appliance" = SG1100 into their office LAN as I was testing.

                                        I assume there was a route missing on the target VM (the default gateway is still the Barracuda) ... we will fix and check that later today.

                                        With a software client like a Windows-PC with OpenVPN on it the device directly gets an IP in the OpenVPN subnet.

                                        With the SG-1100 as client that isn't true, the PC behind it gets an address in the LAN-subnet of that device: additional layer, additional routes needed.

                                        If it was possible to somehow directly use the OpenVPN subnet for the devices plugged into LAN, that would be great.

                                        Maybe you suggest that, could you explain how to DO that?

                                        thanks! good morning (here)

                                        S 1 Reply Last reply Reply Quote 0
                                        • S
                                          sgw @sgw
                                          last edited by

                                          I currently struggle with how to route the LAN behind the OpenVPN client to the servers behind the OpenVPN server.

                                          The SG1100 is able to ping 192.168.1.75 in the LAN of SG2100 (tested from the GUI).

                                          A client in the LAN of SG1100 (192.168.99.0/24) is NOT able to reach 192.168.1.75.

                                          In the OpenVPN server I have "IPv4 Local network(s): 192.168.1.0/24"

                                          For the user used in the VPN client on SG1100 I configured a CSO containing:

                                          IPv4 Remote Network/s: 192.168.99.0/24

                                          No obvious firewall hits ... what do I miss? thanks for help here.

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

                                            @sgw said in multiple client sites: which architecture to choose:

                                            The SG1100 is able to ping 192.168.1.75 in the LAN of SG2100 (tested from the GUI).

                                            A client in the LAN of SG1100 (192.168.99.0/24) is NOT able to reach 192.168.1.75.

                                            I assume, you're missing the outbound NAT rule on the client, as described above.

                                            For the first testing you can do this also without CSO. This is only needed here to assign a certain IP to the client, which would be relevant later.

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