Deepseek:
For an HA pair where the passive firewall has failed, the **Device State** file is the correct and recommended method to restore the replacement RMA firewall. You should not use a named configuration snapshot (XML) for this purpose .
The Device State file is a complete system backup that includes the running configuration along with critical runtime data such as certificates, keys, and most importantly, the High Availability (HA) running time or stateful info. This allows the new firewall to immediately synchronize with the active unit . A named configuration snapshot only captures the configuration and would require you to manually reconfigure HA settings and re-establish the sync relationship.
### 🔄 Step-by-Step Recovery Process
Here is the recommended workflow to bring your new RMA device online:
1. **Prepare the New Firewall**: Before restoring any data, perform initial setup on the new unit. Ensure its hardware model, PAN-OS version, and content database versions match the old (failed) firewall. Also, transfer the licenses from the old serial number to the new one .
2. **Obtain the Device State File**: You need a device state backup from a functional unit. Ideally, you would have a backup from the failed unit. If not, you can export the **Device State** from the currently **active** firewall (via `Device > Setup > Operations`) .
3. **Import the State and Break Sync**:
* On the new (replacement) firewall, import the Device State file (via `Device > Setup > Operations`) .
* **Crucially, do not commit the configuration yet.** After import, the new firewall will have the same IP and HA settings as the active unit. Navigate to the HA settings and **uncheck "Enable Config Sync"**. Also, set the device priority to a higher value (e.g., 200) to ensure it stays in the **Passive** state until fully ready. Chane Management interface IP, and change the HA peer IP which reflects
HA configuration from the failed firewall.
4. **Update Panorama (if managed)**: If your firewalls are managed by Panorama, you must update it to recognize the new hardware. Use the CLI command `replace device old <old serial#> new <new serial#>` and commit the change. You may also need to generate a new Device Registration Auth Key for the new firewall to connect .
5. **Finalize and Sync**: Perform a force commit on the new firewall via CLI (`configure` -> `commit force`). Once complete, re-enable "Enable Config Sync" in the HA settings. The new passive firewall should now synchronize its configuration from the active peer and show a "functional" or "passive" state in the HA widget .
### 💡 Important Considerations
* **Start with the Active Unit**: If your failed unit was the passive one, using the active unit's device state is a perfectly valid way to rebuild it .
* **Dynamic Configuration**: While the device state captures most settings, some dynamic data (like VPN satellite certificates) might not be fully restored. However, in an HA pair, the new unit will typically re-learn this information from the active peer after it joins the cluster .
* **Simplified with Strata Cloud Manager**: If you use Strata Cloud Manager (SCM), there is a newer, automated RMA workflow that simplifies this entire process and handles the configuration restoration for you .
I hope this helps you get your new firewall online smoothly. If you encounter any errors during the commit or sync process, let me know and I can help with some specific troubleshooting steps.
==========================
Kimi:
When the **passive** firewall in a Palo Alto Networks HA pair fails and needs RMA replacement, the procedure is simpler than replacing an active unit because there's no traffic disruption risk. Here's the comprehensive restore procedure:
## Critical Pre-Work Before Starting
1. **Verify the active firewall is stable** - Confirm it's handling all traffic normally and no failover events are imminent
2. **Document current settings** - Take screenshots of:
- HA General Settings (Device Priority, Preemption settings)
- Management Interface IP configuration
- Hostname of the failed unit
## RMA Restore Procedure for Failed Passive Firewall
### Phase 1: Prepare the Replacement Unit
1. **Register and license the new firewall**
- Transfer licenses from the old serial number to the new one via Palo Alto Support Portal
- Retrieve licenses on the new device: `Device > Licenses > Retrieve license keys from license server`
2. **Configure basic network access**
- Set management IP, DNS, and gateway (use a **temporary unique IP** initially to avoid conflicts)
- Verify internet connectivity to `updates.paloaltonetworks.com`
3. **Match software versions**
- Upgrade PAN-OS to match the active peer exactly
- Install matching content/threat database versions: `request content upgrade install version latest`
- Match any special settings (multi-vsys, jumbo frames, FIPS/CC mode)
### Phase 2: Restore Configuration
**Option A: If you have a Device State backup from the failed unit**
1. Import the device state: `Device > Setup > Operations > Import device state`
2. **Do NOT commit yet** - The import brings over the old management IP and hostname
**Option B: If no backup available (use active peer's config)**
1. From the active firewall, export device state
2. Import it to the replacement unit
### Phase 3: Critical HA Safety Configuration
**Before connecting to the network, force the replacement to stay passive:**
1. **Disable Config Sync** on the replacement: `Device > High Availability > General > Setup` - uncheck "Enable Config Sync"
2. **Disable Preemption**: `Device > High Availability > General > Election Settings` - uncheck "Preemptive"
3. **Set highest Device Priority** (e.g., 255) so it stays passive - lower priority number wins election, so higher number = lower precedence
4. **Change identity settings** back to the failed unit's original:
- Management IP
- Hostname
- HA settings (using screenshots taken earlier)
5. **Commit force from CLI**:
```
> configure
# commit force
```
### Phase 4: Connect and Synchronize
1. **Connect only HA1 control link first** (do not connect data plane interfaces yet)
2. **Verify configuration sync**:
- Check Dashboard > High Availability widget shows "Running Configuration: synchronized"
- CLI: `show high-availability all | match "Running Configuration"`
- Verify no idmgr differences: `debug device-server dump idmgr high-availability state`
3. **Enable Config Sync** on the replacement device
4. **Synchronize from active**: From the active unit, push configuration to peer if needed
5. **Connect HA2 link** for session synchronization
6. **Connect data plane interfaces** only after confirming sync is complete
### Phase 5: Finalize
1. Re-enable preemption if required by your design
2. Adjust device priority to match your original HA design
3. Verify HA status shows "Passive" and configuration is synchronized
## Key Differences from Active Firewall Replacement
| Aspect | Passive Replacement | Active Replacement |
|--------|---------------------|-------------------|
| **Traffic Impact** | None - active continues handling traffic | Risk of disruption during failover |
| **HA Priority** | Set high priority (255) to ensure it stays passive | Set high priority temporarily, then adjust |
| **Failover Risk** | Minimal - active is stable | Must ensure surviving peer is healthy first |
| **Session Sync** | HA2 syncs sessions from active to new passive | HA2 syncs from new active to new passive |
## Important Considerations
- **If managed by Panorama**: Replace the old serial number with the new one in Panorama CLI before the replacement connects: `replace device old <old SN> new <new SN>`
- **Master Key**: If the original firewall had a changed Master Key, you must configure it on the replacement before importing config, or commits will fail
- **No GARP needed**: Since the replacement starts as passive, no gratuitous ARP is required
- **Simpler verification**: Just confirm the unit shows "Passive" state and config sync is green
The key advantage of replacing a passive firewall is that **the active unit continues running production traffic throughout the entire procedure**, making this a zero-downtime maintenance operation .
Comments
Post a Comment