Concept of Tags and Profiles in Cisco’s 9800 WLAN Controller

 

Palo Alto Networks – Service Route vs Virtual Router (Know the Difference)

One of the most misunderstood topics in Palo Alto firewalls is the difference between Virtual Router and Service Route.
They serve different traffic types and solving issues often depends on knowing which one is in use.


-Virtual Router (VR)
The Virtual Router controls how production (user/application) traffic is routed through the firewall.
It handles:
Inter-zone traffic
Internet access
East–West traffic
Static & dynamic routing (OSPF, BGP)

- Service Route

A Service Route controls how the firewall itself sends traffic to external services.
Examples include:
DNS & NTP
Syslog & SNMP
LDAP / RADIUS / TACACS+
Software & content updates
License communication
In short: If the firewall generates the traffic, it uses Service Routes

Key Takeaway

Virtual Router = Data plane routing
Service Route = Control & management plane routing
This explains why:
Internet works, but updates fail
Users are authenticated, but LDAP lookups fail
Traffic flows, but logs never reach the SIEM


Best Practice
In complex environments (IT / OT / DMZ):
Always define Service Routes explicitly
Don’t assume they follow the Virtual Router
Document them as part of the firewall design

🚨 Palo Alto SSL Decryption breaks self-signed certificate websites — here’s why

“Website was working fine yesterday.
Today it shows a certificate error after enabling decryption.”
If you’re running Palo Alto Networks firewalls, this is one of the most common production issues teams face.

Let’s break down exactly why this happens.
🔍 What changes when SSL Decryption is enabled in Palo Alto

When SSL Forward Proxy is enabled:
Client → Firewall
Firewall terminates the SSL session
Firewall re-signs the certificate using its Forward Trust CA
Client validates the new certificate
At this point, the firewall is a controlled Man-in-the-Middle (by design).

❌ Why self-signed certificate websites fail
Self-signed certificates already operate on weak trust.
SSL decryption exposes that weakness immediately.

1️⃣ No trusted CA chain
Website uses a self-signed certificate
Palo Alto re-signs it with its own CA
Browser now sees:
Unknown website + unknown CA
Result → Hard certificate warning

2️⃣ Certificate pinning breaks
Some internal or legacy apps:
Expect a specific certificate fingerprint
Do not accept re-signed certificates
Once decryption modifies the cert →
The application rejects the connection.

3️⃣ Forward Trust CA not deployed everywhere
If the Palo Alto Forward Trust CA is missing on:
Endpoints
Servers
VDIs / non-domain devices
Even trusted sites can fail —
self-signed sites fail every time.

4️⃣ Legacy TLS and weak crypto
Many self-signed sites still use:
Old TLS versions
Weak cipher suites
Palo Alto enforces stronger crypto during decryption →
Handshake fails before traffic even starts.

🛠 Correct architect approach
✅ Exclude self-signed destinations from decryption
Use decryption exclusions based on IP, URL category, or certificate.
✅ Use No-Decrypt for internal / legacy apps
Admin portals, lab tools, monitoring pages.
✅ Deploy Forward Trust CA properly
Endpoints, VDIs, MDM-managed devices — no shortcuts.
✅ Decrypt with intent, not blindly
Zero Trust does not mean decrypting traffic you don’t control.

💡 Final takeaway
SSL decryption is powerful —
but trust is fragile.
Self-signed certificates don’t break because of Palo Alto.
They break because decryption exposes poor certificate design.
Design first.
Decrypt second.