Help: VLANs not routing traffic as expected.

I've been architecting a multi-tenant integration layer for our CRM and ERP systems, which requires strict network segmentation. To support this, I've configured a SonicWall TZ series appliance with several VLANs. The core issue is that while intra-VLAN communication functions, inter-VLAN routing is failing. Traffic from a client in VLAN 10 (192.168.10.0/24) cannot reach a server in VLAN 20 (192.168.20.0/24), despite what appear to be correct rules.

My configuration approach follows the principle of least privilege, similar to how I would design API access between microservices. The setup is as follows:

* **Zones & Interfaces:** Created VLAN10 and VLAN20 interfaces, both assigned to the same Layer 2 Zone (named "Internal_Segments").
* **Address Objects:** Defined objects for each VLAN subnet (VLAN10_Net, VLAN20_Net).
* **Access Rules:** Explicitly added an Allow rule on the "Internal_Segments" zone from VLAN10_Net to VLAN20_Net for necessary services (e.g., HTTPS, SQL). The intrazone default is set to "Deny."
* **Routing:** The appliance's routing table shows both VLAN subnets as directly connected routes.

From a client (`192.168.10.50`), a traceroute to `192.168.20.100` dies at the first hop (the client's default gateway, which is the VLAN10 interface IP `192.168.10.1`). Packet capture on the SonicWall for the VLAN10 interface shows the SYN packet arriving, but no corresponding outbound packet on the VLAN20 interface.

This suggests the firewall is not routing the packet between interfaces within the same zone, which contradicts my understanding of zone-based logic. In integration patterns, this is akin to a middleware bus failing to route messages between two authorized services.

My primary hypotheses are:
1. The "Internal_Segments" zone, being an L2 zone, is blocking L3 routing between its own member interfaces.
2. A hidden default rule or a stateful inspection nuance is dropping the packets.
3. A missing NAT policy (though I believe intra-appliance routing should not require NAT).

Could you review this configuration snippet and advise on the conceptual flaw?

```text
Interface Configuration:
X0: VLAN (untagged) - 10.1.1.1/24 (WAN)
X2: VLAN (untagged) - 172.16.1.1/24 (Trusted_LAN Zone)
X3: VLAN10 (tagged) - 192.168.10.1/24 (Internal_Segments Zone)
X3: VLAN20 (tagged) - 192.168.20.1/24 (Internal_Segments Zone)

Access Rule (Internal_Segments):
Rule 1: Allow | From: VLAN10_Net | To: VLAN20_Net | Service: HTTP/HTTPS/SQL | Log: Enabled
Default Intrazone Action: Deny
```

Is the correct design to place these VLANs in separate, dedicated zones (e.g., "VLAN10_Zone" and "VLAN20_Zone") and then create a cross-zone rule, treating them as fully distinct security domains? I am trying to reconcile SonicWall's zone philosophy with a segmented but not fully isolated internal data plane.

-- Ivan