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

    multiple client sites: which architecture to choose

    OpenVPN
    4
    45
    4.8k
    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 @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
                            • S
                              sgw @viragomann
                              last edited by sgw

                              @viragomann Yes, the outbound nat rule was missing.
                              Followed that part from your suggestion

                              Now my laptop is able to connect, great!
                              thanks

                              I will try to understand all this and decide if I can use all this in "production" (after some more cleanups etc, sure)

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

                                On my way.

                                So far I have an OpenVPN server running in Mode: "Remote Access ( SSL/TLS + User Auth )".
                                One shop/site ("site01") is connected via Windows OpenVPN client and is successfully accessing a VM in our server net. Nice.

                                Now for the questions:

                                Should we be able to access the LAN of "site01"?

                                I added its subnet to a CSO in the field "IPv4 Remote Network/s".

                                I see a route added in the Routing Table under "Status/OpenVPN".
                                but when I ping an IP in "LAN-site01" it seems that it goes out via the default gateway .. wrong

                                Quick googling seems to say: only "peer to peer" mode allows accessing the LAN behind the openvpn-client. Correct?

                                If yes, why the option to define Remote Networks in the CSO?

                                I will try to set up a 2nd openvpn server with "peer to peer" etc

                                Although that sounds scary: wouldn't that result in one ovpn-server per customer-site??

                                EDIT: why do I need routing to their LAN? The VM/server in the server LAN has to communicate with a card terminal in the client LAN.

                                S V 2 Replies Last reply Reply Quote 0
                                • S
                                  sgw @sgw
                                  last edited by

                                  plan B

                                  • configured the client-appliance to have 2 LAN-ports
                                  • added a portforwarding: from external "tunnel client IP" to "IP of card terminal in LAN behind the vpn client" (with specific ports)
                                  • successfully accessed that card terminal from the server LAN

                                  (for the test I used a webserver in a docker container on a laptop)

                                  So as long as the card terminal has a fixed IP etc this should work.

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

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

                                    One shop/site ("site01") is connected via Windows OpenVPN client and is successfully accessing a VM in our server net. Nice.

                                    Now for the questions:

                                    Should we be able to access the LAN of "site01"?

                                    I added its subnet to a CSO in the field "IPv4 Remote Network/s".

                                    I see a route added in the Routing Table under "Status/OpenVPN".
                                    but when I ping an IP in "LAN-site01" it seems that it goes out via the default gateway .. wrong

                                    Accessing a LAN device behind a connected Windows Desktop??

                                    Windows is not a router OS by default. You can enable routing in fact if you want, but this must be done with admin privileges on the Windows.
                                    And yes, without a masquerading rule on the Windows or a proper route on the destination device, responses will go the to local default gateway and communication will fail.

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

                                      @viragomann ok, I see, you are right.
                                      I added a portforwarding, now they can communicate with the card terminal.

                                      I still wait for their successful tests of all their features, but it looks good for a "version 0.1".

                                      As I research something for another project: would a transparent bridge maybe help here also? I think of removing the double-NAT by doing so ... but its only an idea so far.

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

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

                                        As I research something for another project: would a transparent bridge maybe help here also?

                                        What do you think to bridge? The clients LAN to the servers LAN, I guess.
                                        So you want to bridge about sixty layer 2 network segments? Really?
                                        Apart from the point, that bridged VPNs are rarely supported and the set up could be painful, for what benefit do you want to do this?

                                        I think of removing the double-NAT by doing so

                                        Seems natting the traffic is pretty bothering you. But can you cite any drawback of this? Or is your opinion based on something you heard or read about natting somewhere in the past, where it presumably was used in a total other context?

                                        And in fact, we are not talking about double-NAT here, even if this wouldn't have any impact either.
                                        Each direction would be natted only one time.

                                        Let me recap your options from my point of view:

                                        • Routing:
                                          pros: you can use the real devices IPs for accessing them and see the real IP on the destination device.
                                          cons: elaborate set up. you need a unique clients LAN network for each, so you have to do the whole client setup manually (so 60 times!).

                                        • NAT
                                          pros: easy set up, you have to do the configuration only once on one client device and can copy it (incl. NAT rules) to the others. Also the clients LAN devices get equal IPs. You just need to configure the VPN then on each.
                                          cons: none ( I can't think of any in your setup)

                                        • Bridging:
                                          pros: I don't see any
                                          cons: haevy L2 traffic over the VPNs, rarely supported

                                        You may make a decision.

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

                                          @viragomann thanks for the long reply, I appreciate your help and your patience ;-) (btw. it seems we could "talk" in german as far as I understand ... would have to happen in the "German" section of this Forum, I assume)

                                          No, I don't want to bridge 60 client subnets. I wondered if a bridge would help in the shops where the openvpn client appliances run. Right now in my test shop the specific PCs run behind the SG1100 and are in a separated LAN there.

                                          I should draw a new diagram ...

                                          Right now the customer is testing things and sounds happy so far. I expect him to plug more PCs into that subnet today ... maybe the current setup already is good enough (while not yet perfect maybe).

                                          It's very likely that I mix up concepts. You list NAT and routing as 2 ways of doing that, I maybe still don't fully see the lines between. As far as I understand right now, I currently have NAT and routing in place ...

                                          Let me come up with another diagram, this time maybe more beautiful and with more details. I'd really like to get this as clean as possible before I have to scale it up to N vpn clients.

                                          good morning from my side ...

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