x-forwarded-for with IIS 6 Page IP Filtering

XFF is an HTTP header value (layer 7), where your web servers are probably filtering on the actual layer source addresses. You can certainly configure an IIS box to evaluate an XFF value though:

https://devcentral.f5.com/articles/iis-x-forward-for-isapi-filter.UvJRDrRs2qs

Alternatively, if you don't need to apply SNAT (secure network address translation) at the VIP, then the client source should make its way to the web server directly.

Everything Kevin mentions is correct. One additional note is that if you move to IIS 7 or higher (I know your question here is about IIS 6), it's probably better to use Microsoft's Advanced Logging feature, rather than F5's ISAPI plugin.

You can find instructions for using that starting on page 28 of the guide at https://www.f5.com/pdf/deployment-guides/iapp-microsoft-iis-dg.pdf

Again, that's only for IIS starting at version 7. For version 6, stick with the link provided by Kevin.

I don't care about the logging. I'm interested only in this (see attached image)

The short answer to your original question is no. An XFF header is an HTTP object. The IP address and domain name restrictions option in IIS will only see the client source address in the TCP payload, not an HTTP header. If you need the client source address at the IIS server for the purpose of using this feature, then you must not enable SNAT in the virtual server. SNAT translates the client source to a local source to force return routing. In the absence of SNAT you must ensure that the servers cannot directly route back through the BIG-IP (not around it).

Alright, thanks Kevin.

Kevin,

Could you expand on what you mean by this?

"In the absence of SNAT you must ensure that the servers cannot directly route back through the BIG-IP (not around it)."

we disabled SNAT, and nothing could reach on http or https

If you disable SNAT the nodes may not be able to send the response to the client.

Kevin and I just chatted about this. He meant his post to say "In the absence of SNAT you must ensure that the servers cannot route around the BIG-IP".

SNAT is pretty simple; it just replaces the original source IP address with an IP address that is assigned to the BIG-IP and [usually] on the same subnet as the target servers. The servers thus don't see the original IP, and therefore don't need any routing information about how to get a return packet to the client. Instead, they just send it "locally" to the SNAT address that BIG-IP used to replace the original. When BIG-IP sees the return packet, it replaces the original source IP as the new destination, replaces the server Ip address with that of the original target BIG-IP virtual server, and sends the packet on its way.

Since the source IP address has been replaced when the packets hit the web servers, IP-level filtering won't be effective, since everything will just look like it comes from the BIG-IP.

Without SNAT, servers will try to return a packet using whatever routing information they have. The default gateway and/or network-specific routes on servers are unlikely to be through the BIG-IP (unless you've specifically configured them that way), and are more likely to be through some router or firewall elsewhere on the network. The original client, or even an intervening firewall, will see a mis-match between the original packet (source: client; destination: a BIG-IP virtual server address) and the reply (source: a server IP address; destination: the client) and will drop the packet.

With SNAT, the packets would match:

1: (source: client; destination: a BIG-IP virtual server address)

2: reply (source: BIG-IP virtual server address; destination: the client) and will drop the packet.

There's a good article on SNAT here: http://www.wtit.com/what-is-snat-in-f5-load-balancing-snat-vs-inline-what-is-nat/