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

    Client IPs translated to LAN IPs

    OpenVPN
    3
    7
    1.3k
    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.
    • K
      kyerie030
      last edited by

      Hi,

      I currently have a working Pfsense 2.3.2 setup with OpenVPN running.
      My LAN network is under 10.10.0.0/16
      My Pfsense clients is given the IP range 190.160.1.0/24

      My issue is that I want to be able to mask the 190.160.1.0/24 range to lets say 10.10.10.0/24 when connecting to any of my LAN clients so that they can get by strict firewall restrictions that would only allow IPs inside the 10.10.0.0/16 range to access them.

      Is this at all possible?

      1 Reply Last reply Reply Quote 0
      • K
        kpa
        last edited by

        Set up outbound nat on the LAN interface with the OpenVPN client range as the source address range.

        Where did you pick up the 190.160.1.0/24 addresses? That's a public IP range registered in Chile. Use a 192.168.. or some other RFC1918 range for VPN instead.

        1 Reply Last reply Reply Quote 0
        • K
          kyerie030
          last edited by

          Not sure, I'm just picking up from someone else who initially setup the OpenVPN.

          Changed the network to 192.168.250.0/24

          Just to confirm, the Outbound NAT should be like this?

          Interface: LAN
          Protocol: any
          Source: Network, 192.168.250.0/24
          Destination: Any (or should this be set to the local network's ip range?)
          Translation: Interface Address

          Any other LAN rules I need to add further?

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

            The rule is okay. It will translate any client address to the LAN interface address. Not sure if this is what you want to achieve.
            If you want to translate each client to a different address you can use NAT 1:1, which is capable to translate the whole IP range.

            1 Reply Last reply Reply Quote 0
            • K
              kyerie030
              last edited by

              Thanks for the instructions on the Outbound NAT.

              So this means that any client of mine accessing 192.168.250.0/24 will go through the pfsense firewall / openVPN host (assume this is 10.10.0.1) then go to the LAN computer (assume this is 10.10.0.2) then use the same route going back to the OpenVPN client?

              @viragomann:

              If you want to translate each client to a different address you can use NAT 1:1, which is capable to translate the whole IP range.

              What if I would like use NAT 1:1? How would I go about it?

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

                @kyerie030:

                So this means that any client of mine accessing 192.168.250.0/24 will go through the pfsense firewall / openVPN host (assume this is 10.10.0.1) then go to the LAN computer (assume this is 10.10.0.2) then use the same route going back to the OpenVPN client?

                Yes, the client will send the responds to 10.10.0.1 and pfSense translates the destination IP back to the origin clients IP.

                @kyerie030:

                What if I would like use NAT 1:1? How would I go about it?

                No, 1:1 is no option here, that was a blindfold hasty reaction.
                This is also to be done by outbound NAT. Just select "Other subnet" at translation and enter e.g. 10.10.0.0/24 below.

                1 Reply Last reply Reply Quote 0
                • K
                  kyerie030
                  last edited by

                  Thanks so much viragomann for the explanation and kpa for the solution. It works as expected now.  :)

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