Offering a scalable, single content switch
solution without the IP accounting limitations of the Proxy Mode,
Transparent Mode is both the most complex, and the most feature rich of all
the configurations. Transparent mode’s intricate packet flow requires a
certain set of capabilities from the content switch. Specifically, the
content switch must offer two features: flow switching and cache-device ACL
support.
Flow switching support is necessary in
order to ensure that traffic passing transparently from the content switch
to the SSL-x follows a specific path. While this path is comparatively
easy to ensure in a non-transparent proxy implementation, it is somewhat
more difficult to guarantee in a transparent One-Armed SSL Offloading model.
This model can easily breakdown after traffic passes from the real-server
back to the content switch. The default behavior of most switching devices
at this point would be to pass the traffic directly back to the client
rather than to the SSL-x. The reason it is absolutely essential to pass it
back to the SSL-x is so that the traffic be encrypted prior to passing back
to the client.
The second requirement, cache-device ACL
support, is also worthy of specific mention because of its
unconventionality. Cache-device ACL support is a generic term for the
handling of traffic in a transparent redirection scenario, and does not, in
our application, refer to a cache device, but rather to an SSL-x device.
This feature enables the content switch to apply access-controls to traffic
returning from a transparent cache-device. These access-controls will be
used to govern routing of traffic on the upstream router VLAN, and on the
SSL-x device VLANs, as well as to control configuration manager access (TCP
and UDP port 2932).
One-Armed SSL Offloading Transparent Mode
Configuration
The physical layout of Transparent Mode is
very much like that of Proxy Mode. Unlike Proxy Mode, which does not require
separate VLANs be defined for each SSL-x device, Transparent Mode does
require that each SSL-x be on its own VLAN. This requirement is part of the
mechanism designed to ensure that real-server traffic be routed back through
the correct SSL-x device before returning to the client.
