XFF and the ASM module

Hi Duncan,

The XFF should be added to the HTTP Request. Do you have an example HTTP Request being sent to ASM? You also need to enable "Trust XFF Header" on the ASM/Security policy.

Cheers,

Brett

When you say it should be added to the HTTP request, do you mean ticking the box for the XFF option on the LTM? We have done that and the iRule that is published on the site is also employed ... {Dont ask me, it was before my time)

Sorry by question, but, is the ASM blocking that traffic? If so, what is the violation triggered? I asked you because I have issues to some requests where LTM/ASM are injecting and breaking the http headers with NULL characters, so I need to know if you have the same issue that me.

Hi Duncan,

Where is the XFF being inserted, before the BIG-IP or at the BIG-IP? Your original question had: "The F5 receives traffic from a certain server that has already added an XFF on to the IP packet." So I took that to be the XFF was being inserted before the BIG-IP, therefore ASM needs to be told to trust the XFF.

Probably a good idea to log a support case.

Cheers,

Brett

Hi Brett

Topology

Internet users | Verisign server (takes Internet users IP add and adds first XFF) | BigIP (needs to accept above and add its own XFF or just accept it and pass it through to the back end financial monitoring package | Financial monitoring package | Backend database

The XFF is being added before the Big Ip and then we would like to add another XFF to the packet on the way through or allow it to just pass through.

What is happening is the financial monitoring package is only seeing the first XFF but not the Internet users IP add in the XFF

Here is an example of the header from the Verisign device heading to the BigIP

if you would uncheck the XFF option in the HTTP profile and remove the iRule which adds the XFF then you should be fine. then only the first one added is used.

Hi Boneyard .. thanks for the reply

If I uncheck AND remove the iRule, then the BigIP wont add any XFF to the existing (and soon to be passing through) header, will it?

.. and I need it to .. should I only remove one?

As I said the addition of the iRule was before my time and I dont want to take it off unless it is causing an issue or unnecessary.

No one can explain to me why we have both the checkbox AND the iRule

you say

"Verisign server (takes Internet users IP add and adds first XFF)"

two times on the BIG-IP is not needed, probably done by people who didn't understand the functions, but again it will take the used IP which might not be what you want.

@boneyard I understand what you are saying about is one XFF enough. But the client wants more than one added. It is possible and this is from the F5 docs.

Many servers and applications expect only a single X-Forwarded-For header, per request. However, the BIG-IP system appends a new X-Forwarded-For header to the existing set of HTTP headers, even if there is an existing X-Forwarded-For header in the request. Both approaches are valid according to the Internet Engineering Task Force (RFC2616, Section 4.2)

But the financial package is complaining because it is only seeing the ipaddress of the Verisign piece of kit, not the XFF header that includes the internet users address.

ok, now it is getting more clear. i wanted to see if i missed this originally but your question seems quite different at the start.

i tested with "Insert X-Forwarded-For" enabled on the HTTP profile and sending a request which already has a X-Forwarded-For header. in that case the BIG-IP nicely adds it's XFF header so there is two in the end.

if this is not the case with you then the iRule might be the issue. can you share that iRule here? perhaps satanize some stuff if it points back to your organization.

also if this works out like you want will depend on the financial package, as pointed out two (or more) XFF headers are allowed, but it will depend on the application to pick the first, last, ...

so still in my opinion there is little need to add the XFF header on the BIG-IP, but lets first see why you don't get two.