Asynchronous Security Zones?

[ALSdburns]

Is there an issue with asynchronous routing if the traffic passes through different security zones? We have our PAs setup with subinterfaces for our respective VLANs. So we have:

Eth1/3.10

Eth1/3.20

Eth1/3.30

Eth1/3.40

These subinterfaces connect to a trunk port on an Aruba 6300. The 6300 just has a default route configured which points to to the Palo Alto Eth1/3.10 IP address. That means Internet traffic leaving the 6300 will go through Eth1/3.10 but return traffic will go through the respective sub interface because of the connected route. This has never been an issue before when all subinterfaces were in the same security zone. I recently tried changing the security zone of Eth1/3.10 and after that change all subinterfaces except eth1/3.10 stopped connecting properly. The traffic fails despite nothing getting blocked. If I run a pcap I see the traffic leaving and returning as expected. The only error I am getting is if I 'run show counter global filter delta yes severity drop' it will have 'Packets dropped: forwarded to different zone' as one of the counters. 

Is there something wrong with this setup? We do not have any zone protection profile applied, and have tried even adding an allow all policy to ensure everything is allowed so I don't understand why the traffic is being dropped. Does the PA just not allow traffic to leave on one zone and return on another?

[rmfalconer]

There probably is an issue with asymmetry on zone traversal. If you look at session information, it shows c2s and s2c flows including the zones on each side. I would imagine the traffic needs to stick to these zones and not return through a different zone pair.

Why do you have subinterfaces for each vlan on the firewall? If you have a default on 10 on the core switch, why have subs for the other vlans? 

[ALSdburns]

Thanks for the reply, I kind of figured that was what was going on but I can't find documentation to confirm. I have a support ticket open as well and they said the configuration is valid, but it seems like that must be incorrect. What I think it is and what you seem to be alluding to is that the return traffic has a session lookup, the session is found but has mismatched zones, and the packets are dropped. 

To be honest, it is mostly a holdover from the config before I started. Now we mostly keep it to stay uniform (some sites have gateway set to the PA instead of a core switch for various reasons). If we could get this configuration to work properly, we'd also filter inbound traffic to certain zones. Maybe we need to rethink it however.