using NAT to "change subnets"

[mnaylor]

Hello community,

I have what I think is an odd use case for NAT but am curious if it would work.

We are readdressing our campus and have a series of vending devices with no way to change the static IPs. All of those devices need to "move" to another subnet.

All of our on-campus routing takes place within our core switches, with no way to do NAT there. Our PA is simply the GW of last resort out to the Internet.

Would it be possible to route traffic destined for this vending subnet to the PA and use NAT to mask the device IPs?

Let me know if I'm unclear...not quite sure if what I'm trying to describe is possible.

[TomYoung]

Hi @mnaylor ,

Using NAT for duplicate or unroutable subnets is very common.  The classic case is a merger with the same subnet in each company.  If I understand your topology correctly, you would need to bridge or trunk the vending devices VLAN to the PA so that it can access that subnet after it performs the NAT to the real IP.

Thanks,

Tom

[mnaylor]

Thanks @TomYoung ,

I left out a crucial detail. We are readdressing in order to sell a chunk of our IP space. These devices (and the two VMs that access them) are currently in the space that we are selling. Per another situation, they will eventually go away but not for several months.

So, with no way to re-program these devices, I'm looking to trick them into communicating with the VMs (which I'll obviously have to re-address) and to trick the VMs into communicating with them on another network.

The other thing to think about is that we cannot really leave any routes to the networks we are selling in case someone would purchase that space and bring up a service that our users need to access out on the Internet.

Does that make sense?

I would love to do something like this but not sure it quite fits the bill. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGZCA0

[Adrian_Jensen]

As Tom says, you can do a double-NAT on the PA, one-to-one NATing both the source and destination. VLAN the vending devices to the PA as their gateway, then NAT vending address 1.2.3.4 <-> 7.8.9.4 new address. The vending machines will then connect out on their existing address, but the world will see them on the new address.

If  the vending devices are going to connect to VMs internally though... and only need to talk to the VMs, it may be a lot easier to just set an isolated network for them. Create a new route VRF on your core switches, route the vending network to a second network interface on the VMs, and then let the VMs talk to the vending devices. The VMs can talk to the external world thru their primary interface.

[TomYoung]

Hi @mnaylor ,

That solution will not work, because it requires the legacy route in the NGFW routing table.  If you want to forward traffic on the NGFW without a route, then configure PBR.  However, @Adrian_Jensen 's solution looks to be the most straightforward.  Your VMs probably won't access the Internet that much and the directly connected legacy route will probably not break anything.

Thanks,

Tom

[mnaylor]

@Adrian_Jensen

We are running HPE 5406 at the core, which do not support VRF.

[Adrian_Jensen]

I don't know HPEs at all, but this says you implement VRFs as "vpn-instance" on HPE:

https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c03529403

A VRF is Cisco terminology is just a separate L3 routing table shared among specific ports. You can do the same on the PA itself by creating a new routing table and linking interfaces (physical or VLAN) to it:

Network -> Virtual Routers

[TomYoung]

Hi @mnaylor ,

How far are the VMs from the vending devices?  Can they be put on the same VLAN?

Thanks,

Tom

[mnaylor]

They could be put on the same VLAN by changing the addresses of the server, but keep in mind I have no way to program the vending devices. So, as far as the devices are concerned, nothing can "change". They have to talk to the servers via the current server IPs and I have no way to change the device IPs.

[TomYoung]

Hi @mnaylor ,

You could add a secondary NIC to one of the VMs in the vending device subnet.  You can configure that VM to route.  You can add a route on the other VMs to point to the multi-homed VM.  Only a handful of VMs will have the route in your network.

If you don't want to go that route (pun intended), I recommend you keep the vending network connected to your internal network.  From what I understand, it seems unlikely that you will sell the public IP prefix and internal users will need it before you decommission the vending machines.

The PANW definitely can provide a solution via NAT, but adding complexity to the design comes with its own problems.

Thanks,

Tom