Since the CSS needs to be in the path between the client host and the service host, you have to take care to ensure that all the service hosts will always be "behind" the CSS when you run it as a bridge.
I got bitten by this charateristic (CSS is not a proxy) when my network changed from:
WAN-Firewall-CSS-Services
to
WAN-Firewall-CSS-Services
_______|_________________
______TEST---Services
And the client expected me to balance the services hosted in the test network. Fortunately we use SSL and the Sonicwall SSL accelerators we have ARE proxies, so I was still able to make it work, since the SSL accelerators are directly connected to the CSS and the two flows are Customers-SSL and SSL-Services and the CSS is in the middle of each flow.
If all you've got "behind" the CSS are services that the CSS balances - then using the CSS as a router makes some sense. If you've got lots of networks behind the CSS and only a few of them have services on them, using it as a bridge and letting a router do the routing may make more sense.
Best wishes,
Tim
