On a zone-based firewall, why can a host reach another host in the same zone by default (even on a different subnet), yet be blocked from a host in the DMZ — and what does that reveal about default behaviour?
A connectivity check makes it visible: pinging from a staff PC to a file server (different subnet but same Inside zone) succeeds, but pinging a web server in the DMZ fails. Traffic within the same zone is allowed by default, but inter-zone traffic requires an explicit rule — and the DMZ is treated as untrusted even though it's "internal".
* Default intrazone-allow vs interzone-deny logic. *
The two ping results:
Mitarbeiter-PC (192.168.110.10) → ping 192.168.100.10 (Fileserver) ✓ SUCCESS
Mitarbeiter-PC (192.168.110.10) → ping 10.0.0.10 (Webserver) ✗ FAILS
Why each behaves the way it does:
| Scenario | Same zone? | Default behavior |
|---|---|---|
| Staff → Fileserver | Both Inside (same zone, even if different subnets) | Allowed — intra-zone traffic implicitly trusted |
| Staff → Webserver | Inside → DMZ (different zones) | Blocked — interzone traffic needs explicit rule |
The hidden assumption — "intrazone-default":
Palo Alto's default rules include:
intrazone-default: any zone → same zone — Allow
interzone-default: any zone → different zone — Deny
These exist at the bottom of every policy and are the catch-all for traffic not explicitly matched. They reflect the standard whitelist-with-default-deny pattern, applied to zones.
The "DMZ is completely walled off" reality:
"Die DMZ jedoch ist komplett abgeschottet. Jede Verbindung nach innen und aussen muss explizit erlaubt werden."
Even though the DMZ is "internal," it's treated as untrusted because it hosts public services. This is correct security thinking: a compromised web server should not have free access to file servers.
Why this surprises beginners:
The intuition "internal = trusted, internet = untrusted" doesn't capture the nuance that the DMZ is internal but untrusted. The zone model forces explicit policy decisions for every cross-zone flow.
Tip: When troubleshooting "why can't I reach X," always ask: are source and destination in the same zone? If yes, look at intrazone rules. If no, look at the explicit interzone rules — and don't assume default-allow.
Go deeper:
Create a Security Policy Rule (Palo Alto) — the default intrazone-allow / interzone-deny behaviour behind the ping result.