How to Configure Your Next-Generation Firewall (NGFW)

Next-generation firewalls offer far more than packet filtering, but most production deployments underutilize them — relying on port-based rules while leaving TLS inspection disabled and application control unconfigured. This walkthrough covers the three controls that matter most: zone-based segmentation, TLS/SSL deep inspection, and layer-7 application filtering. Examples use Palo Alto Networks PAN-OS syntax, but the concepts map directly to Fortinet FortiOS, Check Point, and similar platforms.

Zone-Based Segmentation

Zone segmentation is the foundation of every NGFW policy model. Rather than writing rules between IP ranges, you define trust boundaries and enforce policy at those boundaries. Most misconfigured deployments either collapse too many segments into a single zone or leave implicit inter-zone trust in place.

Defining Zones

At minimum, production environments should separate:

On PAN-OS, zones are created and bound to interfaces:

# Create zones
set zone untrust network layer3
set zone trust network layer3
set zone dmz network layer3
set zone servers network layer3
set zone mgmt network layer3

# Bind interfaces to zones
set network interface ethernet ethernet1/1 layer3 zone untrust
set network interface ethernet ethernet1/2 layer3 zone trust
set network interface ethernet ethernet1/3 layer3 zone dmz
set network interface ethernet ethernet1/4 layer3 zone servers

Writing Zone-Based Security Policies

Zone policies should follow a default-deny model. Define explicit allow rules only where traffic flow is required, and deny everything else implicitly.

# Allow trust -> untrust (outbound internet, inspected)
set rulebase security rules outbound-internet from trust
set rulebase security rules outbound-internet to untrust
set rulebase security rules outbound-internet application any
set rulebase security rules outbound-internet service application-default
set rulebase security rules outbound-internet action allow
set rulebase security rules outbound-internet profile-setting group strict-inspection

# Allow untrust -> dmz (inbound to public services only)
set rulebase security rules inbound-dmz from untrust
set rulebase security rules inbound-dmz to dmz
set rulebase security rules inbound-dmz destination [ 10.0.2.10 10.0.2.11 ]
set rulebase security rules inbound-dmz application [ web-browsing ssl ]
set rulebase security rules inbound-dmz service application-default
set rulebase security rules inbound-dmz action allow

# Deny dmz -> servers (DMZ must never reach internal DB tier directly)
set rulebase security rules dmz-to-servers-deny from dmz
set rulebase security rules dmz-to-servers-deny to servers
set rulebase security rules dmz-to-servers-deny action deny
set rulebase security rules dmz-to-servers-deny log-setting default-logging

A critical mistake is allowing dmz → trust or dmz → servers without explicit justification. Compromise of a DMZ host should not provide lateral movement into internal tiers.

TLS Inspection

The majority of modern malware, command-and-control traffic, and data exfiltration rides over TLS. Without decryption, your NGFW is inspecting metadata only — signatures, application control, and URL filtering all degrade significantly for encrypted sessions.

How TLS Inspection Works

The firewall acts as a man-in-the-middle proxy. For outbound traffic (forward proxy), it terminates the client TLS session, re-encrypts toward the destination using a CA certificate your endpoints trust. For inbound traffic (reverse proxy / inbound inspection), it decrypts sessions destined for internal servers using the server’s private key.

Deploying a Forward Trust Certificate

Generate or import your internal CA into the firewall, then push it to endpoints via GPO or MDM so clients trust the re-signed certificates:

# Import CA certificate and key (PAN-OS)
set certificate-profile TLS-Inspection-CA ca-certificates Internal-CA
set certificate-profile TLS-Inspection-CA username-field subject cn

# Configure forward trust and forward untrust certificates
set shared ssl-decrypt forward-trust-certificate-rsa Internal-CA
set shared ssl-decrypt forward-untrust-certificate-rsa Untrusted-Signer

The forward-untrust certificate is presented to users when the destination certificate is invalid or self-signed — this is your mechanism for surfacing certificate errors that would otherwise be hidden.

Creating a Decryption Policy

# Decrypt outbound HTTPS from trust zone
set rulebase decryption rules decrypt-outbound from trust
set rulebase decryption rules decrypt-outbound to untrust
set rulebase decryption rules decrypt-outbound source any
set rulebase decryption rules decrypt-outbound destination any
set rulebase decryption rules decrypt-outbound service application-default
set rulebase decryption rules decrypt-outbound type ssl-forward-proxy
set rulebase decryption rules decrypt-outbound profile Outbound-Decryption-Profile
set rulebase decryption rules decrypt-outbound action decrypt

