Hey everyone! 👋 I just wrapped up a pretty intense migration project and wanted to share a detailed walkthrough. We moved ten geographically dispersed remote sites (retail locations, small offices) from a patchwork of legacy IPSec tunnels (using various old firewalls) to Prisma Access. The goal was zero downtime for point-of-sale and inventory systems, which was... ambitious.
**The "Before" State Was a Mess:**
* Ten sites, each with its own ISP and an aging firewall (mix of vendors).
* Hub-and-spoke IPSec tunnels back to a data center. Latency was a real issue.
* No consistent security posture; policies were managed per-device.
* Any network change meant updating 10+ individual tunnel configs. 😫
**Our Migration Philosophy: "Build the New Highway Before Closing the Old Road"**
We ran Prisma Access in parallel with the existing tunnels during a cutover window. Here's the high-level flow:
1. **Prisma Access Onboarding:** Got our ten remote networks defined under the `Mobile Users and Remote Networks` setup in the portal. The key was meticulously defining the address objects for each site.
2. **Parallel Tunnel Build:** We established new IPSec tunnels from each site's local firewall to the nearest Prisma Access PoP. This was the most hands-on part. We used IKEv2 with pre-shared keys. A generic config snippet we adapted for each site looked like:
```
# On the local firewall (example snippet)
network-interface tunnel.100
ip 192.168.100.1/30
exit
vpn ikev2-route-config "to-prisma-access"
interface tunnel.100
local-private-network "Site10-LAN" subnet 10.10.10.0/24
peer-public-network "Prisma-PoP-IP"
tunnel-establish tunnel-route
exit
vpn ipsec policy "Prisma-Access-Policy"
ikev2-reauth yes
proposal "aes256-sha256"
exit
```
3. **Route & Policy Cutover:** Once the tunnel to Prisma was up and passing health checks, we slowly shifted traffic. We started with low-risk systems (like internal dashboards) by adjusting the local route metrics, then moved critical systems (POS). We used BGP where possible, but static routes with higher/lower preferences were our friend at simpler sites.
4. **Legacy Tunnel Decommission:** After 48 hours of stable operation on Prisma Access, we disabled the old IPSec tunnels back to the data center.
**Key Gotchas & Lessons Learned:**
* **MTU/MSS Issues:** This was the biggest headache. Prisma Access adds overhead. We had to set `tcp-mss` adjustments on the local firewall's egress interface to Prisma (`clamp-mss-to-pmtu` or a hard value like 1350) to avoid weird packet fragmentation that broke some older applications.
* **Local Egress vs. Tunnel All Traffic:** We chose to tunnel *all* user traffic (0.0.0.0/0) from the sites to simplify policy enforcement and get full inspection. Just be mindful of bandwidth at each site.
* **Monitoring Gap:** The native Prisma Access logs are great, but correlating a site's tunnel drop with a specific ISP outage required looking at the local device logs. We ended up setting up a webhook from our firewalls to a Make scenario to alert on tunnel state changes.
* **Phased Approach is Non-Negotiable:** Migrating one or two sites first, learning, and *then* scaling to the remaining eight saved us. The process for site 10 was 80% faster than site 1.
The result? Latency improved for cloud apps (thanks to the PoPs), security posture is now unified, and adding a new site is a matter of minutes in the portal instead of a day of config. The admin overhead reduction alone is worth it.
If anyone's planning a similar move, I'm happy to dig into more specifics on the routing or policy translation. What's been your biggest hurdle with remote network migrations?
-- Ian
Integration Ian