CSS 11503 Destination NAT - can only enable one service

Question

I have three web servers configured as six services. Three are for MOSS (Microsoft Office Sharepoint Server) and three are for SSRS (SQL Server Reporting Services 2006 in integration mode).
THE PROBLEM:
When more than one MOSS service is active I can no longer connect to the SSRS services.
This is a trunked Configuration:
interface 1/1
trunk
redundancy-phy
vlan 1
default-vlan
vlan 100
vlan 101
vlan 103
interface 3/16
bridge vlan 4000
circuit VLAN100
redundancy
ip address 192.168.100.xx0 255.255.255.0
circuit VLAN103
redundancy
ip address 192.168.103.xx0 255.255.255.0
circuit VLAN4000
ip address 1.x.x.2 255.255.255.252
redundancy-protocol
circuit VLAN101
redundancy
ip address 192.168.101.xx0 255.255.255.0
service MOSSWeb01
ip address 192.168.103.xx1
keepalive port 80
keepalive type tcp
active
service MOSSWeb02
ip address 192.168.103.xx2
keepalive port 80
keepalive type tcp
active
service MOSSWeb03
ip address 192.168.103.xx3
keepalive port 80
keepalive type tcp
active
service SSRSWeb01
ip address 192.168.103.xx1
active
service SSRSWeb02
ip address 192.168.103.xx2
active
service SSRSWeb03
ip address 192.168.103.xx3
active
owner MOSS
content MOSS
vip address 192.168.100.xx1
vip-ping-response local-remote
add service MOSSWeb01
add service MOSSWeb02
add service MOSSWeb03
active
owner SSRS
content REPORTSERVER
vip address 192.168.100.xx2
add service SSRSWeb01
add service SSRSWeb02
add service SSRSWeb03
vip-ping-response local-remote
active
group MOSS2007-DSTNAT
vip address 192.168.100.xx1
add destination service MOSSWeb01
add destination service MOSSWeb02
add destination service MOSSWeb03
active
group SSRS2005-DSTNAT
vip address 192.168.100.xx2
add destination service SSRSWeb01
add destination service SSRSWeb02
add destination service SSRSWeb03
active
NOTES:
All (3) real servers have a default route to 192.168.103.xx0 which insures traffic passing through the CSS (so I don't understand why I still need a destination service group).
When MOSS accesses SSRS it does so via http://SSRS2005/reportserver. This is configured in DNS as 192.168.100.xx2. I would think that this would also insure traffic through the CSS but I still had to configure a destination service for these.
All clients connect to the MOSS services via one VIP (192.168.100.xx1) and the MOSS services connect to the SSRS services via a 2nd VIP (192.168.100.xx2). MOSS also connects to itself for indexing content and a variety of other services (I had originally tried separating the MOSS content rules using layer 5 matching on Host Headers. This seemed to cause issues with access to ports 139 and 445 for UNC access to document libraries so I simplified the MOSS content rule back to layer 3).
I have setup two distinct groups and have used destination NAT so that the servers can communicate to each other.
When using Wireshark on the servers to run packet traces and all services are up I do not even see any packets destined for the SSRS services leading me to believe that they are dropped by the CSS (however, I don't see them using show flows on the CSS either).
Can anyone here shed some light on the correct way to configure the CSS in such a scenario?
Thanks in advance.

Answer 1

I have two MOSS services down because MOSS can't get to SSRS if more than one MOSSservice is active. That's the crux of the biscuit.
I had hoped to avoid the whole packet sniffing activity but it looks like I may need to capture more information. I don't really want to change the VLAN configuration since this CSS is managed by our network team and there are other services configured on the CSS that I have not indicated.
I appreciate your advice, so far. I will actually have some downtime this coming weekend where I can try some additional configuration options after prime time from home.
One thing that may not be apparent in this whole discussion is that all of the sites on both MOSS and SSRS use HOST Headers for HTTP. That's what keeps them separated. I had tried using layer 5 content rules but had the same issue plus other issues with non-HTTP traffic. I also did not care for the fact that the CSS actually spoofs the responses when using layer 5. There is a lot of NTLM Challenge/Response traffic for Windows Integrated Authentication and Negotiated Kerberos. The bottom line is that even without Layer 5 content rules the Host Headers do get passed to IIS and the sites are selected properly based on that header. The exception is that Host Headers are no longer required for SSRS since it is the default website on port 80 (besides - setting up host headers for SSRS in MOSS integration mode has it's own set of issues). Still, the host headers are sent to SSRS SOAP Endpoints and there are no issues connecting to any of the three SSRS services from any of the three MOSS servers interactively. The issue is when a client outside of these VLANs makes a request for a report.
client->MOSS->SSRS->MOSS->client
Be aware too that both MOSS and SSRS are making connections back through the CSS to their respective databases for each request.