Firewall offloading traffic -- how to disable

by panagent on ‎03-16-2012 11:02 AM - edited 3 weeks ago by (12,865 Views)

Inside of this article you will learn how to verify if traffic is being offloaded and how to disable this feature.

 

When session traffic is processed by the dataplane of the Palo Alto Networks firewall, session stats and timers will be updated for every packet.

 

Most of our high-end platforms have an FPGA chip to entirely offload a session (CTS and STC flows) and bypass the cores completely. 

 

Verification

You can verify if a session has been offloaded by using the following CLI command:
> show session id <id_num>

 

Here's an example of an SSL session that is offloaded because it is not being decrypted. The firewall cannot do any content threat detection, so it is offloaded to hardware for faster processing:

admin@PAN_firewall> show session id 96776

Session           96776

        c2s flow:
                source:      172.20.13.132 [L3-Trust]
                dst:         50.17.226.145
                proto:       6
                sport:       61973           dport:      443
                state:       ACTIVE          type:       FLOW
                src user:    unknown
                dst user:    unknown

        s2c flow:
                source:      50.17.226.145 [L3-Untrust]
                dst:         10.46.198.13
                proto:       6
                sport:       443             dport:      14690
                state:       ACTIVE          type:       FLOW
                src user:    unknown
                dst user:    unknown

        start time                           : Thu Oct 12 09:30:35 2017
        timeout                              : 1800 sec
        time to live                         : 1799 sec 
        total byte count(c2s)                : 54759
        total byte count(s2c)                : 134469
        layer7 packet count(c2s)             : 103
        layer7 packet count(s2c)             : 200
        vsys                                 : vsys1
        application                          : ssl  
        rule                                 : Trust-Untrust
        session to be logged at end          : True
        session in session ager              : True
        session updated by HA peer           : False
        address/port translation             : source
        nat-rule                             : Trust-NAT(vsys1)
        layer7 processing                    : completed
        URL filtering enabled                : True
        URL category                         : computer-and-internet-info
        session via syn-cookies              : False
        session terminated on host           : False
        session traverses tunnel             : False
        captive portal session               : False
        ingress interface                    : ethernet1/6
        egress interface                     : ethernet1/3
        session QoS rule                     : N/A (class 4)
        tracker stage l7proc                 : ctd decoder bypass
        end-reason                           : unknown

Note:  In PAN-OS 7.1 and later, an offloaded session will have a tracker stage l7proc value of ctd decoder bypass.

 

All session statistics and timers are maintained in software. So, it's necessary for the offload chip to send regular updates to the software. These updates cannot be sent for every packet, due to performance concerns.

 

Offloading details - what happens inside

Depending on the platform model, different rules apply:

 

PA3050 - 50xx series

Offload chip is sending a per-flow stat message to the dataplane after 16 packets are received on one flow

(CTS or STC).

The dataplane software will update session statitics and refresh the timer accordingly.

 

Note: On PA3050 and 50xx series devices, you can have a scenario where a low-traffic session has been aged-out due to TTL expiration. This can happen if the 16 packets condition has not been met before the end of this timer.

 

PA70xx series

The PA7000 seies devices handle the updates differently.

It will send the per-flow stat to the dataplane when one of two following conditions occur:

  • One flow has accumulated 64 packets of stat
  • A scan timer has expired for this particular flow

Software will update session statistics and refresh the timer accordingly.

 

Workaround

To avoid the offloading of the sessions, there are several workarounds to achieve this:

 

  • Turn off hardware offload temporarily using with the CLI command: (will reset to offloading after a reboot)

    > configure
    set session offload no 

     or permanently with: (even after a reboot, the offloading will be disabled)

    > configure
    # set deviceconfig setting session offload yes 
    # commit

     Note: This approach can have a noticeable impact on the CPU.

  • Create a custom application and adjust the timeout value for the custom application to accommodate the worst-case scenario. We accept a maximum timeout value of 604800 seconds (1 week).

  • Tune the tcp keepalive timer and interval on the application servers.

 

Comments
by a.cadarso
on ‎06-26-2012 10:43 AM

"For sessions that will be offloaded there must be a minimum of 16 packets scanned before a message is sent to the CPU to reset the timeout for the session. "


Can you please explain this point, I don't understand its meaning.


I assume it is indicating that sessions will be offloaded in the future ...... but :

ONE -- If the CPU doesn't scan 16 Packets then the session will timeout. Which timeout?

TWO -- If the CPU scan 16 packets then a message is sent to the CPU to reset the timeout. Who sends the timeout message?


Additionally, if the session is offloaded. what happen with that timeout?

by mgarg
on ‎12-17-2016 02:31 PM

Every time a packet is matched with the session in the fastpath the timer for the session is reset. This is for the sessions that are not offloaded. So if even a single packet is not seen by the firewall in either direction matching that session for its lifetime, the session will be marked as discarded

 

For sessions that are offloaded the session lifetime timer is not reset after every single packet. The offloaded session must see about 16 tcp packets in either direction before the cpu resets the session lifetime. Similarly for udp it is 8 packets before the session is reset.

 

 

Ask Questions Get Answers Join the Live Community