Exchange 2010, Kemp and OS X
  • Hi,

    I have had a strange problem using KEMP LM's, Exchange 2010 and OS X 10.8. Every client configuration I have tried works, OWA, Outlook 2010/2003 and Outlook 2011 for Mac. The only one that refused to work is Mac Mail and the builtin Contacts and Calendar in OS X.

    I found the following solution which appears to work from the Apple Support forums: http://tinyurl.com/ce2282d

    It involves changing the service type to Generic and the Other server initiating protocols rather than HTTP/S and Normal protocols. It doesn't seem to affect any other service (OWA, ActiveSync etc.) that uses the same VIP on the KEMP.  Anyone else had this issue and could it cause problems with the recommended settings for the KEMP LM's and Exchange 2010?

    The issue I can see is that I can no longer configure the persistence options to Super HTTP and Source IP and I am sure this would cause issues from NAT'ed clients??

  • Hi Patso,
    Thanks for cross-posting this here! We have seen a few instances of similar issues with Mac clients and from the solution provided, it sounds like it might be the same issue we have observed. Without observing the traffic it would be impossible to know for sure, but I can offer the solution which has worked in the other situations and may work here.

    The issue we were able to identify is as follows: When LoadMaster operates at full Layer 7, requests sent to CAS servers can have two additional headers inserted automatically. These are the X-Forwarded-For and Via headers which inform the server the IP of the client and the IP address of the service respectively. The Via header is used by proxies to indicate to servers that there may be a hop in between. The presence of this header causes the CAS server to set the 'Persistent-Auth' header to 'false' — ordinarily this would be fine, it would simply require each request to be sent with credentials rather than once per connection. I believe there was a problem with the Mac Mail.app which wouldn't re-send the credentials.

    Side note: the reason the CAS servers behave differently when receiving the Via header is because some proxies perform TCP multiplexing and as a result, a single TCP connection could contain HTTPS requests from multiple clients. This would obviously be a security concern as unauthenticated users could potentially make requests. LoadMaster does not perform TCP multiplexing and as such is not vulnerable to this.

    Removing the Via header using a content rule seems to fix this issue. First create the rule, under Rules & Checking using these parameters:

    Rule Name: Remove_Via
    Rule Type: Delete Header
    Header to be deleted: Via

    Next navigate to your HTTPS virtual service, and select  'Show Header Rules' under 'Advanced Properties' and then add the Remove_Via rule to the Request Rules. This will add the header to all requests for the HTTPS service. Bear in mind that if you have already changed the service to Generic, you will need to change it back first.

    Post back and let us know if this is a solution!
  • Hi,

    I have implemented the Header Rule and all seems to be working fine. I have changed the service back to HTTP/HTTPS and the Persistence option back to Super HTTP and Source IP and MacMail and Address Book connect without the "SOAPWebServicesErrorDomain error -1".

    Thanks for the detailed description of the problem and a working solution.

  • Excellent! Glad that was the fix in this case. I've cross posted on the Apple forums to direct other people here.
  • Oh my; that really needs to get into the manuals or be added to the templates. I just spent 5 hours beating my head on that one; The above solution worked perfectly.

    Time to for someone to re-write a template for the an exchange 2010 port 443 rule; with 5 sub rules that does everything in one shot. That is what we wound up with in the end; and with the above fix it works great.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID