Prisma AIRS: Microperimeter Deployment

The architecture uses a hairpin traffic pattern. All packets undergo inspection before reaching their destination. Redirection operates on both inbound and outbound directions.

Hairpin traffic pattern: GENEVE encapsulation to the AIRS firewall and back.

Four-step flow:

1. Interception — The panredirect agent intercepts inbound and outbound packets on the designated workload interface.
2. Encapsulation — The agent wraps packets in a GENEVE tunnel using UDP 6081. A GENEVE option (0x20) and flow direction flag uniquely identify the traffic.
3. Inspection — The encapsulated traffic arrives at the Prisma AIRS firewall data interface. The firewall decapsulates, performs L7 inspection against security policies, and re-encapsulates the traffic.
4. Delivery — The firewall sends the inspected packet back to the originating host. The agent decapsulates it and forwards it to the Linux kernel protocol stack for delivery to the application or destination.

Microperimeter runs on Linux workloads across private and public cloud platforms.

Microperimeter addresses a specific gap: east-west traffic between workloads that share the same network segment. Choose between deployment models based on your traffic pattern.

Microperimeter and Network Intercept are complementary. Network Intercept handles traffic that routes through the firewall naturally. Microperimeter captures traffic that bypasses the firewall because it stays within the same L2 segment.

The panredirect agent only runs on specific non-EOL Linux distributions. Verify each target workload before proceeding.

1. SSH to each target workload.
2. Check the distribution and version:

   cat /etc/os-release

   Copy
3. Confirm the NAME and VERSION_ID fields match a supported distribution above.

GENEVE encapsulation requires UDP 6081 open between each workload and the Prisma AIRS firewall data interface.

1. Identify the Prisma AIRS firewall data interface IP that will receive redirected traffic.
2. From each target workload, verify connectivity on UDP 6081:

   # Test UDP 6081 reachability to firewall data interface
   nc -zvu <firewall-data-IP> 6081

   Copy
3. Verify that any intermediate security groups, NACLs, or NSGs allow UDP 6081 in both directions between the workload and the firewall.

sudo firewall-cmd --zone=public --add-port=6081/udp --permanent
sudo firewall-cmd --reload

Microperimeter requires a deployed Prisma AIRS firewall with an available data interface. Standard VM-Series firewalls do not support this feature.

1. Confirm a Prisma AIRS AI Runtime Firewall is deployed and operational. If not, complete the AIRS Network Intercept Core Guide through Phase 4 first.
2. Verify the firewall has an available data interface that can be dedicated to Microperimeter traffic.

The panredirect installer is available from the Palo Alto Networks Customer Support Portal.

1. Log in to the Customer Support Portal (CSP).
2. Navigate to Updates > Software Updates > Traffic Redirector.
3. Download the panredirect installer package appropriate for your Linux distribution.
4. Transfer the package to each target workload (e.g., via scp).

The Prisma AIRS firewall needs a dedicated Layer 3 interface to receive GENEVE-encapsulated traffic from the panredirect agent. This interface must have a static IPv4 address reachable from all workloads running the agent.

1. Log in to the firewall management interface (or Panorama/SCM).
2. Navigate to Network > Interfaces.
3. Select the interface to dedicate to Microperimeter (e.g., ethernet1/2).
4. Set Interface Type to Layer3.
5. On the Config tab, assign or create a dedicated Virtual Router (e.g., VR-Microperimeter).
6. On the Config tab, assign or create a dedicated Security Zone (e.g., Zone-Microperimeter).
7. On the IPv4 tab, set Type to Static.
8. Click Add and enter the static IPv4 address with subnet mask (e.g., 192.168.101.1/24).

An Interface Management Profile on the data interface enables health check and telemetry communication between the panredirect agent and the firewall.

