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

Private Network With No Router

Scheduled Pinned Locked Moved NAT
4 Posts 2 Posters 926 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.
  • C
    CrtxReavr
    last edited by Jun 25, 2014, 3:58 PM

    I've been attempting to implement something with pfSense that I thought would be a simple use of some 1:1 NAT, but after much experimentation, I'm not getting anywhere and I'm starting to question if it's even possible.

    I've included what I hope will be a useful visual aid (You may need to scroll left & right to see it all.):

    What I'm hoping to configure is a setup where hosts on the left can access the host on the right, via a VIP on the 'WAN' interface of the pfSense box.  The monkey wrench in the works here is that the 192.168.4.0/24 subnet on the right has no route off of it.  The hosts that sit there have no router configured, nor can I configure one.  (They're part of a rack of equipment that's sold as a "product" and we can't modify their config.)

    My thought was if packets from the left side of the diagram could be "re-written" so that they hit the 192.168.4.80 node on the right with the pfSense machine's 'LAN' IP of 192.1.68.4.254 as the source IP.  Then the 192.168.4.80 node would respond with the 192.1.68.4.254 IP as the destination IP, and then the pfSense machine would re-write the packets so they would route back to the originating host on the left side of the diagram, all providing transparent access to the 192.1.68.4.80 node.

    Is this possible?  Is pfSense the right tool?

    Thanks in advance for your consideration of my crazy ideas.

    -CR

    1 Reply Last reply Reply Quote 0
    • P
      podilarius
      last edited by Jun 25, 2014, 7:14 PM

      This is certainly doable with pfsense. I have done the same thing in my lab for some speed testing. I think you will need to setup manual outbound NAT since NAT is usually only completed on the WAN interface by default. Basically you would need to access 172.17.1.175, that 1:1 NAT will change the destination, but not the source to 192.168.4.80. The host on the right would still get the remote IP of the machine that is communicating to it. So you are going to have to switch to manual outbound NAT and add a LAN entry to change anything going to 192.168.4.80 to the LAN IP or a VIP on the LAN side of pfsense.
      This way the machine talks to the VIP or LAN IP of pfsense.
      Normal 1:1 would probably work if you swapped LAN and WAN on pfSense such that all that on the left is LAN and everything on the right is WAN. Then you just have to make sure that your main router (if not pfsense) routes data destined for 192.168.4.80 to the LAN ip of pfSense. After that 1:1 NAT works with no further changes.

      1 Reply Last reply Reply Quote 0
      • C
        CrtxReavr
        last edited by Jun 25, 2014, 8:07 PM

        Could you elaborate more on this part?:

        "add a LAN entry to change anything going to 192.168.4.80 to the LAN IP or a VIP on the LAN side of pfsense."

        -CR

        1 Reply Last reply Reply Quote 0
        • P
          podilarius
          last edited by Jun 26, 2014, 2:06 PM

          If you enable manual outbound NAT, you can specify a rule on the LAN interface that changes anything destined to 192.168.4.80 to use the LAN interface address or a VIP. Just like creating a manual WAN rule. I really think the other way would be less "complicated". It up to you.

          1 Reply Last reply Reply Quote 0
          1 out of 4
          • First post
            1/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received