I think I'm going crazy getting my CSS11501 to work as intended!

Question

I've been posting here before regarding CSS and NAT'ing and how our web servers just log the VIP address of the CSS.
Now it turns out after a talk with our programmers, we can't use NAT at all because the backend servers will deliver services based on source IP addresses.
So here's my configuration: backend servers -> HP Procurve 2650 -> CSS11501
The CSS interface where the servers are connected to have the following configuration:
interface e5
bridge vlan 2
redundancy-phy
phy 100Mbits-FD
And circuit VLAN2 is as follows:
circuit VLAN2
description "LAN"
redundancy
ip address 192.168.1.4 255.255.255.0
I tried yesterday to separate two servers as a test in a vlan so that the CSS would act as a bridge between the servers and our firewall (which acts as a router).
So on the switch, I assign the ports for e5 on the CSS as untagged in the default vlan and tagged in vlan2. I then assigned the server ports for untagged in vlan2 and 'no' for the default vlan.
They can't see each other with this configuration, and setting the e5 interfaces as untagged in vlan2, tagged in vlan1 and the server ports untagged in vlan2, they still can't see each other!
And I really mean they can't see each other, if I clear the arp cache for the servers, the CSS doesn't pick up the MAC addresses again, so it's clear that there's something with the vlan tagging.
I've been working on this for a week and it's just getting more frustrated as I try different things which still doesn't work, what am I doing wrong?
Also there's a potential additional problem which I hope I can get an answer to: The servers has two nic's active. The primary nic has an IP address which is on the same subnet as the CSS WAN interface. If I get the servers and the CSS to talk across the vlans, will this be a problem with bridging, as the CSS finds a host on its LAN segment which has an IP address that belongs to its WAN segment?

Answer 1

Thanks Gilles.
I read the list of advantages and disadvantages.
However the only disadvantage I can see, is that the CSS yelds lower performance since it has to shuffle inbound and outbound traffic on the same interface.
For instance: "When using this configuration, the load balanced servers will see all traffic as being originated from the CSS rathar than the real client source IP address. You do not get a true representation of where your traffic is coming from."
and in the following example:
"The CSS is now configured to load balance to the services, however, there is one problem. When the traffic goes through the CSS to get load balanced, the destination IP address is changed but the source IP address is not changed. When those packets head back to the client, they bypass the CSS through the switch because the servers' default gateways are set to the router IP address and the source IP address of the load balanced request is not on the local subnet.
You must not only NAT the destination address of the packet but the source addresses as well. In order to do this, configure the source groups."
This could be considered a bit misleading; I set the default gateway for the servers to the CSS, and not only do I *not* need to NAT, I *do* see the real client source IP address not the CSS VIP address, and furthermore, the servers have full access to all of our network resources as well as the internet if we chose to.