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?

Hello and thanks for giving the new iApp template a try. We haven't seen this particular error before -- where exactly are you seeing it? Before ever getting to the login page, or after logging in but before getting to the Mailbox view? Some things to check: Did you by any chance change the URI for reaching OWA (within the context of the iApp template)? The question immediately follows the one about if you're deploying OWA; you should really leave that at the default value -- we default that to "/owa/". Is your OWA pool actually listed as available (green) by BIG-IP LTM? If not, What type of monitors are you using -- simple or advanced? If using Advanced monitors, what Auth method are you using for OWA -- forms-based or Basic/Integrated? If forms-based (default), did you specify that correctly in the iApp template monitor section, and also follow the requirement to change the credential format on each CAS server from 'domain\username' to just 'username'? Lastly, did you remember to make the External URL for both Outlook Web App and Exchange Control Panel 'https:///owa' (where is your client-resolvable DNS name, of course) rather than 'https:///owa'? Let us know about these items and, if none of those are the culprit, we can suggest some further troubleshooting steps.

Thanks for the suggestions! Did you by any chance change the URI for reaching OWA (within the context of the iApp template)? The question immediately follows the one about if you're deploying OWA; you should really leave that at the default value -- we default that to "/owa/". This is still on the default. Is your OWA pool actually listed as available (green) by BIG-IP LTM? If not, What type of monitors are you using -- simple or advanced? It is set to simple and it all shows green in the monitors. If using Advanced monitors, what Auth method are you using for OWA -- forms-based or Basic/Integrated? If forms-based (default), did you specify that correctly in the iApp template monitor section, and also follow the requirement to change the credential format on each CAS server from 'domain\username' to just 'username'? This was set previously. Lastly, did you remember to make the External URL for both Outlook Web App and Exchange Control Panel 'https:///owa' (where is your client-resolvable DNS name, of course) rather than 'https:///owa'? These kinda look the same.... ;) They are set to https://mail.whatever.com/owa. Any other thoughts? Thanks!!!

Sorry for the confusion about the URLs -- this forum stripped the example names I had in the URLs because I had encased them in left and right angle-brackets and it thought they were HTML. When your browser gives you the error, what's the URI in your browser location bar? Is it just https://mail.whatever.com/owa, or do you have something like https://mail.whatever.com/owa/auth/logon.aspx followed by possibly some other values? Do you have HTTPwatch or Firebug or something similar available to you? We'd like to see what the actual error message is (for example, 401 Not Found, or whatever it happens to be) rather than the "friendly" message provided by your browser. What about SNAT settings and routing? (which are controlled by the topology questions about where your BIG-IP and actual servers are in relationship to one another? How did you answer those? Is your Windows firewall on the CAS servers enabled (any of the Domain, Public or Private profiles)? Can you try an Advanced monitor instead, using a real mailbox login? This will give us some additional information based on whether that works or not. I know we're fishing a bit, but we so far seem to be missing some piece of information that will point us towards a solution.

Thanks again! When your browser gives you the error, what's the URI in your browser location bar? Is it just https://mail.whatever.com/owa, or do you have something like https://mail.whatever.com/owa/auth/logon.aspx followed by possibly some other values? It's whatever I type in. It doesn't change to the OWA URI or any other URI. Do you have HTTPwatch or Firebug or something similar available to you? We'd like to see what the actual error message is (for example, 401 Not Found, or whatever it happens to be) rather than the "friendly" message provided by your browser. I don't, unfortunately. What about SNAT settings and routing? (which are controlled by the topology questions about where your BIG-IP and actual servers are in relationship to one another? How did you answer those? Primary connections are LAN based. And the CAS boxes are on the same subnet as the F5. Is your Windows firewall on the CAS servers enabled (any of the Domain, Public or Private profiles)? Nope. All off. Can you try an Advanced monitor instead, using a real mailbox login? This will give us some additional information based on whether that works or not. Green monitors across the board, minus Exchange_2010_combined_http, as it shows Unknown.

It sounds like, for whatever reason, the request is not getting to the server (or not returning properly), since you should receive a redirect. I'm sending you a private message via your DevCentral Inbox in just a few minutes with some additional questions. If whatever we discover is relevant to a larger audience (bug, configuration error, or something else that is not unique to just this one instance) we'll post the eventual solution here.

New iApp, Exchange 2010 and SSL bridging

Techgeeeg
Nimbostratus
Apr 27, 2012
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
Historic F5 Account
Apr 27, 2012
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.
Techgeeeg
Nimbostratus
Apr 27, 2012
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
Historic F5 Account
Apr 27, 2012
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].
Techgeeeg
Nimbostratus
Apr 27, 2012
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,

Forum Discussion

New iApp, Exchange 2010 and SSL bridging

Recent Discussions

self-directed requests fail because of no certificate

Decode ObjectSID from Base64-encode string

iRule - Url rewrite and header replace and pool selection not working

ip x-forwarding

F5 ASM API-Protection Policy

Related Content

SSL Bridging verification

Leaks & breaches, memory-safe C++, cryptominers and bridging the air-gap

Spring4shell iApp

Understanding iApps

Integrating SSL Orchestrator with CheckPoint Firewall VM-Bridge Mode (L2)

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS