Steelhead Appliance

[Edwin Groothuis]

When a Steelhead appliance sees a naked SYN, it will try to insert an auto-discovery probe in it. If they both fit it the TCP options field, it will optimize against the first one which matches. If the second one doesn't fit, it will just pass it through.

Edwin

[geertn444]

Ok thanks.

Thinking about this solution, i have just one question: what will the SH do when he is configured to use option 75 for example and he receives a SYN packet with already option 76 in it ? Will he add his option ? do nothing ? Or remove the old option and put his opion in it ?

We have the following case:

PARTNER -->-- PARTNER SH ---->----- BOUNDARY ----  OUR DATACENTER ---- SH ---- WAN ---- SH ----- REMOTE SITE

As you can see, if i configure our SH with a non-default option, what will happen if our datacenter SH sees a SYN with an option inserted from PARTNER SH ?

Goal: the session from partner -> remote site, might be optimized between our SH, but not between our SH and the partner SH.

[Edwin Groothuis]

Hello,

So far , the only zero administration and scalable way to split two groups of Steelhead appliance in the same network is by using different autodiscovery TCP options values.

Ask the TAC about the KB article and commands for it.

Edwin

[cgeary]

1) Yes, lots of admin overhead but would work.

2) If you know the subnets of the remote sites, then you can create passthrough rules for them. But at this time, we don't have a concept of NOT rules

3) Yes, we have this facility. These are hidden commands so please drop me a PM and I'll let you know what they are. This could be the right solution for you here but each time you add a new Steelhead to your environment, you'll need to remember to configure the secret key or it won't optimize.

4) Dropping port 7800 traffic will cause connection setup delays. You would be better off stripping the autodiscovery probes. Some firewalls can be configured to do this and pass the packet on. This may also be the right solution for you here and may cause you slightly less admin overhead than 3.

[geertn444]

We have deployed Steelhead appliances in our network, but we are connected to trusted partners who have also deployed Steelheads (with their policies). However, these are not managed by us and traffic to these remote trusted partners may NOT be optimized (traffic is monitored and accounted for)

Problem now: I have added peering rules to only allow peering with our known SH IP addresses.

However, this is not enough. I have an in-path rule: "AUTO-DISCOVER protocol: 445 destination:all". This rule triggers remote steelheads not managed by us to peer back to with my SH appliance. I don't want this !

So what are my options:

1) remove the "destination:all" and replace this by +/- 10 rules detailing all our subnets:

           10.200.0.0/16

            10.16.0.0/16

              etc...

   We have lots of ranges and this would be horrible to manage, and it would need to be specified for every general protocol

we would like to optimize ("general" means: without specific destination servers specified, for example HTTP (80), CIFS (445), NETBIOS (139)....

2) Can i specify an in-path rule specifying a negative destination subnet ?

       For example: if destination is NOT 10.200.0.0/16, then PASS, not autodiscover

   This would allow me to add once on top of my in-path rules, all our subnets. If NOT in these subnets, then don't auto-discover.

3) Can i put a "peering" secret key on all our managed steelheads ? if the peering key does not match with the destination

SH, then don't peer. Simple. Does this exist ?

4) Can i put a router ACL on the edge to prevent peering ? For example, if i define on the edge routers, drop ALL 7500 TCP towards or from my steelhead appliances, would that prevent peering ?

regards,

Geert