Dataplane Limitations - When to use a router for intrazone vlan routing?

[Scruffy]

Hi,

This is  a question about when to use the firewall or a seperate core router to route traffic vor vlans in the same zone (intrazone).

As this traffic does not need to be inspected, it should only be using the network layer and cpu of the dataplane.

I tend to use the FW (simpler, more secure) but at which point would you recommend using a seperate router to do this?

I guess the bottleneck in this case is the dataplane, bus and network cpu. Are there any specs regarding the limitations of the dataplane on how much traffic can be switched, routed using only the network layer of the dataplane? Or is it the same as using the specified firewall throughput including App-ID? E.g in case of the PA5220, 20Gb.

regards

Jonathan

[reaper · Accepted solution]

The firewall treats all connection the same, so intrazonewill still go through the whole process of being inspected.

any sessions that are simply bounced off the interface risk running into asymmetry as the returning packets will likely be routed directly to the original client and bypass the firewall, which will cause the firewall to assume the session is broken and terminate the connection which will also interrupt new packets from the original client

If the only requirement is to bounce packets, it is probably better to have a dedicated router in place

alternatively you can set up 2 L2 interfaces that connect the 2 areas as a switch and set a virtual L3 IP to serve as default gateway, so you can still achieve full session sanity and apply the level of scanning you do like (app-id would be a minimum)

[Scruffy]

Ok, thanks for your feedback.

I was under the impression that these packets would only affect the network layer of the dataplane and would be forwarded to the egress stage immediately, according to this document:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0&refURL=http%3A%2F%...

The ingress stage receives packets from the network interface, parses those packets, and then determines whether a given packet is subject to further inspection. If the packet is subject to further inspection, the firewall continues with a session lookup and the packet enters the security processing stage. Otherwise, the firewall forwards the packet to the egress stage

Just to get a better understanding of the process, which kind of packets are then actually not subject for further inspection?

regards

Jonathan

[reaper]

that stage is called fastpath, it is only used in 2 scenarios:

- the received flow is a protocol we don't inspect, so can be egressed out immediately

- inspection on a flow is completed and no additional inspection will be performed, so flow can be fast-forwarded out 

all other flows go through slowpath and are inspected

[Scruffy]

Great, thanks for your help

[jeremy.larsen]

I'd be curious to see how putting an intra-zone allow rule at the top of the ruleset with no filtering profile would affect throughput.  Would this allow this traffic to be fast-pathed?

[reaper]

The rule order will have no influence on fastpath, this is a decision made by app-id and content-id engines on a session by session basis

The only way to force this would be to set an app override for all sessions between the zones, but this will still not fully accomplish your objective and I wouldn't recommend it