Hello!
We are planning to use ssl off-loading on our F5. However, this was not appreciated by our security team since this would allow a user to browse to the sever on port 80 and logon to the mailbox without any encryption. Is there a way to prevent this so we
can force the users traffic through the loadbalancer?

Brian

There is an amazing pack of free network admin tools. click here to download it

Connection restrictions in IIS. Although you will only be able to block the traffic, not redirect it.
Also you will need to include the Exchange servers in the list of allowed connections as the servers like to talk to each other and some internal processes will go over http ports.

Simon.Simon Butler, Exchange MVP
Blog |
Exchange Resources | In the UK?

Hire Me.

There is an amazing pack of free network admin tools. click here to download it

Hello
You have the option of re-encrypting the traffic on the F5 before delivering it back to the Exchange servers. Please have a look at the F5 Deployment guide for Exchange

http://www.f5.com/pdf/deployment-guides/f5-exchange-2010-dg.pdf
. We didn't have this requirement in our organization when deployment but I had tested it out in our lab and
it worked without issued.Jason Apt Microsoft Certified Master | Exchange 2010

Need to support users over the internet? click here try our remote control online beta

If we re-encrypt the traffic, can we still use ssl-offloading then?

Need to support users over the internet? click here try our remote control online beta

It doesn't sound much like off-loading at that point does it? :)
So you utilize the SSL-Offloading setting on the F5 to unencrypt the traffic and then have F5 re-encrypt the traffic before sending it to the CAS array. The CAS array will still have to unencrypt the traffic.
From a performance gain stand-point, you don't gain anything from this so you aren't really off-loading.

If your security team is concerned, are they concerned about difference security standards or certifications being met (outside of being able to get to mailbox data on port 80)? I can't really agree with their concern and I know that SSL-Offloading
meets PCI, HIPAA, FISMA, etc. standards. The traffic is also on the internal network at this point (and possibly on its own subnet behind the F5) so how many users have access AND knowledge to get at the traffic?Jason Apt Microsoft Certified Master | Exchange 2010

There is an amazing pack of free network admin tools. click here to download it

thanks for mentioning the standards. Good ammo for further discussions :)

Need to support users over the internet? click here try our remote control online beta

Brian,
Let me know if I have the concern summarized correctly.... The BIG-IP is decrypting the SSL/TLS and sending the traffic to the CAS servers unencrypted (over port 80). The concern is that this will allow the clients to just use uncencrypted port 80 to connect,
without ever encrypting the traffic.

You can easily configure the BIG-IP to not allow port 80 traffic on the client side. Just don't create a port 80 VIP. A more sophisticated solution would be to actually create a port 80 VIP that points to the "https redirect iRule" that ships with the
BIG-IP. In that case, if a client does connect unencrypted and over port 80, the BIG-IP will just send them a 302 redirect to the same URL/URI but over SSL this time.

-Ryan (F5)

There is an amazing pack of free network admin tools. click here to download it

Hi,
the concern from the security team was the possibility to access the server directly on the server fwdn/owa on port 80. Not sure if this is a problem anymore since when you access the server directly using the server
http://fqdn/owa exchange seems to redirect you to https anyway?
But regarding the F5 configuration i will have the F5 guys to redirect port 80 to 443 using the iRule you mentioned.

Thanks,
Brian

There is an amazing pack of free network admin tools. click here to download it

Brian,
One popular option is to put the CAS servers behind the BIG-IP, therefor clients do not have the ability to connect directly to the CAS servers. In this type of deployment, clients are forced to connect through the BIG-IP, which can block or redirect all
incoming connections over port 80. BIG-IP just recieved its ICSA firewall certification, so this architecture adds to the overall security of the deployment.

There is an amazing pack of free network admin tools. click here to download it

Brian,
One popular option is to put the CAS servers behind the BIG-IP, therefor clients do not have the ability to connect directly to the CAS servers. In this type of deployment, clients are forced to connect through the BIG-IP, which can block or redirect all
incoming connections over port 80. BIG-IP just recieved its ICSA firewall certification, so this architecture adds to the overall security of the deployment.

There is an amazing pack of free network admin tools. click here to download it