THE INFORMATION IN THIS ARTICLE APPLIES TO:
EFT v8.0 and later store Advanced Properties in a JSON file. When you upgrade to EFT v8, the non-default settings that you have defined in the registry will be added to the Advanced Properties file during upgrade. (Default settings become part of the EFT configuration files.) For a more on how to use advanced properties, and a spreadsheet of the advanced properties, please refer to the "Advanced Properties" topic in the help for your version of EFT.
DISCUSSION
Note: This is a high risk and controversial override that is considered experimental only. Use at your own risk!
If you are behind a trusted proxy or load balancer that always injects the real client IP into the X-Forwarded-For (XFF) header and you want EFT to use the XFF value over the connection defined IP, then you will want to create this key. When enabled, EFT will audit, log, and perform operations based on the XFF provided value (including IP ban logic!) Note that EFT’s default behavior is to completely ignore any XFF header supplied value as those values can easily be spoofed by client. You should only enable this advanced property if you completely trust the device(s) on the network closest to EFT that you know with certainty will inject the true client IP into the XFF header. If you are not 100% certain then do not create this key!
In EFT v8 and later:
Add the name:value pair to the AdvancedProperties.JSON file in EFT's \ProgramData\ directory as described in the "Advanced Properties" topic in the online help for your version of EFT.
{
"ForwardedForHeader": X-Forwarded-For, Forwarded, X-Forwarded-Host, or a custom value
}
In versions prior to v8.0:
Key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\GlobalSCAPE Inc.\EFT Server 7.2\ForwardedForHeader
Name: ForwardedForHeader
Type: STRING
Value name: X-Forwarded-For, Forwarded, X-Forwarded-Host, or a custom value
Default Value: Empty (if Empty then it is treated as if the key was not present).
EFT service restart required? Yes
Q. Why is this a string rather than a true/false (Boolean)?
A. The reason for this is that in a few rare instances customers rely on custom headers other than the XFF standard. This key allows customers to supply the custom header name they want, although we recommend sticking with X-Forwarded-For for most proxies and load balancers, including Azure and AWS elastic load balancers.
Q. What happens if an empty string is applied?
A. In that case EFT defaults to its standard behavior (use connection derived IP)
Q. What happens if EFT cannot find the header that was defined?
A. In that case EFT defaults to its standard behavior (use connection derived IP)
Q. If the XFF header contains multiple IPs, comma delimited, what happens?
A. EFT does not support multiple entries and this may result in some odd logging and operational behavior.
Q. Can I supply multiple IPs via the XFF, comma delimited?
A. Not presently and this will result in some odd logging and operational behavior
Q. Can I supply an IPv6 IPs via the XFF?
A. This should work but has not yet (as of March 2019) been tested, given this feature is both experimental and risky.
Q. What if no string or garbage strings arrive via the XFF header?
A. This is why you should never use this key unless you are certain your LB or proxy will be supplying a valid IP in the XFF header. EFT will audit the garbage data but will not be able to ban the real client IP.