1. Navigate to Network > Network Profiles > Interface Mgmt.
2. Click Add to create a new profile (e.g., IMP-Microperimeter).
3. Enable HTTPS and Ping under Network Services.
4. Click OK.
5. Return to Network > Interfaces and select the Microperimeter data interface.
6. On the Advanced tab, set Management Profile to the profile created above (e.g., IMP-Microperimeter).
7. Click OK.
8. Click Commit to apply the interface and management profile configuration.

The firewall needs security policy rules to process the decapsulated east-west traffic arriving from the GENEVE tunnel. Without policy, the firewall will drop the redirected traffic.

1. Navigate to Policies > Security.
2. Click Add to create a new rule.
3. Set Name to a descriptive value (e.g., Microperimeter-EastWest).
4. On the Source tab, set Source Zone to the Microperimeter zone (e.g., Zone-Microperimeter).
5. On the Destination tab, set Destination Zone to the same zone (Zone-Microperimeter).
6. On the Actions tab, set Action to Allow.
7. Attach the appropriate Security Profile Group (AI Security Profile, Threat Prevention, etc.) to enable L7 inspection.
8. Click OK, then Commit.

Install the panredirect agent on each target Linux workload.

1. SSH to the target workload.
2. Make the installer executable and run it:

   chmod +x ./panredirect-installer
   sudo ./panredirect-installer

   Copy

panredirect version
panredirect 0.9.0-3

Point the agent at the Prisma AIRS firewall data interface so GENEVE-encapsulated traffic reaches the inspection engine.

1. Set the firewall IP:

   sudo panredirect configure --fwip <firewall-data-interface-IP>

   Copy

   Example:

   sudo panredirect configure --fwip 192.168.101.1

   Copy

sudo panredirect configure --fwip 10.0.3.4 --fwsubnet 10.0.4.0/24

Activate traffic redirection on the workload interface that carries the east-west traffic to be inspected. This is the interface whose traffic the agent will intercept.

1. Identify the target interface (e.g., ens224, eth0):

   ip link show

   Copy
2. Enable redirection:

   sudo panredirect enable <interface>

   Copy

   Example:

   sudo panredirect enable ens224

   Copy

sudo panredirect configure --fwip <firewall-IP> --exception <management-IP>

panredirect status
IF              FW_IP            VNI    IF_MAC             ACT
ens224          192.168.101.1    48813  00:50:56:95:f2:6e  yes

The built-in health check confirms the GENEVE tunnel is operational and the firewall is inspecting traffic correctly.

1. Run the health check:

   panredirect health_check

   Copy

By default, panredirect does not survive a system reboot. Enable the systemd service to ensure redirection starts automatically.

1. Enable and start the systemd service:

   sudo systemctl enable panredirect
   sudo systemctl start panredirect

   Copy
2. Verify the service status:

   systemctl status panredirect

   Copy

systemctl status panredirect
● panredirect.service - PAN redirect
     Loaded: loaded (/usr/lib/systemd/system/panredirect.service; enabled; preset: disabled)
     Active: active (exited) since ...
   Main PID: 1099 (code=exited, status=0/SUCCESS)

When redirection is enabled on an interface, a default rule redirects all traffic to the firewall. Selective steering rules allow granular control over which traffic is redirected and which bypasses the firewall.

Rule structure: Each rule matches on a 5-tuple:

Actions:

• pass — Route the matching traffic locally (bypass the firewall).
• redirect — Send the matching traffic to the firewall via GENEVE.

Evaluation order: Rules are evaluated in ascending index order. The first matching rule wins. The default catch-all redirect rule sits at index 0.

panredirect rule list
ifname          idx proto remoteip        rport localip         lport action
ens224          0   any   any             any   any             any   redirect

If the redirected interface also carries management traffic (SSH, monitoring), add pass rules to exempt that traffic from redirection. Insert these at a lower index than the default redirect rule so they match first.

1. Exempt SSH traffic from a specific management subnet:

   sudo panredirect rule insert --index 0 \
     --interface ens224 \
     --proto tcp \
     --remoteip 10.0.0.0/8 \
     --localport 22 \
     --action pass

   Copy
