Palo Alto - TCP Normalization

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Palo Alto - TCP Normalization

L1 Bithead

Hi !

 

We are migrating to Palo Alto from ASA Where ASA TCP normalization is enabled for option 28. 

 

How we can achive the same in Palo Alto ?

 

8 REPLIES 8

Cyber Elite
Cyber Elite

hi @gpsriram

 

What are you looking to achieve exactly?

TCP options are generally left alone unless they are malicious, but depending on your needs there may be different approaches

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Cyber Elite
Cyber Elite

@gpsriram,

From an ASA configuration standpoint I really don't get what you are asking for? Normalization is always enabled on an ASA, so if you have any statements in your current configuration for this there should be more to the configuration than it simply being enabled. 

As @reaper mentioned, if you describe what you were attempting to do on the ASA we can see what the Palo Alto equivalent would be. 

@BPry & @reaper Thanks for your reply. Below are the ASA configuration.. We are using TCP option 28

 

 

tcp-map TCP28
tcp-options range 28 28 allow
!

policy-map global_policy
set connection advanced-options TCP28
!

@gpsriram Have you found solution for this case yet? because we ran into same kind of problem, if you have solution already please post it here.

So I'm looking into what option 28 is and I don't really see why this is directly needed in the Palo.  (If I'm understanding the RFC correctly)

 

So option 28 is "User Timeout Option"

 

https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml

 

Which is specifically referenced here:

 

https://tools.ietf.org/html/rfc5482

 

"This document specifies a new TCP option -- the TCP User Timeout Option (UTO) -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the connection to adapt its user timeout
accordingly. That is, TCP remains free to disregard the advice provided by the UTO option if local policies suggest it to be
appropriate.

 

Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a
short time without connectivity."

 

So is the ultimate intent to just set a VPN/Tunnel timeout value?  If so there are already configuration parameters in GP that do this.

@Brandon_Wertz 

 

Thanks for the reply, today we had received a request from client end asking to block the traffic coming towards Palo alto which is with TCP option 76, because traffic flows in following order,

 

1, Email Server

2, Palo Alto

3, Riverbed

4, Internet

5, Cisco ASA 

6, Email server

 

Riverbed configuration similar to below details,

 

=======================================

Details

Steelhead appliances use following TCP options:

  • Option 76: Riverbed auto-discovery probe.

  • Option 77: OutOfPath NAT.

  • Option 78: WAN visibility transparency option.

=================================================

Cisco ASA:

Here is a configuration example to allow tcp-option 76 through 78.

 

access-list riverbed_tcp extended permit tcp any any

class-map tcp-traffic

match access-list riverbed_tcp

 

tcp-map allow-probes

tcp-options range 76 78 allow

policy-map global_policy

class tcp-traffic

set connection advanced-options allow-probes

 

service-policy global_policy global

 

Can we configure the Palo Alto firewall in the same way?


@Pradeepkumar064 wrote:

@Brandon_Wertz 

 

...

 

Can we configure the Palo Alto firewall in the same way?


I think you need to change how you're thinking.  Just like @reaper mentioned to the OP.  Don't try to "make Palo be like the ASA," but instead get at what are you trying to accomplish.  Then leverage the Palo for that purpose.

 

Based on what you described it seems like you're leveraging the ASA "as a poor man's palo" so to speak.  Using TCP options as a way to "allow applications."

 

I think ultimately in the Palo world this Riverbed traffic would be an "application" and ultimately, yes you can do what you're doing in Palo like what you're doing in the ASA.  You just need to create security policy which leverages the RB apps as identified by Palo.

 

RIOS.PNG

Sorry I was not checking the forum for long time, Thanks for your suggestion, will share the output once we implement the proposed change.

  • 6395 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!