Wednesday, 4 February 2026

🔄 Inter-VSYS Traffic — Why Two Sessions Are Created


When traffic flows between two Virtual Systems (VSYS) on a Palo Alto firewall, one session is NOT enough.
👉 Inter-VSYS communication always uses TWO sessions.
Let’s break it down in plain language.

🧱 Example Scenario
VSYS1 → user network
VSYS2 → server network
A host in trust1 (VSYS1) needs to reach a server in trust2 (VSYS2)

🔹 Session #1 (Inside VSYS1)
Traffic starts from trust1
Firewall creates Session #1
trust1 → untrust1  (VSYS1)
Traffic exits VSYS1 toward VSYS2
(internally or via a shared / external path)

🔹 Session #2 (Inside VSYS2)
Firewall receives traffic into VSYS2
Firewall creates Session #2
untrust2 → trust2  (VSYS2)
Traffic reaches the destination server

🧠 Why Two Sessions?
Because:
✔ Each VSYS is a separate firewall
✔ Each VSYS has its own policy engine
✔ Each VSYS enforces its own security rules
No VSYS can “see” inside another VSYS’s session.

⚠️ Important Things to Remember
✔ Policies are required in both VSYS
✔ Logs appear in both VSYS
✔ Troubleshooting requires checking two sessions
✔ One deny = traffic fails

🎯 Real-World Impact
If traffic works one way but not the other:
Check policies in VSYS1
Check policies in VSYS2
Check routing between VSYS
Check zones on both sides
Most inter-VSYS issues happen because only one side is allowed.

🔐 Final Thought
Think of inter-VSYS traffic as:
Firewall → Firewall inside the same box
Once you remember “two sessions, two policies”,
VSYS troubleshooting becomes much easier.

No comments:

Post a Comment

🔥 The Hidden Risk of “Wide Open” Internal Policies — And How To Remove Them Safely

In one of my recent projects, I noticed a wide open internal traffic policy in place. Later, I was asked to work on this issue and remove th...