Forum Discussion
Alternative to getfield to check XFF client IP using data group
Hi All,
Can anyone please help resolve this? I have tried the recommendation that Kevin suggested, however I am not sure if I am doing it correctly as it does not seem to work.
Here is the old code that was working on 12.x code, but after upgrading to 13.x, it no longer works...
F5, can you help with this here? How to change this so with version 13.x it is able to look/compare the client XFF IP against the data group and allow/deny/redirect based on that..
**** Original code with getfield that looks at the client IP address in the XFF header, if it does not match the IP address listed in the "DG-ALLOWED-IP" data group, and the user tries to access the URIs listed in the "DG-ALLOWED-URI-LIST", they will get dropped...The switch command is also used for access and redirect based on the match in the "DG-ALLOWED-IP" data group..
when HTTP_REQUEST {
if { [active_members POOL-WEBSERVERS] < 1 } {
HTTP::redirect " http://maintenance.mysite.com"
} else {
set CHECK_IP [getfield [HTTP::header values X-Forwarded-For] " " 1]
if { !([class match $CHECK_IP eq DG-ALLOWED-IP]) } {
if { [class match [HTTP::uri] eq DG-ALLOWED-URI-LIST] } {
reject
}
}
switch -glob [HTTP::uri] {
"*/abc/portal1/idtrack*" -
"*/cde/portal2/idtrack2*" -
"*/fgh/abc/portal3/idtrack*" {
if { ([class match $CHECK_IP eq DG-ALLOWED-IP]) } {
if { [HTTP::uri] contains "/public/idtracker" } {
HTTP::redirect "https://[HTTP::host]/secure/idtracker"
} else {
HTTP::redirect "https://[HTTP::host]/login2/public/idtracker/"
}
}
}
}
}
}
- Simon_BlakelyJul 02, 2020Employee
First - did you try the irule I provided, or try the proc provided?
Two - if this occurred as a result of an upgrade, you could raise a support ticket with F5.
Three - try some logging statements to determine where the error is occurring:
when HTTP_REQUEST { if { [active_members POOL-WEBSERVERS] < 1 } { HTTP::redirect " http://maintenance.mysite.com" } else { set CHECK_IP [getfield [HTTP::header values X-Forwarded-For] " " 1] log local0. "the X-Forwarded-For header value is $CHECK_IP" if { !([class match $CHECK_IP eq DG-ALLOWED-IP]) } { if { [class match [HTTP::uri] eq DG-ALLOWED-URI-LIST] } { reject } } switch -glob [HTTP::uri] { "*/abc/portal1/idtrack*" - "*/cde/portal2/idtrack2*" - "*/fgh/abc/portal3/idtrack*" { if { ([class match $CHECK_IP eq DG-ALLOWED-IP]) } { if { [HTTP::uri] contains "/public/idtracker" } { HTTP::redirect "https://[HTTP::host]/secure/idtracker" } else { HTTP::redirect "https://[HTTP::host]/login2/public/idtracker/" } } } } } }
On the BigIP, run
# tail -f /var/log/ltm | grep "the X-Forwarded-For header value is"
to see the logged lines from the irule.
Either you are getting an IP address with a leading "{" that needs to be removed, or Check_IP is empty - both will cause the IP address validation failure.
Use irule logging to determine which one it is.
- ant77Jul 07, 2020Cirrostratus
Hi Simon,
Sorry for the delay in replying. I tried your irule and it works perfectly. For some reason, after the upgrade, the F5 would not read the original "getfiled" irule correctly and would add a "," (comma) after the XFF client IP. This caused the iRule to not see the IP correct and the function would stop working.
I added the following to the iRule and check the LTM logs and now the IP is without a comma and doing what it is supposed to.
Added your portion to my original IRule.
set CHECK_IP [lindex [lsearch -all -inline -not -exact [split [HTTP::header values X-Forwarded-For] "\{\} ,"] {}] 0]
Thanks again!
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com