Forum Discussion
This sounds almost certainly like an asymmetric routing issue, as you suggest.
From a CAS server, can you connect to the Autodiscover virtual server via a telnet session, curl request, or Web browser? You don't need to worry about authentication or anything; you just want to see if you get a response. Wireshark would be helpful to see if you get return traffic.
Anyway, assuming that's the source of the problem, you have a couple of options:
1) Turn on SNAT. Also enable the X-Forwarded-For header (the iApp will do this for you) and set up IIS Advanced Logging to capture that field so you still have accurate original IP info in the logs. The Deployment Guide explains the steps to do this.
2) Run the iApp again and set up another virtual server for only the Autodiscover service. Set the virtual server to be on the server-side network. You'd have to enable SNAT for this, but if you choose this option you can leave SNAT off for the client-facing virtual server. Then make sure that 'autodiscover.' resolves to the server-side virtual server by making a 'hosts' file entry on each CAS server.
If neither of those work, or don't make sense to you, or you'd like more detailed suggestions/directions, just let us know. (And if this was in fact the problem, please update us with that information as well!)
My apologies for the long-overdue update to this post (thought I had updated it when the solution was identified).
As Dayne Miller suggested, enabling SNAT was the chosen solution. I recently ran across a more elegant solution using an iRule for selective SNAT which has proven to resolve the issue for the server-to-server communications while regaining the ability to track true client addresses for the vast majority of the traffic. We created an iRule named LB-Servers-to-VIPs-SNAT-Bounceback-23-bit_irule with the following "Definition":
when LB_SELECTED {
if {[IP::addr "[IP::client_addr]/23" equals "[LB::server addr]/23"]} {
snat automap
}
}
With this iRule, the only detail which might need to be modified is the size of the network where the servers reside. If a large number (64,000+) of concurrent connections of this type is expected, an SNAT pool (such as LB-Servers-to-VIPs-SNAT_pool) can be created and "
snatpool LB-Servers-to-VIPs-SNAT_pool
" would replace "snat automap
" in the iRule.
While we were at it, we defined similar "generic" iRules on all our LTM deployments for network sizes ranging from 20-bit to 25-bit and will be implementing them for similar reasons in the future.
Thanks to Dayne for the quick response which led to our initial solution and, again, my apologies for not responding in kind. Hopefully someone will still find this old post useful.