- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-28-2019 04:23 AM - edited 01-28-2019 04:23 AM
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
01-28-2019 06:52 AM
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.
08-26-2019 04:29 AM
@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.
08-26-2019 09:14 AM
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.
08-26-2019 09:45 AM
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?
08-26-2019 09:53 AM
@Pradeepkumar064 wrote:
...
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.
10-25-2019 04:41 AM
Sorry I was not checking the forum for long time, Thanks for your suggestion, will share the output once we implement the proposed change.
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!