Palo Alto Inbound NAT Architecture and Network Objects

This study guide details the architectural setup and policy configuration for deploying a Palo Alto Networks VM-Series Next-Generation Firewall (NGFW) in Amazon Web Services (AWS). It focuses on inbound Destination Network Address Translation (DNAT / Port Forwarding), interface and zone segregation, AWS-specific routing nuances, network object modularization, and the foundational packet-processing evaluation order between NAT rules and security policies.

1. Architectural Overview & Inbound Access Strategy

When deploying multi-VPC topologies in cloud environments such as AWS, exposing backend workloads (like an internal Amazon Linux EC2 instance hosting OWASP Juice Shop) directly to the public internet introduces severe security risks. Rather than attaching Elastic IP (EIP) addresses directly to workload instances or relying solely on client-side VPNs (such as GlobalProtect) for administrative access, enterprise architectures utilize centralized inbound NAT on a dedicated firewall cluster.

Key Architectural Objectives

• Centralized Ingress Inspection: Inspect and filter all inbound administrative and application traffic through a single security perimeter.
• Port Multiplexing / Port Forwarding: Leverage a single external public IP address to expose multiple internal services across distinct non-standard ports (e.g., forwarding external port 2222 to internal SSH port 22, and external port 8888 to web application ports).
• Outbound Egress Enablement: Provide outbound Source NAT (SNAT / PAT) so backend instances can pull container images from Docker Hub and install system dependencies via package managers (yum/dnf).

2. Interface Configuration & Security Zone Design

The VM-Series firewall requires distinct interfaces attached to separate AWS Elastic Network Interfaces (ENIs) residing in distinct subnets.

Interface Configuration Details

1. Internal Interface (ethernet1/1):

   • Type: Layer 3
   • Virtual Router: default
   • Security Zone: private (or trust)
   • IPv4 Configuration: DHCP Client
   • Automatically Create Default Route: Unchecked. Internal interfaces must not overwrite the firewall's default gateway.
   • Management Profile: A custom interface management profile named ethernet1/1 with ICMP/Ping enabled for hop-by-hop reachability verification.

2. External Interface (ethernet1/2):

   • Type: Layer 3
   • Virtual Router: default
   • Security Zone: public (or untrust)
   • IPv4 Configuration: DHCP Client
   • Automatically Create Default Route: Checked. This allows the external interface to automatically learn its default gateway (pointing out the AWS subnet router toward the Internet Gateway).

Note on Cloud DHCP Addressing: In AWS VPC subnets, the .1 address of a standard CIDR block is not used for the gateway. AWS reserves the first four IP addresses and the last IP address of every subnet. For instance, in a subnet starting at 10.0.0.16/28, the default gateway assigned by AWS DHCP is .17. Leaving interfaces set to DHCP allows PAN-OS to dynamically resolve the exact gateway IP without manual schema calculation errors.

3. Virtual Router & AWS Routing Integration

The firewall relies on its Virtual Router (VR) table to maintain clean separation between inbound return paths and outbound internet transit paths.

Routing Logic

• Default Egress (0.0.0.0/0): Points directly out the public interface (ethernet1/2) toward the AWS Internet Gateway.
• Internal Supernetting (10.0.0.0/22): Instead of declaring dozens of individual /24 subnet routes, a single aggregated /22 supernet route encompasses 10.0.0.0/24, 10.0.10.0/24, 10.0.20.0/24, and 10.0.30.0/24. All internal-bound traffic is forwarded out ethernet1/1 to the internal AWS router (.17).

Routing verification can be confirmed directly within the PAN-OS management interface by inspecting the Routing Information Base (RIB) under the Route Table and the Forwarding Information Base (FIB) under the Forwarding Table.

4. Network Objects & Address Group Structuring

To avoid hardcoded IP sprawl within firewall policies, all endpoints and subnets are defined as modular objects.

Object Definition Hierarchy

• Individual Workload Objects: Defined for specific backend servers (e.g., obj-ec2-juiceshop with IP 10.0.x.150).
• Subnet Objects: Defined for each individual VPC or segment (/24 CIDRs).
• Address Groups: Static address groups collect multiple subnet objects under a single identifier, streamlining outbound NAT and inter-VPC security inspection rules.

