A newbie basic question

Does this not help? http://www.f5.com/pdf/deployment-guides/f5-sharepoint-2010-dg.pdf

The deployment guide is a good place to start, but I'd add a few things:

1. DNS should just be pointing clients to the F5 VIP for SharePoint access.

    

2. Alternate Access Mappings can actually be dealt with in two ways: AAM settings in SharePoint, or HTTP Host header iRules applied to the F5 VIP. I personally prefer the former.

    

3. The deployment guide doesn't mention Kerberos, so you'll either need the Access Policy Manager (APM) module to do client side and server side Kerberos authentication, or you'll need the VIP FQDN to match the SPN of the Kerberos resources behind the F5 (with just LTM). Not sure which direction you're going here, so I won't dive into the specifics of either.

    

Wholeheartedly agree with blwavg's iApp suggestion here. It's a good place to start, to get the application working with the F5, and then go back later and try to figure out what it did.

Ultimately though, you'll dealing with a proxy layer. Instead of contacting the SharePoint server directly, clients will contact a virtual server on the F5, which will then proxy and load balance these requests to the SharePoint services. And with any proxy environment, there may be implications to address. The proxy in this case presents a "virtual" representation of the application, so its name is necessarily different. For SharePoint, that means managing AAM settings to match this virtual service name. If you're doing any form of authentication at the web server, then you must also take that into consideration. For Kerberos specifically, the name/SPN is critical, so the SPN of the service that the client requests access to from its local KDC must match the SPN of the services behind the proxy, so that the service can decrypt and use the Kerberos ticket (unless you're using APM).

Here's a very basic rundown of any F5 proxy configuration:

1. A pool that points to the SharePoint servers by IP and port.

    

2. A virtual server that represents the application to the client, and that sends client requests to the pool.

    

   This is the absolutely bare bones requirement of any F5 proxy configuration - a VIP and a pool. You can then add "services" on top of that configuration to affect different elements of the traffic:

    

3. An HTTP Profile, bound to the virtual server configuration that allows the VIP to evaluate HTTP requests and responses in an iRule.

    

4. An iRule (or several) that can evaluate/read/write/delete/change any aspect of the client/server HTTP dialog.

    

5. A SNAT Profile, short for "Secure NAT", changes the client's source address to a locally-managed address to force return routing through the F5. This isn't expressly required in all environments, but makes most deployments much easier to manage.

    

6. A client SSL Profile that can terminate and offload client side SSL (ie. HTTPS traffic).

    

7. An optional server SSL profile that can re-encrypt to the back end web servers (as required).

    

8. Any number of other protocol-specific profiles, as required.

    

If you can, temporarily, disable Kerberos authentication (set to anonymous) for a single SharePoint server, the iApp and/or deployment guide should get you to a point where you're passing traffic from the client, through the proxy, to the SharePoint server. From there you'll need to customize AAM settings (or implement an iRule to change the Host headers to trick AAM), and then work on the authentication requirements.

Thanks for everyones help.