0

I need help writing NAT rule for this use case: I want to be able to connect to an local IP as though it's the remote server IP. e.g. port forwarding.

I don't have access to the firewall on the remote network and the server is on the other side of that. See map

enter image description here

So ideally if a client on 10.99.0.0/24 accesses say 10.100.0.129 it would translate to 192.168.50.129 and back again. 192.168.50.129 doesn't access the clients directly. VPN tunnel is up and functioning.

I've tried (with subnet and host objects but I didn't want to jumble this example up with a bunch of unnecessary lines)

nat (inside,outside) source static 10.99.0.0/24 10.100.0.129 destination static 192.168.50.129 192.168.50.129

but that was a no go.

On the vendor firewall the rule would likely be (whatever the Palo Alto version of this is):

nat (inside,outside) source static 192.168.50.128/25 192.168.50.128/25 destination static 10.100.0.0/24 10.100.0.0/24

What am I doing wrong?

---- EDIT ----

Figured it out.

  1. Added the server IP (192.168.50.129) to the interesting traffic for Spoke A <-> Hub tunnel.

  2. Added this NAT rule to my hub:

object network LocalServerIP
host 10.100.0.129
object network RemoteServerIP
host 192.168.50.129
nat (outside,outside) source dynamic any LocalServerIP destination static RemoteServerIP RemoteServerIP
  • Traffic destined from your local network to your local network will not travel to your firewall in order to be translated. Traffic from a host on the 10.100.0.0/24 network to 10.100.0.129 would be sent directly from the source host to the destination host on the same network. Unless the destination address exists on the same network, the attempt will fail. – Ron Maupin Sep 4 at 2:19
  • Sorry, that's my bad for trying to simplify the problem too much. I figured I'd get the quickest answer if I simplified it. See edited post for more accurate problem. – user70726 Sep 4 at 4:25
  • 2
    Are you using VPN links? You should. If you do, no NAT is required at all. – Zac67 Sep 4 at 16:55
  • Yes but the links per the diagram are only to HQ, so I needed to NAT spoke-spoke. I've actually figured out and will update my post with my solution. – user70726 Sep 5 at 0:35
  • 1
    "so I needed to NAT spoke-spoke" No, no, no. You never NAT unless you are translating private to public addressing, or you have overlapping network addressing. If you have overlapping network addressing, you use outside-source NAT as a temporary solution until you fix the addressing, but NAT is to be avoided. – Ron Maupin Sep 5 at 2:45
1

Generally, you only use NAT when it's required:

  1. source NAT, translating from private to public addressing, e.g. Internet access
  2. destination NAT, translating from public to private addressing, aka. reverse NAT, port forwarding, virtual IP
  3. both source and destination NAT, translating from private to private addressing to disambiguate overlapping address spaces (which should be repaired = renumbered, and not worked around with NAT)

NAT breaks TCP/IP's end-to-end paradigm and it's an ugly hack that should be avoided wherever possible.

In your case, NATing over VPN with continuous private addressing is redundant and even disruptive - servers accessed across locations cannot distinguish remote clients, breaking subnet zoning and useful logging. Furthermore, there's nothing gained by using NAT, only damage.

| improve this answer | |
  • Ok what's the syntax? – user70726 Sep 6 at 3:08
  • You don't need any syntax to not use NAT. Just make sure the routes point into the VPN tunnel, either statically or by setting up OSPF. – Zac67 Sep 6 at 7:23
0

Figured it out.

  1. Added the server IP (192.168.50.129) to the interesting traffic for Spoke A <-> Hub tunnel.

  2. Added this NAT rule to my hub:

object network LocalServerIP
host 10.100.0.129
object network RemoteServerIP
host 192.168.50.129
nat (outside,outside) source dynamic any LocalServerIP destination static RemoteServerIP RemoteServerIP
| improve this answer | |
  • 1
    This is really bad. With non-overlapping addressing and VPNs, you should use simple routing. NAT is not a substitute for routing. NAT is really just something to keep IPv4 around long enough for IPv6 to become ubiquitous. Your solution will not work with IPv6, which does not have NAT because it has enough unique addresses, which you apparently have, so NAT is unnecessary and undesirable. You jumped through a bunch of hoops for no reason because you could have simply let routing take care of it. – Ron Maupin Sep 5 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy