LTM, X-Forwarded-For, IIS and AD

Having the default gateway be the F5 isn't bad design. In many ways it's the (i.e. mine) preferred design... But that can all come down to how easy you want things to be, and how much of a support nightmare you want to experience.

 

 

The over-riding thing for support is consistency. Anything that is different on a server will cause a problem at some stage in the future. Whether it's simply because of unfamiliarity or tireness or something else.

 

 

My preferred solution is to have the F5 act as the gateway for everything to/from the backend servers. No other route onto those backend networks. Then you have a single point of control and monitoring to determine why things aren't working in the future...

 

 

Number two from me would be that SNAT is EVIL! Avoid it if you can... Why? Because lots of debugging requires the use of tcpdump (Or similar tools). Once you SNAT you can't filter on the client SRC ip any more. So if you have a large volume, in depth analysis of your traffic at the network level is now impossible... Especially if the traffic is encrypted... And there's not many apps that you can tell to log the X-Forwarded-For header instead of the tcp connection. And that will only work for HTTP... LDAP and many other protocols don't have a concept of telling the backend the REAL client IP address.

 

 

If you have a one-armed configuration, then you can still have the best of both worlds (i.e. No SNAT) if your backend servers (Or your network) will do advanced routing and route packets back via the F5 for only connections made to the poolmember IP:ports... Linux with IPTables is a great feature here (I also think AIX with routing by group is pretty good too).

 

 

H