Best Practices for Separate Networks for Firewall Interfaces

1) It is possible to have multiple subnets "behind" one router; the Internet would be a very broken place with millions more routers needed if it were not.

However, your example of using a /16 subnet mask on the LAN interface, with many /24's connecting to it, is not exactly how it would actually function. (More on that in a moment.)

2) There are many use cases. This aggregation and routing of traffic for many networks/ subnets is the purpose of a router.

Take for a simple example, a branch office location with VoIP telephones. At this site, there is a router connected via Dot1q trunking to a layer 2 access switch.

There is, of course, a need for separation of the Voice and Data traffic, which can be achieved by using separate VLANS on the access switches. Each VLAN will have a separate subnet back on our router. Each subnet would terminate on its own "sub interface", a logical partitioning of the physical connection to the access switches.

In this example, there are two subnets (one for data, and one for voice) living "behind" the router.

3) The performance benefit is that you don't need a different physical device to handle the routing for every single subnet in your network. You talk about the traffic ending up on the same router, and it does, but the traffic is still separated unless you specifically allow it to move between the subnets.

In simple case:

• You need only one VR. Multiple VR are needed when you want separate routing tables for different groups of interfaces (i.e. for different clients).
• If you can select destination for packet using only destination IP (and as I understand - you can), then you not need PBF. PBF is needed if you want to send packets with same destination IP to different next hops based on source IP/port and/or destination port.

And with your specific question:

• Based on Palo Knowledge Base you can have asymmetric routing between zones if you use:
  set deviceconfig setting session tcp-reject-non-syn no
set deviceconfig setting tcp asymmetric-path bypass
  
• But maybe you should rethink merging ZONE1, ZONE2 and ZONE3 into one zone because another article suggest that these commands effectively disable higher level scanning for asymmetric traffic. You probably can bypass this with adding artificial VR and scanning traffic between VR (where it will be symmetric), but this in effect will be same as merging zones - just more complicated.