- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-08-2013 04:52 AM
I see that there's a 'riverbed-rios' app listed in Applipedia, which gives me some hope.
Specifically what I am concerned about is discussed here (with configuration examples for PIX/ASAs):
http://www.dslreports.com/faq/16494
The Riverbed appliances we have take advantage of TCP option 76 for autodiscovering other Steelhead appliances that are in-path. Has anyone configured a Palo Alto to allow this traffic? I'm not finding anything in the CLI guide that implies this advanced, granular configuration of TCP is available, but I'm hoping I'm wrong and this traffic can be permitted (or is magically already permitted by using the 'riverbed-rios' AppID - that would be awesome).
02-18-2013 04:32 PM
Just to clarify on this one here's Palo Alto support's reply to this question:
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
07-17-2013 06:31 PM
Hey Eric,
Just wondering how you went with this?
I need to implement something similar. My incredibly limited understanding of the situation is that in the scenario above for cisco the traffic passes like:
LAN1-Riverbed1-Gateway1-INTERNET-Gateway2-Riverbed2-LAN2
BUT in Palo world, the traffic needs to go to the PA Firewall, THEN to the Riverbed, THEN back to the PA Firewall, THEN off to its final destination.
07-17-2013 07:21 PM
We actually haven't implemented firewalls on both sides of Riverbed appliances yet, so unfortunately I don't have any experiences to share. We have plans in the works to implement PA, but the actual implementation is about a month out. The most I had received from support was as it is above, basically "PA won't muck with option 76 traffic." So in theory the Riverbeds should see each other and work as normal (at least in theory).
Sorry!
07-17-2013 07:26 PM
No problems mate - thanks for the prompt reply 🙂
I'll probably be implementing in the next month or so as well.
I will be sure to share my experiences here when its done!
07-18-2013 06:53 AM
We have a remote branch office VPNed back to our Datacenter via an IPSEC tunnel between two Palos ; in the DC I setup a separate interface for the branch office traffic on the Palo, the routed the traffic out of the DC steelhead to that interface, down the IPSEC tunnel & out the other end where the second steelhead picks it up.
Works fine - Palo identifies the traffic as application riverbed-rios so there may be a gotcha in there if you want to filter by application type (since you cant tell what the original app was once its been processed by the steelhead).
07-18-2013 03:13 PM
Some excellent feedback there SimmSimm - thank you so much for that!!
Cheers!
07-19-2013 02:57 AM
Hi,
If you want to be more granular, you can plug your riverbed on palo and use PBF for routing traffic to remote site equiped with remote Riverbed Mean:
server - palo - riverbed - palo - Ipsec tunnel - Remote site
server - palo - IpSec tunnel - Remote site.
and if install a ne remote Riverbed, just add subnet ini pbf rule.
Meke sense ?
V?
02-28-2024 11:42 AM
Hi,
This thread is over 10yrs old, but currently have issues with RB Steelheads behind palos
lan-rb-palo-ipsec-srx-rb-lan works fine
migrated out the srx with palo recently
lan-rb-palo-ipsec-palo-rb-lan not working for optimization
Tried any:any on both side
Tried app override for ports 7800-7850 riverbed peering
Just see resets in the packet captures.
PanOS running 10.2.7-h3
Riverbed RIOS 9.14.2
Appreciate any thoughts on what to try next
Thanks
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!