Check Point and Riverbed - any issues?

[Thorpuse]

Hi All,

I'm working on a site where they are intending to run Riverbed devices through a Check Point firewall - has anyone had any experience with this and know of any issues? Specifically, I'm concerned about the following :

1. As I understand it, the Riverbed boxes create a tunnel between the two boxes for Acceleration. If the traffic is tunneled, can the firewall still have any visibility of the traffic?
2. Other WAN Acceleration devices that I know of manipulate parts of the IP header for signalling. Does the Riverbed do the same, and does Check Point have a problem with this (I'm thinking particularly around SmartDefense as well as standard IP header checking here).
3. If the traffic is tunnelled, am I right from a Security angle to be paranoid about the gaping access hole this will put in my security policy? From a management perspective, what's the correct way to position the risk around this?

If anyone else has had to deal with this, I'd be pleased to get your feedback, as well as any other comments about how the solution works or doesn't work.

Thanks,

[cciesec2006]

Originally Posted by Thorpuse

Hi All,

I'm working on a site where they are intending to run Riverbed devices through a Check Point firewall - has anyone had any experience with this and know of any issues? Specifically, I'm concerned about the following :

1. As I understand it, the Riverbed boxes create a tunnel between the two boxes for Acceleration. If the traffic is tunneled, can the firewall still have any visibility of the traffic?
2. Other WAN Acceleration devices that I know of manipulate parts of the IP header for signalling. Does the Riverbed do the same, and does Check Point have a problem with this (I'm thinking particularly around SmartDefense as well as standard IP header checking here).
3. If the traffic is tunnelled, am I right from a Security angle to be paranoid about the gaping access hole this will put in my security policy? From a management perspective, what's the correct way to position the risk around this?

If anyone else has had to deal with this, I'd be pleased to get your feedback, as well as any other comments about how the solution works or doesn't work.

Thanks,

This is an interesting problem. We use Riverbed in our frame-relay
environment that connects between the HQ and remote-offices but not
through the firewalls. I do have a Riverbed box in my lab that I am going
to try it through my NGx R65 firewalls. Will let you know how it goes.

[Thorpuse]

Originally Posted by cciesec2006

This is an interesting problem. We use Riverbed in our frame-relay
environment that connects between the HQ and remote-offices but not
through the firewalls. I do have a Riverbed box in my lab that I am going
to try it through my NGx R65 firewalls. Will let you know how it goes.

Thanks for that - your design is exactly what i recommended, but I was outvoted....

The other concern I've got (particularly as Riverbed tunnels traffic) is that the tunnelled traffic is going to accelerate traffic between the internal and external Riverbeds, then try and route the traffic back through the firewall. Anti-spoofing hilarity ensues....

[rubber_chicken]

I'm running riverbeds over site to site VPN's. I've got a mesh of sites where the config is essentially:

LAN1
|
Riverbed1
|
Gateway1
|
Wild Wild Web
|
Gateway2
|
Riverbed2
|
LAN2

You get the drift.

All we did was plug them in and turn them on (ok a little bit more - but not much). All was "ticketty-boo". It even fixed(masked) some underlying problems with file copy problems. It works so well that the users complain bitterly when they are not working for whatever reason. My site to site VPN mesh allows all ports and in SmartView tracker you just see the traffic on the startard ports (TCP7800 and a few others from memory). As the units are "in-line" and have correct internal addresses we have no antispoofing issues.

[Thorpuse]

Thanks Rubber_chicken. Any concerns about losing the capacity to inspect traffic due to the Riverbed's tunnelling? Although in your case, your VPN is allowing all traffic bidirectionally, so your trust levels must be high on the security imposed on the LANs.

[rubber_chicken]

Originally Posted by Thorpuse

Thanks Rubber_chicken. Any concerns about losing the capacity to inspect traffic due to the Riverbed's tunnelling? Although in your case, your VPN is allowing all traffic bidirectionally, so your trust levels must be high on the security imposed on the LANs.

In our situation there are no concerns really. We don't run any port based security over the VPN's and for performance reasons we don't log this inter-site VPN traffic anyway. These VPN's form around 30% of our intersite links (just the international ones where we'd be "financially violated" by Telco's). All our local national links are provided over Frame Relay/ATM/DSL etc and are open pipes as they are not firewalled.

I only turn the logging on for the VPN's when I want to diagnose something. The Riverbed logging gives enough of a heads up for the minor day to day issues.

All said and done we are sold on them, put them in-line (no worries about single point of failure as they fail to wire - been there, tested that) and away you go.

[abusharif]

Maybe a bit late, but i've deployed recently couple of RVBD's through Nokia/R65 and havent seen any issues.