IP address and domain name restrictions in IIS

Hi,

 

 

Are you performing/do you need to perform source address translation on the BIG-IP? If not, you can configure the BIG-IP to not translate source addresses on requests sent to the pool. This requires that the servers have a route back to the client through the BIG-IP. This would typically be done by setting the default gateway of the servers to the BIG-IP's floating self IP on the server VLAN.

 

 

If you do need to perform source address translation for symmetric routing, the simplest method for passing details about the original client IP address is by inserting a custom HTTP header with the original client IP address. You can do this on the HTTP profile. But if you're using the value for authentication, it would be much more secure to use an iRule to remove all instances of the header and then insert a new header. The application would need to parse this custom HTTP header to get the client IP address. I'm not sure you can configure a default IIS installation to parse the header for authentication purposes though.

 

 

Another option would be to implement the IP address / host name checking in an iRule on the BIG-IP. It would be relatively straightforward to write a rule which does IP / host / URI validation before sending requests to the pool. There are quite a few examples of this in the iRule forum.

 

 

If you have questions on these options, let us know. If you pick one option and want help setting it up we can provide examples.

 

 

Aaron

Hi Aaron,

 

 

Yes I am doing source address translation. Looks like i need some assistance with either a custom HTTP header or with an iRule.

 

 

Thanks for your help.

You can remove all existing XFF headers and insert a new value using this iRule:

  
 when HTTP_REQUEST {  
    
     Remove all XFF headers, if present 
    while {[HTTP::header exists X-Forwarded-For]}{  
  
        Log a debug message for deleting the current XFF header  
       log local0. "Removing XFF: [HTTP::header value X-Forwarded-For]"  
    
        Remove the current XFF header  
       HTTP::header remove X-Forwarded-For  
    }  
     Now that no XFF headers exist, insert a new one  
    HTTP::header insert X-Forwarded-For [IP::client_addr]  
 } 
 

This will ensure that only the BIG-IP XFF value is included in requests sent to the server. You'll need to parse the XFF header value to get the original IP address the BIG-IP received.

Aaron

Hi Aaron,

 

 

I had to make some changes to the script as it waould not compile, just minor adjustments addedd or removed brackets. Can you confirm that what i have done is correct please?

 

 

when HTTP_REQUEST {

 

 

Check if there are any XFF headers

 

if {[HTTP::header exists X-Forwarded-For]}{

 

 

Log a debug message for deleting the current XFF header

 

log local0. "Removing XFF: [HTTP::header value X-Forwarded-For]"

 

 

Remove the current XFF header

 

HTTP::header remove X-Forwarded-For

 

}

 

Now that no XFF headers exist, insert a new one

 

HTTP::header insert X-Forwarded-For value [IP::client_addr] ]

 

}

 

 

However, if the script is correct it still isn't working as I cannot get the IP restrictions to work. My configuration is as follows: I have a VIP defined with two Microsoft IIS 6 webservers being load balanced with SNAT in the DMZ, rather a simple configuration. I also have x-forwarded-for installed as an ISAPI on the web servers for client address logging and it is working. I have a workstation on the inside network (private address) connecting via HTTP to the VIP address without any issues but as soon as i try to restrict access to the web site by denying all except certain addresses (address of the workstation) I get the usual 403 error message in the browser of the workstation.

 

 

Thanks

 

 

David

Hi David,

 

 

Sorry, I had a couple of typos and a logic error in the example I posted. I changed the 'if' to 'while' and removed a couple of extraneous braces. The edited version above should work (Click here) for removing any existing XFF headers and inserting a new one.

 

 

The caveat to this approach is that I don't think the DLL posted on Devcentral to log the XFF value will allow IIS to parse the XFF header value for authentication. I think the DLL only affects logging. I was suggesting that you might need to implement the authentication in the application. Or perhaps there is an existing DLL (or one you could create) which parses the XFF header value for authentication. However, I don't think IIS parses the HTTP headers before it checks the source IP address for authentication.

 

 

If you want to use IIS IP-based authentication, I think you'll need to disable SNAT and set the default gateway on the IIS servers to the BIG-IP. If that's not an option, you could either implement the authentication within the application or on the BIG-IP using an iRule and datagroups. The last approach could be relatively simple. You'd need to create an address datagroup containing your allowed hosts/networks. You could also create a datagroup which lists allowed paths. Then in the HTTP_REQUEST event, you could check whether the client IP matches the hosts/networks datagroup and that the requested path is allowed.

 

 

Aaron

Hi Aaron,

 

 

I'm afraid it still isn't working even after applying the modified iRule. From what i can gather is once you hit the VIP it passes the request onto the floating IP address and then onto the web servers as this is configured for high availabilty with two f5's (active/standby). The only address that IIS can see is the floating address from the f5.

 

Ignore the austhentication issue as I'm not concerned about authentication from an IIS perspective as the application will handle that but as i've mentioned i would like to restrict access to the web servers only from certain trusted sources.

 

 

David

Sorry for any confusion. By authentication, I mean validating the client (whether that's by IP address or username, etc). In other words, I don't think you'll be able to use SNAT and IIS's IP address ACL functionality together.

 

 

Aaron

Hi David

 

Did you ever get a solution to this problem?

 

I have a similar setup - two F5 boxes sitting on one VLAN along with all of the nodes(same subnet). I have tried the x-forward method but this only works for the log file and does not help.

 

 

Aaron

 

If I disable SNAT then the VS do not work. The F5 is not the default gateway for the nodes (that is the firewall) as they need outbound access.

 

Is there any way around this without creating additional subnets/vlans and swtiching off SNAT?

 

Can the F5 itself do the IP validation on a particular URL (move it from IIS to the F5)?

 

 

 

Regards,

 

Jon

Hi Jon,

 

 

Unfortunately no i haven't resolved this problem i'm having to work around it. Let me say how dissapointed i am with the fact that you just cannot seem to do simple things like being able to log source address without having to find third party tools and the like. I have worked with other load balancing units in the past that allowed you to do these sorts of things without having to rely on someone else writing additional software to install. For a unit (or two) that cost around 30-40k each and not being able to do simple thing like these is very dissapointing or maybe i'm just missing something.

 

 

Sorry i cannot help.

 

 

David

Hi David,

 

 

The BIG-IP allows you to insert a custom HTTP header (X-Forwarded-For) with the original source IP address with a single click of the button. As it was being used for access control, I gave a suggestion of using an iRule to ensure that only the BIG-IP's header is passed on. Of course, depending on which web server platform you're using, you need to configure the web server to do something with that custom HTTP header. To log the value with Apache, it's a matter of changing a configuration option. In IIS, you need to use an ISAPI filter--which F5 provides. For access control, it's not so easy as the ACL is probably done before the HTTP headers are parsed.

 

 

You can definitely enforce an ACL based on requested URI and/or source IP address on the BIG-IP using an iRule and a couple of datagroups. There are a few examples in the Codeshare and a lot of forum posts with examples.

 

 

Short of having an option to automatically removing all existing XFF headers before inserting a new one, I don't think it would be possible for another load balancer to handle this scenario better. All BIG-IP and any other load balancer is doing in this scenario is changing the source IP address. How would another load balancer not require changes to the server in order to use the header?

 

 

Aaron

 

 

Aaron