5. Custom Service Objects for Port Redirection

When conducting Port Address Translation (PAT) on inbound flows, standard predefined services like service-ssh (which defaults strictly to TCP port 22) are insufficient for original-packet matching.

By defining a dedicated service object with a destination port of 2222, the firewall can intercept SSH traffic targeted at the custom port and translate it to the standard listening port 22 on the internal server.

6. Packet Flow & Evaluation Order: NAT vs. Security Policies

A fundamental operational concept within PAN-OS is that NAT policy evaluation occurs before Security Policy evaluation, but enforcement happens in a coordinated sequence.

Critical PAN-OS Rule Matrix:

• In the NAT Policy, the destination zone is the zone where the destination IP currently belongs before translation (often public to public).
• In the Security Policy, the destination zone is the post-NAT zone (where the packet will exit, i.e., private), but the destination IP address remains the pre-NAT IP (the external address the client originally connected to).

7. The AWS Elastic IP (EIP) vs. Private IP Nuance

In on-premises networks, a firewall external interface often directly owns a public routable IP. However, in AWS, Elastic IPs do not exist inside the operating system of the EC2 instance or PAN-OS firewall.

The 1:1 NAT Cloud Abstraction

1. AWS handles 1:1 NAT at the Internet Gateway boundary.
2. The public Elastic IP is mapped seamlessly to the private IP assigned to the firewall's external Elastic Network Interface (eth1/2, e.g., 10.0.0.40).
3. When external clients send packets to the Public EIP, the AWS IGW translates the destination IP to the ENI's private IP (10.0.0.40) before the packet ever hits PAN-OS.

Operational Impact on NAT Rules

When configuring an Inbound DNAT rule in PAN-OS on AWS, never configure the public Elastic IP as the Original Destination Address. The rule will fail to match because the firewall only sees its assigned private IP (10.0.0.40) in the packet header.

8. Inbound Destination NAT (DNAT) Policy Configuration

To allow external administrative access to the internal Juice Shop EC2 instance, an inbound DNAT rule is established.

Port Translation Scalability

This model allows massive scalability on a single external IP:

• External Port 2222 $\rightarrow$ Server 1 Port 22
• External Port 2223 $\rightarrow$ Server 2 Port 22
• External Port 8888 $\rightarrow$ Juice Shop Web Application Port 3000

9. Outbound Source NAT (SNAT / PAT) Configuration

Backend workloads require outbound connectivity to update system packages and fetch container images from registries.

10. Inbound Security Policy Configuration

Because the NAT policy only rewrites packet headers and does not authorize traffic, an explicit Security Policy rule must permit the flow.

11. Tabular Summary of Network Objects, NAT, and Security Rules

Object Definitions

Policy Mappings

Summary and Key Takeaways

• Cloud IP Translation Boundary: In AWS, public Elastic IPs are translated at the Internet Gateway. The PAN-OS external interface only sees its local private subnet IP (e.g., 10.0.0.40). All incoming NAT rules must use this internal private IP as the original destination address.
• NAT Before Security Evaluation: PAN-OS processes NAT rules first to determine the post-NAT destination zone and IP, but enforces security policy rules using the post-NAT destination zone combined with the pre-NAT destination IP address.
• Interface Route Management: When using DHCP on PAN-OS cloud interfaces, enable default route creation only on the public WAN interface (eth1/2). Disable it on internal LAN interfaces (eth1/1) to prevent overwriting the system default gateway.
• Efficient Route Supernetting: Use aggregated CIDR blocks (e.g., 10.0.0.0/22) within the Virtual Router to direct all inter-VPC spoke traffic out internal interfaces rather than managing numerous specific static routes.
• Object-Driven Architecture: Avoid hardcoding raw IP addresses and ports inside policies. Use address objects, static address groups, and custom service objects to maintain modularity and simplify future topology changes.
• Port Forwarding (Inbound PAT): Multiple internal workloads running on standard ports (such as SSH on port 22 or HTTP on port 80) can be securely published through a single external IP by mapping distinct external destination ports (e.g., 2222, 2223, 8888) to backend private IPs and standard destination ports.