Forum Discussion

Don_Steinberg's avatar
Don_Steinberg
Icon for Nimbostratus rankNimbostratus
Jun 04, 2014

Exchange 2013 iApp v1.3.0 - No response to CAS when accessing Autodiscovery VS

We have recently deployed Exchange 2013 using the 1.3.0 iApp. Initial testing indicated all was functioning as expected until the Exchange admins attempted to create/access a new mailbox via OWA. The initial authentication/connection to OWA functions as expected, but it appears when the CAS attempts to connect to the Autodiscovery VS no reply is received. No similar issue is observed with connections directly from devices on the "client" side of the LTM to the Autodiscovery VS.

 

A few basic details which might bypass the usual first round of questions:

 

vCMP running BIG-IP v11.4.1 (Build 608.0) with the following Resource Provisioning:

 

  • MGMT - Small
  • CGNAT - Disabled (Unlicensed)
  • LTM - Nominal
  • All Others - None

As such, APM should be uninvolved.

 

The iApp was deployed in a multi-VS mode for OWA, OA/EWS/OAB, ActiveSync, Autodisover and POP3 to load-balance and optimize CAS traffic with the following basic details:

 

  • SSL Bridging - No issues have arisen indicating certificate problems. The same certs are installed on each CAS and the LTM.
  • Different subnet for BIG-IP virtual servers and Client Access Servers
  • Client Access Servers use the BIG-IP as their default gateway
  • Use different IP addresses for the different services
  • Each service will be handled by a unique set of Client Access Servers (even though it is actually the same set of 16 servers providing all services)
  • Using Simple monitors

With the exception of POP3 (which has not yet been turned up), all monitors appear to be functioning as expected - all related nodes and pool members report a green "Available" status.

 

My initial suspicion is SNAT will be needed (which rather obfuscates the desire to maintain accurate client connection logs) in a "VIP Bounceback" (yes, I have been supporting BIG-IPs since the v4.x days) type of configuration (since the "client" for the secondary/back-end connection is on the same "side" of the LTM as the "server"), but I hesitate to just start changing such things without a level of confidence it will resolve the issue (and not significantly disrupt production traffic).

 

Thanks in advance for any suggested next-steps.

 

11 Replies

  • Dayne_Miller_19's avatar
    Dayne_Miller_19
    Historic F5 Account

    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!)

     

    • Don_Steinberg's avatar
      Don_Steinberg
      Icon for Nimbostratus rankNimbostratus

      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.

  • Hey Don,

     

    Can you please confirm if you managed to Offload ActiveSync for Exchange 2013 using the same iApp template?

     

    I am using the same Firmware release, everything works well except ActiveSync. It looks like my SSLHandshak is failing. Server immediately sends RESET after ClientHello packet.

     

    Tried to tweak with server-side profile, without success. Any clues?

     

    Thank you, Darshan

     

  • have you checked the ltm log? you could try enabling reset cause logging.

     

    http://support.f5.com/kb/en-us/solutions/public/13000/200/sol13223.html

     

  • Actually I ran TCPDUMP and SSLDUMP as well. In TCPDUMP, I could see only 5 packets,

    Syn
    Syn, ACK,
    ACK,
    ClientHello
    RESET
    

    I am suspecting the cipher suite incompatibility or sort of issue here, not sure if I am going to the right direction or not.

    I didn't enable the rstcausedb so far. I will enable it and verify it. However do you think cipher suite can be the issue?

    Cheers! Darshan

  • Dayne_Miller_19's avatar
    Dayne_Miller_19
    Historic F5 Account

    Hi Darshan-

     

    If you can upgrade your BIG-IP to 11.5.x, that should solve your problem.

     

    If upgrading isn't an option, you can use the following workaround:

     

    1. Create a custom Server SSL profile and associate it with the virtual server.
    2. To create the Server SSL profile a. On the Main tab, click Local Traffic > Profiles > SSL > Server. b. Click Create. c. In the Name box, type a unique name for this profile. d. In the Options row, click the Custom box. e. From the Available Options list, select No TLSv1.2, and then click the Enable button. f. Click the Finished button. g. Attach the new Server SSL profile to the virtual server either using the iApp.
    3. To attach the profile to the virtual server using the iApp template: a. Re-enter the iApp template (on the Main tab, click iApp > Application Services > [name of your Exchange application service] and then from the Menu bar, click Reconfigure). b. In the Tell us which services you are deploying section, from the "Which Server SSL profile do you want to use" question, select the Server SSL profile you just created. c. Click Update.

    Please let us know if that fixes the issue you're seeing.

     

  • Is this a known issue? I will follow your instructions and let you know the result.

     

    Thank you very much for your help.

     

    Cheers! Darshan

     

  • Hello Dayne,

     

    It worked like charm. I am very desperate to know the impact and reason to make TLSv1.2 disable on ServerSSL Profile.

     

    Can you please help me with that?

     

    Thank you very much for your help, Darshan

     

  • there was an earlier thread about this, but without any actual reason it doesn't work:

     

    https://devcentral.f5.com/questions/issues-with-exchange-2013-iapp-on-1141

     

    also by Dayne, so perhaps he was more to share now.

     

  • Dayne_Miller_19's avatar
    Dayne_Miller_19
    Historic F5 Account

    There's an incompatibility between the TLSv1.2 implementations in BIG-IP 11.4.x and some versions of Microsoft IIS. (Whether BIG-IP or IIS, or both, are technically incorrect, I don't know). Version 11.5 of BIG-IP changes F5's implementation in a way that makes the two interact successfully. I'm sorry, I don't have more details than that at this time.

     

    If the change is backported to the 11.4.x branch as a future hotfix, I'll announce it here.