Http Proxy adding X-Forward-For header

RogerioWagnerRogerioWagner
in Technical Discussion

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

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    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

  • Bruce_BriggsBruce_Briggs

    Why isn't the initiating IP addr being seen by your web server?

  • Tristan.ColoTristan.Colo
    I would advise getting a newer non-end of life firewall XP I can’t imagine that old firewall is still actually secure enough to be a NGFW anymore.
  • RogerioWagnerRogerioWagner
    edited March 2022

    @james.carson said:
    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.

    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

  • RogerioWagnerRogerioWagner

    @Tristan.Colo said:
    I would advise getting a newer non-end of life firewall XP I can’t imagine that old firewall is still actually secure enough to be a NGFW anymore.

    Thanks for the advise Tristan, could you please specify which model should I use to address my issue?

  • RogerioWagnerRogerioWagner

    @Bruce_Briggs said:
    Why isn't the initiating IP addr being seen by your web server?

    All external http requests are identified as originating from the appliance.

  • Tristan.ColoTristan.Colo

    @RogerioWagner said:

    @Tristan.Colo said:
    I would advise getting a newer non-end of life firewall XP I can’t imagine that old firewall is still actually secure enough to be a NGFW anymore.

    Thanks for the advise Tristan, could you please specify which model should I use to address my issue?

    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

  • Bruce_BriggsBruce_Briggs

    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 ?

  • Tristan.ColoTristan.Colo
    edited March 2022

    @Bruce_Briggs said:
    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

  • Bruce_BriggsBruce_Briggs

    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.

  • RogerioWagnerRogerioWagner

    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

Sign In to comment.