Forum Discussion

iclay_37999's avatar
iclay_37999
Icon for Nimbostratus rankNimbostratus
Apr 11, 2012

New iApp, Exchange 2010 and SSL bridging

I have ran through the new iApp for Exchange 2010, trying to use SSL bridging, but no matter what I do, I can't get it to work at all. OWA is just giving me Page Cannot Be Displayed. Granted, I am an F5 rookie, so I'm sure I did something wrong. We're on 11.1 on our LTMs, not using APM or any other product. Just Exchange and the LTMs. According to the MS article, when using SSL Bridging, I don't need to enable any sort of offloading in Exchange, so Exchange is still on the default. Any thoughts on what I need to check?
  • Hi iclay,

     

    Was the same setup working fine before putting the new release of iAPP on ver 11.1???? were you using the same version ???? If yes... then it should work... From your explanation what I have understood is that you are using end to end SSL so you must have uploaded the Certificate and the key to the LTM boxes. Secondly in the iAPP run down config you have to offload SSL and have to select to again encrypt the traffic using the same certificate and the key sending it to the CAS array servers. It should work I have still not tried the latest release of iAPP but I am using the similar environment as yours in which I have end to end SSL. if this dosent work try creating a VS manually with client and server side ssl profile set using your certificates to ensure if it is working fine or not at all. If you discover any other problem do let us know if this resolves your problem that will be great.

     

     

    Regards,
  • Dayne_Miller_19's avatar
    Dayne_Miller_19
    Historic F5 Account
    I'll let iclay respond if so inclined, since I can't share details about that configuration, but the summary is that the issue ended up being one of network topology rather than iApp configuration. Once that was sorted out, the iApp worked correctly.

     

     

    Techgeeeg: Actually, you don't have to select the same cert and key for the serverssl section (the re-encryption part). The old iApp erroneously asked for a cert and key but never actually used them. The BIG-IP is acting as a 'client' in that context, with each CAS pool member being the server; the 'client' is not expected to present a cert or key.

     

     

    The new iApp fixes a large number of issues (including no longer asking for the cert/key for re-encryption)and offers much more flexibility in deployments. We recommend it for all 11.x customers.
  • Hi Miller,

     

    How about the advanced monitors for Exchange 2010 is it part of the new iAPP or we still have to create it ????? also the advanced monitors as described in the deployment guide of F5 For exchange 2010 Auto Discover, Outlook anywhere and active sync never worked is it still the same or these issues are also sorted out in te new iAPP ???? any idea over it...

     

     

    With SSL bridging what I understand is that its SSL all the way from client to the CAS servers???? m i thinking wrong... correct me... pls

     

     

    Regards,
  • Dayne_Miller_19's avatar
    Dayne_Miller_19
    Historic F5 Account
    The new advanced monitors -- which perform synthetic transactions that emulate "real" clients and use actual user credentials that you supply -- are configured by the new iApp. They all work as advertised.

     

     

    (MAPI, aka RPC Client Access, is the only supported CAS protocol/service for which we don't provide an advanced monitor at this time.)

     

     

    You are correct that SSL Bridging re-encrypts traffic before placing it back on the wire. However, it's important to understand how certs and keys are used.

     

     

    On the client side of the BIG-IP, the cert/key combination is supplied by the BIG-IP system (as if it was a server). A client -- for instance, a browser -- connects, checks the server [BIG-IP] certificate for authenticity, and then negotiates a secure connection using the server [BIG-IP] key. [This is a simplified description; see any number of TLS/SSl information sites for details about the full exchange.]

     

     

    On the server side, the BIG-IP is itself the' client' and, in this case, the CAS members are the servers. So the BIG-IP doesn't present a certificate and key (and therefore there's no need to select them); that's done by the server [CAS].

     

  • Hi Miller,

     

    Well then I have to check the new iApp for the synthetic monitors if it's working fine. Now coming to the SSL offloading and re-encryption just need more knowledge from you ...

     

     

    At first lets consider that there is no LTM in my setup and I have the SSL directly terminating on the server and everything works fine. Now after introducing LTM I have two choices either I offload SSL on LTM and change the SSL setting on the CAS servers that is it should not expect any more SSL traffic or I will leave the setting of SSL on CAS servers as it is so it will be working like the same that is SSL will terminate on it. In the second senario when nothing has been changed on the server part so I expect LTM to re-encrypt the connection received from the user using the same certificate and key combination. M I correct..... let me know if this is wrong what I have written.... if its correct then why should we not be choosing the certificate+key.

     

     

    Regards,