Translating ASA object-groups to PAN-OS

Addresses and services look trivial to migrate — until nested groups, mixed-protocol service objects, and the port-vs-App-ID fork turn the simple part into the part that breaks your rules.

Objects look like the boring part of a firewall migration — addresses and services, just names for IPs and ports. Then you hit nested groups, service objects that bundle protocols PAN-OS keeps separate, and the question of whether a rule should match on a port or an application. The "simple" part is where a surprising number of migrated rules quietly stop matching.

The clean mappings

Most of it does translate directly. An ASA network object becomes a PAN-OS address object:

! ASA
object network WEB01
 host 10.1.1.10
object network DMZ_NET
 subnet 10.20.0.0 255.255.0.0

# PAN-OS
set address WEB01 ip-netmask 10.1.1.10/32
set address DMZ_NET ip-netmask 10.20.0.0/16

Hosts, subnets, ranges, and FQDNs all have direct PAN-OS equivalents. And object-group network becomes an address group — PAN-OS supports nested groups too, so a group-of-groups carries over structurally.

Where services get messy

Here's the first real divergence. A PAN-OS service object is single-protocol — it's TCP or UDP, with a destination port (and optionally a source port). An ASA object-group service doesn't respect that boundary; it can bundle TCP and UDP ports, and even ICMP, into one group.

! ASA — one group mixing TCP and UDP
object-group service DNS_SVCS
 service-object tcp destination eq domain
 service-object udp destination eq domain

That single ASA group has to become two PAN-OS service objects (a TCP one and a UDP one) collected into a service group. A converter that maps one-to-one without splitting produces a service object PAN-OS won't accept, or silently drops half of it. Any mixed-protocol service group is a place to look carefully.

One more that fails the commit rather than the traffic: ASA allows an empty object-group, PAN-OS does not. The ASA is happy to hold a group you declared but never populated — a placeholder, or one you emptied out and left behind. PAN-OS rejects an address or service group with zero members at commit time. Carry an empty group across untouched and the whole candidate config fails to commit, usually with an error that points at the group but not at why. Find the empty groups before the cutover: drop the ones you don't need, and populate the ones you do.

The fork in the road: ports vs. App-ID

This is the decision that defines the migration. The ASA is port-based — a rule permits TCP/443 and it's done. PAN-OS can do the same with a service, but its native model is App-ID: match on the application (ssl, web-browsing) with service application-default, so the rule follows the app regardless of port and blocks non-app traffic riding the same port.

A faithful conversion gives you port-based rules — TCP/443, not ssl. That's correct and it works, and it's the right first step because it preserves behavior exactly. But it doesn't use what you migrated to Palo Alto for. The realistic path is two-phase: convert literally to services first so the cutover behaves identically, then tune high-value rules to App-ID afterward, once the migration itself is proven. Trying to do both at once means you can't tell a migration bug from an App-ID tuning issue.

Migration is your one free cleanup

Because you're rebuilding the object set anyway, it's the cheapest moment to drop the cruft:

• Duplicate and overlapping objects — long-lived ASA configs accumulate three objects for the same host. Collapse them.
• Unused objects — defined once, referenced nowhere. Don't carry dead weight across.
• Names — ASA tolerates characters PAN-OS rejects in object names. Sanitize on the way over, consistently, so references don't break.

None of this is hard individually. It's the accumulation — a nested group three levels deep, containing a mixed-protocol service, referenced by a rule you're about to convert to App-ID — that turns objects from the boring part into the part you debug at 2 a.m. Resolve them to what they actually contain, not what they're named, and the rules that depend on them convert cleanly.

Written by Roman Dmytriv — network security engineer (CISSP), two decades securing and modernizing enterprise networks. More writing at blog.dmytriv.com, and I'm on LinkedIn.