Checking for X-Forwarded-For against an Address Data-Group
Hello, I've been back and forth over this simple block of code, extracted from our f5 rule. I'm trying to adjust to Cloudflare X-Forwarded-For header for handling source IP address comparison to an internal list of credible internal IP ranges. While I understand that the "X-Forwarded-For" header is not 100% reliable, having this value set will aid debugging in other respects. When I call this f5 irule with no headers, it is fine, it appears to use the client_addr normally against our whitelist address Data Groups (very simple list of allowed ranges). But when I call it with a header of X-Forwarded-For via Postman it does not respond at all to the client (fails hard). I thought all Tcl variables are Tcl String, but is there something I need to convert extra for headers? -value on the header did not help either. when HTTP_REQUEST { if {[HTTP::header exists "X-Forwarded-For"]}{ set ip [HTTP::header "X-Forwarded-For"] } else { set ip [IP::client_addr] } set externalHost 1 if {[class match $ip equals Internal_Hosts]}{ set externalHost 0 } if {($externalHost == 0)}{ HTTP::respond 200 content { externalHost=0 } } elseif {($externalHost == 1)}{ HTTP::respond 200 content { externalHost=1 } } else { HTTP::respond 200 content { externalHost=unknown } }
HTTP x-forward-for
Hi all, I have configured the x-forward-for virtual server as below. <vitual server> type : standard protocol : tcp Source Address Translation : Automap HTTP Profile : Added profile with 'Insert X-Forwarded-For' enabled The symptoms are as follows. 1) Configure the service port of the virtual server to 80 or 8080. - BIG-IP recognizes the port as http and adds the Client IP to the header. 2) Configure the service port of the virtual server to 11211. - BIG-IP recognizes the port as TCP and does not operate X-forward-for. I have a few questions. Q1) For X-forward-for to operate, does the HTTP well-known(80,8080) port that BIG-IP knows must be configured as a service port? Q2) Is there a way to make X-forward-for work by configuring unknown-port on the service port? Q3) Are there any other service ports that F5 recognizes with HTTP other than 80,8080? Thanks,
iRule - XFF different case based on direction
I have an issue with Bitbucket versions where XFF is sent differently depending on the direction of traffic between versions. I am sure other apps have this issue as well. Bitbucket versions ( v7.2.5 --> v8.19.3 ) Can the XFF type case-sensitivity be controlled based on direction. (Right side is a mixed up standard and all upper-case versus the left side is all lower-case.xff and geolocation
If I want to create a dos l7 profile that needs to check the xff header as the source address (I will add an http+xff profile), and I want to exclude a country from the dosL7 policy using an LTM policy - can this be done with XFF? can the ltm policy recognise xff addresses' geolocations? If not with ltm policy, can this be done with an irule? thanks, Vered
iRule - Fallback Persistence
Hi - I'm trying to create an iRule for the Persistence Profile of one of my applications. The preferred method is to use cookie - the application actually injects a cookie in the HTTP RESPONSE and the F5 looks for this cookie in both the HTTP RESPONSE and HTTP REQUEST to do persistence, identical to how JSESSIONID works. However in the event that the client has configured their browser to reject / disable cookies, the expectation is that we persist based on their source IP, however as they come in to our data centre via Akamai, we actually need to extract their IP from the X-Forwarded-For header. What I came up for this was: when HTTP_REQUEST { if { [HTTP::cookie exists "App_SessionId"] } { persist uie [HTTP::cookie "App_SessionId"] 1800 } else if {[HTTP::header X-Forwarded-For] != ""} { persist uie [lindex [ split [lindex [HTTP::header values X-Forwarded-For] 0] "," ] 0] 1800 } else { persist uie [IP::client_addr] 1800 } } when HTTP_RESPONSE { if { [HTTP::cookie exists "App_SessionId"] } { persist add uie [HTTP::cookie "App_SessionId"] 1800 } } I haven't had the chance to test this but reviewing the logic I see that we may have a problem with the first request cominf from the user's browser. When a user first lands on the website, the HTTP_REQUEST from their browser will not have the App_SessionId cookie and this causes the LTM to add a persistence record based on the X-Forwarded-For header, or add a persistence record based on the user's source IP address. When the request makes it to the server and the server responds ( HTTP_RESPONSE ), that response will have a App_SessionId cookie, and the LTM adds another persistence record based on this cookie. Then the subsequent HTTP_REQUEST from the users browser will have the App_SessionId cookie, and this will now match the if { [HTTP::cookie exists "App_SessionId"] } section of the iRule and they will be persisted to the same server that inserted the cookie. This is good but there's the loose end which is the initial persistence record based on the X-Forwarded-For header that's lingering. Would this lingering persistence record based on the X-Forwarded-For header cause a conflict with the persistence record based on the App_SessionId cookie? How do I clean up this loose end? On the flip side, if the user had configured their browser to reject cookies, the persistence record based on the X-Forwarded-For header is vital to maintain session consistency. But now we have the loose end of the persist add uie [HTTP::cookie "App_SessionId"] 3600 in the HTTP_RESPONSE .BIG-IP : http profile : insert x-forwarded-for : enabled
F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi HTTP Profile Insert X-Forwarded-For : Enabled Suppose the client has already added the "X-Forwarded-For" header value to the request. How will BIG-IP behave ? Will it leave the existing header value intact ? Or will it overwrite the value with what it believes to be the request client ip ? Further, at what point in request-processing does the insert/replace header operation occur ? Does it occur before iRule processing so that the header value is available within the iRule event processing when HTTP_REQUEST {} ?BIG-IP : HTTP Profile Insert X-Forwarded-For Enabled but not found in request headers collection
F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi For a Virtual-Server assigned an HTTP Profile configured with : Insert X-Forwarded-For Enabled under what circumstances would the header not be inserted ? My iRule logs : when HTTP_REQUEST { log local0. "X-Forwarded-For header = [HTTP::header X-Forwarded-For]" ` indicate header is not present -- here is log output : `X-Forwarded-For header = Could disabling HTTP_REQUEST event at end of iRule affect HTTP Profile ability to add the header ?
X-Forwarded-For header
Hi All, My application team requirement is to able to see the actual client ip address whoever accessing the application instead of BIG IP address as SNAT (Auto map) is enabled. I have read some SOL on it and understand that we can achieve this by iRule & HTTP profile. However, my requirement is to have an iRule as we can take decision whether to add X-Forwarded-For header to client requests. Can anyone please share the iRule script pertaining to this requirement. Thanks in advance, MSK
