Routing – Does normal packet flow within a virtual router in a PA firewall require a rule

firewallpalo-altorouting

I'm trying to understand packet flow within a Palo Alto firewall. Our firewall has one "inbound" leg and three "outbound" legs corresponding to different exterior VLANs. The exterior VLANs are used for differing purposes (think multiple DMZs with a transit interface). We want traffic to arrive at the inbound interface of a firewall (INSIDE), get NAT to an IP on one zone (ZONE2), then be routed to a third zone (ZONE1). A recent attempt at this configuration failed, but we were unable to obtain a packet capture before we had to return the firewall to normal operation. For those of you experienced with Palo Alto firewalls, what is the anticipated packet flow in an environment like this and can you answer the following questions:

  • Should I be able to achieve this with a single VR or will I need to define a different VR on a per-zone basis and/or define PBF behaviors?
  • Will a rule be required for transit from the "ZONE2" zone to the "ZONE1" zone?
  • Will the firewall drop the return traffic by default because the flow may seem asymmetric? (The router directly will forward traffic to the Palo Alto's "ZONE2" interface) – If so, how do I disable this behavior when a zone protection profile is set to the "global" rule under asymmetric drop?

Diagram:

topology

Best Answer

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.
Related Topic