# Exclude sensitive categories (banking, healthcare) from decryption
set rulebase decryption rules no-decrypt-sensitive from trust
set rulebase decryption rules no-decrypt-sensitive to untrust
set rulebase decryption rules no-decrypt-sensitive category [ financial-services health-and-medicine ]
set rulebase decryption rules no-decrypt-sensitive action no-decrypt

Place the no-decrypt exclusion rule above the decrypt rule. Rule order is top-down.

Decryption Profile Settings

Enforce minimum TLS protocol versions and reject weak cipher suites at the decryption profile level:

set profiles decryption Outbound-Decryption-Profile ssl-forward-proxy block-expired-certificate yes
set profiles decryption Outbound-Decryption-Profile ssl-forward-proxy block-untrusted-issuer yes
set profiles decryption Outbound-Decryption-Profile ssl-protocol-settings min-version tls1-2
set profiles decryption Outbound-Decryption-Profile ssl-protocol-settings max-version max
set profiles decryption Outbound-Decryption-Profile ssl-protocol-settings keyxchg-algo-rsa no
set profiles decryption Outbound-Decryption-Profile ssl-protocol-settings enc-algo-rc4 no
set profiles decryption Outbound-Decryption-Profile ssl-protocol-settings auth-algo-md5 no

Rejecting RSA key exchange forces forward-secrecy cipher suites (ECDHE). Blocking RC4 and MD5 removes legacy weaknesses that are actively exploited.

Application Control

Port-based rules are blind to evasion techniques — applications like Tor, BitTorrent, and many C2 frameworks routinely tunnel over port 443 or 80. Layer-7 application identification classifies traffic by behavioral signatures, not just port numbers.

Application Identification Prerequisites

Application-ID on PAN-OS requires:

• Correct zone assignment (traffic must pass through the firewall, not around it)
• TLS inspection enabled for encrypted application traffic (otherwise App-ID sees ssl generically)
• Security policy set to service: application-default to prevent port-hopping

Building Application-Aware Rules

Replace generic port-based rules with explicit application references:

# Allow only sanctioned SaaS — block everything else outbound
set rulebase security rules sanctioned-saas from trust
set rulebase security rules sanctioned-saas to untrust
set rulebase security rules sanctioned-saas application [ office365 google-workspace zoom salesforce ]
set rulebase security rules sanctioned-saas service application-default
set rulebase security rules sanctioned-saas action allow
set rulebase security rules sanctioned-saas profile-setting group strict-inspection

# Block high-risk application categories explicitly
set rulebase security rules block-highrisk from trust
set rulebase security rules block-highrisk to untrust
set rulebase security rules block-highrisk application [ tor bittorrent ultrasurf anonymizer-pro ]
set rulebase security rules block-highrisk action deny
set rulebase security rules block-highrisk log-setting default-logging

# Block unknown TCP/UDP (often evasion or malware)
set rulebase security rules block-unknown from trust
set rulebase security rules block-unknown to untrust
set rulebase security rules block-unknown application [ unknown-tcp unknown-udp ]
set rulebase security rules block-unknown action deny
set rulebase security rules block-unknown log-setting default-logging

Application Override (Selective Bypass)

For proprietary or custom applications that App-ID cannot classify, use application override to assign a known application context rather than leaving traffic as unknown:

# Force custom app classification for internal monitoring tool on TCP 9200
set rulebase application-override rules internal-elastic from trust
set rulebase application-override rules internal-elastic to servers
set rulebase application-override rules internal-elastic destination 10.10.5.20
set rulebase application-override rules internal-elastic port 9200
set rulebase application-override rules internal-elastic protocol tcp
set rulebase application-override rules internal-elastic application elasticsearch

Use override sparingly. Every override is a gap in full App-ID processing.

Attaching Security Profiles

Application control only blocks known bad applications. Pair every allow rule with a security profile group that includes antivirus, anti-spyware, vulnerability protection, URL filtering, and file blocking:

set profile-group strict-inspection virus default
set profile-group strict-inspection spyware strict
set profile-group strict-inspection vulnerability strict
set profile-group strict-inspection url-filtering Strict-URL-Profile
set profile-group strict-inspection file-blocking strict-file-blocking
set profile-group strict-inspection wildfire-analysis default

Apply strict-inspection to all outbound and inbound allow rules. Apply at minimum vulnerability and antivirus profiles to inter-zone rules between internal segments.

Conclusion

Zone segmentation, TLS inspection, and application control are interdependent — application control is partially blind without decryption, and decryption is ineffective if traffic is incorrectly zoned. Start with a clean zone model and a default-deny posture, deploy forward-proxy TLS inspection with appropriate exclusions, then layer application-aware rules on top with full security profile coverage. Audit your decryption policy hit counts and App-ID logs regularly; unknown-tcp and unknown-udp blocks are the most reliable early indicator of evasion activity or misconfigured applications in your environment.