Inter VSYS NAT and How to Hide Subnets

[reaper]

You may need to split segments of your network into different VSYS but still be able to have segments communicate with each other but requiring NAT to hide the original IP subnets. Here's a quick how to review:

In this example, I'll show how Red1 in vsys2 needs to connect to Blue1 in vsys. Red1 will be connecting to NAT address 172.10.0.1 which is translated to the physical IP of Blue1 (192.168.0.21), while Blue1 will receive packets from NAT address 172.0.0.29.

Each vsys has it's own router with routes set for the next VR (more on that in a moment), visibility for the vsys has been enabled, 'external' zones have been created and security policy set so traffic is permitted: for more on how to set up basic inter-vsys routing, please check out this article: Tips & Tricks: Inter VSYS routing (please read this article first as it explains the basic steps to enable what we will need prior to configuring NAT)

For basic routing you should already have a route back and forth for the connected networks, but an additional route for the NAT ip subnets will need to be added, this is because the VirtualRouter in each vsys will need to be able to resolve pre- and post-NAT IP addresses to determine egress zone

So VR1 will have a route for the physical subnet on VSYS2, and one for the NAT source we're using to hide incoming sessions.

VR2 will have an entry for the physical subnet on VSYS1, and a route for the NAT destination IP Red1 is using to connect to.

Still with me?

So, Red1 is going to send out a packet to 172.0.0.1. The firewall (VSYS2) will need to determine what to do with this packet, so it does a route lookup and sees it is destined for the 'external' zone going out to VSYS1. A NAT policy will be matched (trust to external) and NAT policy will be applied where the destination is translated to the physical IP of Blue1, a new route lookup is done to verify where the packet needs to be sent and the second route is hit. The packet is forwarded then forwarded to the 'external' zone.

On VSYS1, the packet is received and a routelookup determines its sourced from the 'external' zone destined to the trust zone, a NAT policy is applied where the source address is rewritten to 172.10.0.0/24 (last octed will be matched to the original source, so in this case the packets' source will be changed to 172.10.0.29, and the packet is forwarded to Blue1.

Blue1's reply packet will be destined for 172.10.0.29, so VSYS1 does a route lookup on VR1 and finds the packet needs to go. The external Zone, a matching session will be found and reverse NAT policy will be applied, after which another route lookup will determine the packet is in fact destined for 192.200.0.29, located in the 'external' zone. The packet is forwarded to VSYS2 where it is received, found to be destined for the trusted zone, and matching an existing NAT session where the source is changed from 192.168.0.21 to 172.0.0.1, and the packet is forwarded on to Red1.

As you can see in the packetcaptures, neither side can see: 

A secondary scenario would be when there is one Virtual Router for the entire system (not bound to a specific VSYS), in which case, only source NAT can be performed as a reverse route lookup, for the reply packet will not find a route in the routing table.

I hope this was useful! Feel free to leave a comment below.

Reaper out!