Options
Http Proxy adding X-Forward-For header
Hello,
I would like to know if somebody already made a configuration to add X-Forward-For header identifying the originating IP address of a client connection.
My need is to propagate to the website behind the XTM 330 the caller IP address.
Thanks!
Rogerio Wagner
0
Sign In to comment.
Comments
Hi @RogerioWagner
The firewall won't generally add headers (especially "x-" headers, which are nonstandard) to traffic that didn't already have it. The firewall won't have any context on what to add, nor what it's for. Furthermore, the XTM330 is end of life, so it's unlikely that your device will see any updates in the future.
-James Carson
WatchGuard Customer Support
Why isn't the initiating IP addr being seen by your web server?
Hello Mr. Carson, thanks for your answer, x-forward-for is the non standard header that became an informal standard (LOL).
I'm aware that the XTM330 is retired and we are planning to replace it with some other appliance, the issue we are facing with HTTP based applications (web applications or rest api's) is that we did not receive the external initiator IP address, the application receive all the requests with the IP address of the appliance, I believe it's related to SNAT rules.
Do you know if the M390 firmware is capable of propagate the initiator IP address thru http-proxy actions or similar feature?
Thanks,
Rogerio Wagner
Thanks for the advise Tristan, could you please specify which model should I use to address my issue?
All external http requests are identified as originating from the appliance.
All newer devices do the same thing (T40 and bigger that is) it depends on the size you want. Use this tool to help: https://www.watchguard.com/wgrd-resource-center/watchguard-appliance-sizing-tool
Once there you'll be able to open a ticket with WG where they will be able to actually do remote support since the device won't be EOL.
If you are having the firewall act as an HTTP proxy then the source will usually be the firewall on the web server since it (the firewall) is sending the request to the server after inspecting the packet.
~T
Isn't the HTTP and HTTPS proxy transparent, and thus both should provide the source IP addr of the web client, unless one is using HTTPS with incoming Inspect or TLS/SSL offload ?
Apparently (according to a long winded explanation here) if Static NAT works correctly then devices are supposed to receive packets from the firewall:
https://serverfault.com/questions/55611/loopback-to-forwarded-public-ip-address-from-local-network-hairpin-nat
I couldn't find a way on the firewall to bypass this... have never seen it needed for a webserver either... so to answer your question it is not fully "Transparent" according to how SNAT and such works... I am unsure if same principal applies to 1:1 NAT
The posted link refers to hairpin NAT - which WG calls NAT loopback.
For NAT loopback, I can see where the source IP addr would be replaced by the firewall interface IP addr in order for reply packets to get back via the originating path.
But I don't see why this would be true for standard SNAT from external to an internal device.
To address not seeing the client's IP addr when using NAT loopback, one needs to not use NAT loopback and use a DNS solution where internal clients use a DNS server or similar solution which provides the private IP addr of the web server instead of the public IP addr.
Hello Guys, thank you very much for engage on my issue.
I've seen this configuration on F5 Big Ip .
I'll start the process to replace our two XTM 330, and research a little bit to decide which WatchGuard can address this issue, or try another brand.
Regards,
Rogerio Wagner