Forum Discussion

Matt_64640's avatar
Matt_64640
Icon for Nimbostratus rankNimbostratus
Oct 01, 2009

Help with client IP filtering and SNAT

Here's the background: My F5 is at version 9.4.6.

 

 

I have a publicly published website which resolves to an IP of a virtual server setup on my F5 and which is listening for traffic on 443. That passes traffic off to an ISA 2004 array which has a web-publishing rule on it, with the intent to setup an SSL session between the requesting external system and the ISA 2004 server. Once that's established, the ISA2004 server connects to an internal webserver (reverse proxy setup).

 

 

If I don't use SNAT on the F5, the ISA server sees the client IP address (the F5 just forwards the traffic), but can't establish the SSL connection with the client because the client knows it's request went into one address, and is coming back from a different IP address. If I use SNAT, the traffic goes into and comes back from the F5 (the ISA sees the traffic as originating from the F5), and the SSL session between the external client and the ISA server is established without issue.

 

 

My problem is that I'd like to restrict the access to specific external client IP addresses. I thought I could do this at the F5 by using an iRule to match the client IP to an entry in a datagroup. To test this, I created a datagroup and the following iRule:

 

 

when CLIENT_ACCEPTED {

 

if { not [matchclass [IP::remote_addr] equals $::mySite_accessGroup] } {

 

log local0. "[IP::remote_addr] Does not Match IP check."}

 

}

 

 

The problem I'm seeing is that in the logs, it looks like the traffic is already SNATed at this point, so the only IP I see listed in the log is the F5's self-ip for my external VLAN.

 

 

Did I miss something or does anyone have any suggestions? I'm kind of new to F5s, and I'd appreciate any assistance.

 

 

7 Replies

  • I am not sure if this helps but did you try [IP::client_addr] instead of [IP::remote_addr]?

     

     

    CB

     

  • IP::client_addr and IP::remote_addr will return the same value in clientside events.

     

     

    Any SNAT configuration is applied after CLIENT_ACCEPTED, so the SNAT configuration shouldn't affect your iRule. Are you sure the log statement is showing the LTM self IP address? I'm not sure how that could happen.

     

     

    Aaron
  • Okay, figured out what I was doing wrong. What I was seeing was not the self IP of the LTM, but the connection from the GTM health monitor. What I wasn't seeing was the external connection, and that was because it wasn't getting there (firewall issue upchannel from my F5). Now that the firewall issue's been resolved, I can see the external IPs connecting, which means I can move on to setting the restrictions.

     

     

    Once you guys pointed out that the iRule at least should have been right, and that the snat takes place after the CLIENT_ACCEPTED event, I could figure out where to look for the problem.
  • I'd like to use this same logic to setup a "whitelist" of clients that are allowed to connect to a virtual server that load balances smtp servers for sending outbound email. Due to SNAT the smtp servers won't see the true client ip so the whitelisting can't be done there.

     

     

    Once I have specified authorized smtp clients using the logic of this irule what are the commands to allow use of the virtual server if in the datagroup and not allow otherwise?

     

     

    thanks,

     

     

    Mark
  • Hi Mark,

    You could use drop (Click here) or reject (Click here) for client IP addresses which don't match your allow list.

     
     when CLIENT_ACCEPTED { 
      
         Check if client is not in the allowed_clients_class datagroup 
        if { not ([matchclass [IP::client_addr] equals allowed_clients_class])}{ 
      
            Drop the connection 
           drop 
        } 
     } 
     

    Aaron