how to clear TCP options using Palo Alto firewalls?

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.

how to clear TCP options using Palo Alto firewalls?

L1 Bithead

At the moment we are replacing our Cisco ASA firewalls with Palo Alto firewalls and one thing we cannot still figure out is how to make the Palo Alto firewalls to clear the TCP options on TCP sessions. This can be done, in Cisco ASA firewalls, using the commands:

tcp-options clear range <lower number> <higher number> clear

Is there any way to do the same with PA firewalls?

8 REPLIES 8

L4 Transporter

This completely blows my mind if it's true, but the response I received from support when I was researching TCP options and their interaction with PA firewalls was this:

Hello Eric

I did some research on this one for you.

PA firewalls does not alter the TCP options, whenever we send traffic through the Firewall, TCP options are no altered.

Please let me know if you have any questions.


Thank you again for choosing Palo Alto Networks.


Sincerely,

Harsha Natarajan | Network Security Engineer

L4 Transporter

See my thread here on Riverdbed Steelhead appliances and TCP options (which is why I was looking into what PA does with TCP options in the first place):

https://live.paloaltonetworks.com/message/23134

L1 Bithead

I am actually requiring to clear TCP option 21 which is used by Cisco WAAS. It looks like some device close to the server our users are trying to reach is dropping packets with this option enabled. I guess, if not currently available, we would have to submit a feature request that can enable us to clear these options.

If you submit a "handle TCP options" FR I would sign up for it too... the fact that PA just ignores them completely doesn't seem right to me.

If you activate SYN Flood Protection in your Zone Protection Profile, I believe you will lose TCP options.

This can be a bad thing. For example, last time I looked, the email servers for Google Postini could not handle 1500-byte packets, and were behind a packet filter that blocked outbound ICMP size exceeded. End result, if you miss the MSS=1420 hint in the TCP options, you could not send email messages longer than about 1300 bytes to any client of Google Postini.

I understand there might be specific situations where turning on or off TCP options might break stuff, but the option to tune them should be there either way in my humble opinion.

With firewalls there's plenty of potential for us to break lots of stuff, that's why we get paid the big money (to NOT break stuff because we have the knowledge I mean :smileylaugh: )

L1 Bithead

I agree with egearhart. We should be given the ability to turn on/off TCP options for certain src zone to dst zone flow and the granularity to decide which options I can turn on/off. At the moment we have sites that are not accepting our packets with certain TCP options leaving our network and it would be beneficial for us to, at least, turn this option off.

My main point was that for me, turning on SYN Cookies in a Zone Protection Profile had the unintentional effect of clearing all TCP options. This was bad for me, but if the behavior still exists, it could be good for you. I went back and found the original ticket was longer ago than I though, at PAN-OS 3.x. Maybe the "bug" I reported was "fixed," maybe not.

Yes, selective TCP option washing would be best.

  • 3794 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!