2. Exempt a specific trusted subnet from all inspection:

   sudo panredirect rule append \
     --interface ens224 \
     --proto any \
     --remoteip 192.168.100.0/24 \
     --localip 192.168.100.0/24 \
     --action pass

   Copy

Instead of redirecting all traffic, create specific redirect rules for only the traffic that requires inspection. This approach is useful when most traffic should bypass the firewall and only specific flows need L7 inspection.

1. First, delete the default catch-all redirect rule if switching to a targeted model:

   sudo panredirect rule delete --index 0 --interface ens224

   Copy
2. Add specific redirect rules for traffic that needs inspection:

   # Redirect HTTP/HTTPS traffic to AI model endpoints
   sudo panredirect rule append \
     --interface ens224 \
     --proto tcp \
     --remoteip 10.1.0.0/16 \
     --localport 443 \
     --action redirect

   Copy

Remove rules that are no longer needed by specifying the index and interface.

1. List current rules to identify the index:

   panredirect rule list

   Copy
2. Delete the rule by index:

   sudo panredirect rule delete --index <N> --interface <interface>

   Copy

   Example:

   sudo panredirect rule delete --index 3 --interface ens224

   Copy

Confirm the panredirect agent is running, redirecting on the correct interface, and communicating with the firewall.

1. Check agent status:

   panredirect status

   Copy

   Confirm ACT is yes for each redirected interface.

2. Run health check:

   panredirect health_check

   Copy

   Confirm the output is OK.

3. Verify the pangnv0 interface exists with MTU 1440:

   ip link show pangnv0

   Copy
4. Verify systemd persistence:

   systemctl is-enabled panredirect

   Copy

   Confirm the output is enabled.

Send traffic through the redirected interface to confirm the firewall receives and inspects it.

1. From the workload running panredirect, generate test traffic to another host on the same subnet:

   # HTTP request to a test target
   curl -v http://<target-host-IP>/
   
   # Or a simple ping
   ping -c 4 <target-host-IP>

   Copy
2. On the firewall, check the traffic log to confirm the redirected traffic was received and inspected:

   # From the firewall CLI
   show log traffic

   Copy

Confirm the firewall applies security profiles to the redirected traffic, not just forwarding it.

1. Generate traffic that should trigger a security profile action (e.g., a URL category match, a known test signature, or a DLP pattern).
2. Check the firewall threat log:

   # From the firewall CLI
   show log threat

   Copy
3. In SCM or Panorama, navigate to Monitor > Logs > Threat and filter by the Microperimeter zone.

Confirm that selective steering rules are working as expected: traffic matching pass rules bypasses the firewall and traffic matching redirect rules is inspected.

1. Generate traffic that matches a pass rule (e.g., SSH from the management subnet).
2. Verify this traffic does not appear in the firewall traffic log.
3. Generate traffic that matches a redirect rule.
4. Verify this traffic does appear in the firewall traffic log.

The panredirect agent includes a built-in diagnostic tool that collects a point-in-time snapshot of the agent status, host network configuration, and recent traffic patterns, similar to a Technical Support File (TSF) in PAN-OS.

1. Generate the bundle:

   sudo panredirect diag --out /tmp/microperimeter-diag.tar

   Copy
2. Extract and review:

   tar xf /tmp/microperimeter-diag.tar -C /tmp/diag-output/
   ls /tmp/diag-output/

   Copy

Diagnostic Bundle Contents

Systemd Service Commands

To completely remove the panredirect agent from a workload, stop redirection, disable the interface, and uninstall the package.

1. Stop all redirection:

   sudo panredirect stop

   Copy
2. Disable redirection on each interface:

   sudo panredirect disable <interface>

   Copy
3. Disable the systemd service:

   sudo systemctl disable panredirect

   Copy
4. Remove the package:

   RHEL / Rocky / Alma / OpenSuse:

   sudo dnf remove panredirect

   Copy

   Ubuntu / Debian:

   sudo apt remove panredirect

   Copy