Why do many Palo Alto engineers open a TAC case immediately… without checking anything first?

A production issue happens.

Application team says “network issue.”
Users say “firewall problem.”

And within minutes someone says:

“Let’s open a TAC case.”

But here is the reality experienced firewall engineers know:

In many situations… the firewall is not actually the problem.

Before opening TAC, every Palo Alto engineer should quickly validate a few basics:

✔ Did the traffic actually hit the firewall?
✔ Was a session created for the flow?
✔ Which security rule matched the traffic?
✔ Was NAT applied correctly?
✔ Did any security profile block the traffic?
✔ Is the return traffic taking a different path?
✔ Is routing or the server causing the issue?

You would be surprised how many “firewall issues” are actually:

• Asymmetric routing problems
• Wrong NAT configuration
• Security policy mismatch
• Application-side issues
• DNS or routing mistakes

🚨 𝗠𝗮𝗷𝗼𝗿 𝗜𝗻𝗰𝗶𝗱𝗲𝗻𝘁 / 𝗢𝘂𝘁𝗮𝗴𝗲 𝗖𝗮𝗹𝗹? 𝗛𝗲𝗿𝗲’𝘀 𝗛𝗼𝘄 𝗧𝗼𝗽 𝗡𝗲𝘁𝘄𝗼𝗿𝗸 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗛𝗮𝗻𝗱𝗹𝗲 𝗜𝘁

From my experience handling incident bridges:

👉 The problem is rarely the issue
👉 The problem is how we approach it

🧠 𝟭. 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝘁𝗵𝗲 𝗖𝗮𝗹𝗹 𝗙𝗶𝗿𝘀𝘁

During outages:

Users are confused
Managers are under pressure

👉 If you don’t control the call, you lose direction

Start with:
“Let’s first understand the exact issue”

💡 Clarity > Speed

🔍 𝟮. 𝗗𝗲𝗳𝗶𝗻𝗲 𝘁𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝗖𝗹𝗲𝗮𝗿𝗹𝘆

Avoid:

“App not working”
“Internet is down”

Convert into:

Which app?
Which URL/IP?
From where?
Since when?

🌐 𝟯. 𝗟𝗼𝗰𝗸 𝗦𝗼𝘂𝗿𝗰𝗲 & 𝗗𝗲𝘀𝘁𝗶𝗻𝗮𝘁𝗶𝗼𝗻

Most users won’t know — guide them:

Windows → ipconfig
Linux → ip address / ifconfig
Mac → ifconfig

👉 No clarity = No troubleshooting

📍 𝟰. 𝗨𝘀𝗲 𝗬𝗼𝘂𝗿 𝗜𝗣 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆 ⭐

Users won’t know hosting details.

👉 Always maintain an IP Details Sheet

Map:

IP → Location (DC / Cloud)
Environment
Application / Owner

💡 Saves huge time during incidents

🧭 𝟱. 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝘁𝗵𝗲 𝗣𝗮𝘁𝗵

👉 How traffic flows from source → destination

Use:

Network diagrams
Your architecture knowledge

🧱 𝟲. 𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝘆 𝗗𝗲𝘃𝗶𝗰𝗲𝘀 𝗶𝗻 𝗣𝗮𝘁𝗵

Routers
Firewalls
Load Balancers
Proxies

👉 Firewall is not always the issue


🔄 𝟳. 𝗖𝗵𝗲𝗰𝗸 𝗥𝗲𝗰𝗲𝗻𝘁 𝗖𝗵𝗮𝗻𝗴𝗲𝘀 𝗙𝗜𝗥𝗦𝗧


👉 “What changed recently?”

Most outages = change impact

Policy / NAT
Routing
Certificates

👉 Revert → Validate → Restore


📊 𝟴. 𝗩𝗮𝗹𝗶𝗱𝗮𝘁𝗲 𝗦𝗺𝗮𝗿𝘁𝗹𝘆

Don’t rely only on firewall logs

Check:
Ping / Traceroute
Packet capture
Server / LB logs


🧪 𝟵. 𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝘆 𝘁𝗵𝗲 𝗟𝗮𝘆𝗲𝗿

L2/L3 → Connectivity
L4 → Port issue
L7 → App / SSL

Example:
👉 “Not Secure” → Likely certificate issue


🗣️ 𝟭𝟬. 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗲 𝗟𝗶𝗸𝗲 𝗮 𝗟𝗲𝗮𝗱𝗲𝗿

Clear updates
No assumptions
Keep everyone aligned

🎯 Final Thought
👉 Don’t follow noise
👉 Don’t jump to logs
👉 Don’t assume firewall

Instead:

✅ Understand
✅ Map
✅ Then troubleshoot