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