Forum Discussion

Waylon's avatar
Waylon
Icon for Nimbostratus rankNimbostratus
Feb 05, 2016

X-Forwarded-for with SSL Passthrough (no offloading on LTM)

Hi,

 

Is there a way to get X-forwarded-for working with SSL passthrough (NO offloading)?

 

I have some system owners who refuse to have any form of "man in the middle" sessions and require the F5 to pass all SSL sessions directly to the web servers, so I cannot do any form of SSL offloading or SSL Proxy'ing.

 

I've had success using an HTTP profile with x-forwarded-for enabled, however, I know you cannot use an HTTP profile if the VS is set to use 443.

 

Is there perhaps an iRule I could use and if so what would it look like, or something else as simple as enabling X-forwarded-for elsewhere?

 

(I'm very new to F5 / LTM so any detailed steps would be greatly appreciated)

 

Thanks in advance!

 

application delivery
iRules
LTM
ssl passthrough
  • jamesdris's avatar
    jamesdris
    Icon for Nimbostratus rankNimbostratus
    Feb 05, 2016

    If SSL is not offloaded on the bigip, there is no way it can decrypt the traffic coming from the servers and so nothing can be inserted into the headers.

     

  • Hannes_Rapp's avatar
    Hannes_Rapp
    Icon for Nimbostratus rankNimbostratus
    Feb 05, 2016

    All HTTP headers (incl. the optional X-Forwarded-For) are subject to encryption whenever SSL is enabled. You cannot read or modify the HTTP headers without offloading the SSL on the clientside.

     

    If the issue is a lack of visibility of the real customer IP address, you may want consider a HSL logging solution, or consider changing your routing topology so that translating a customer IP is no longer required. There are no other options.

     

    Regards,

     

  • Brad_Parker's avatar
    Brad_Parker
    Icon for Cirrus rankCirrus
    Feb 05, 2016

    If your app owners refuse to let you use the best SSL stack around :-) and you can't have the LTM be default route for the back-end server, but still require the original source address to be presented to those servers you may consider using nPath routing(direct server return). Since you aren't inspecting content anyway, not having the response go through the BIG-IP isn't that big of a deal.

     

    https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-6-0/4.html

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Feb 05, 2016

    Hi Waylon,

     

    as the previous posters have already mentioned. You can't insert anything to the SSL protected content without performing MitM.

     

    So you have to use either one of the following approaches...

     

    1. A routed approach (Hannes recommendation) to transparently forward the original client IP to the backend servers.
    2. An IP-Tunneling approach, to tunnel the traffic between your F5 and web servers to avoid intensive changes to your entire routing infrastructure.
    3. A rather complex NAT4-to-6 constructs to hide the original IPv4 into a /96 IPv6 SNAT pools while forwarding the traffic to your backends (to avoid Default-GW dependencies). But in this case your backend infrastructure has to support native IPv6 or ISATAP transition technologies...

    Note: I would like to second Hannes recommendation, by either...

     

    1. changing the Default-GW topology of your network to passthrough your F5 in the path for 0.0.0.0/0.
    2. adding an additional VLAN interface directly into the subnets of your webservers and change just the Default-GW of your web servers.
    3. implementing certain Route-Maps / PBRs in your network environment, to be able to route just the HTTPS responses from your web servers (based on their SRC-IP and the SRC-Port of :443) through your F5 for internet related traffic (DST-IP:Any).

    Cheers, Kai

     

  • Waylon's avatar
    Waylon
    Icon for Nimbostratus rankNimbostratus
    Feb 08, 2016

    Thanks to everyone for their feedback, all the help is greatly appreciated! I'll forward the recommendations onto the necessary parties!

     

  • Suresh_Gurugubi's avatar
    Suresh_Gurugubi
    Icon for Nimbostratus rankNimbostratus
    Apr 12, 2018

    Hello guys, Need some help.

     

    It was confirmed we cannot use X-Forward-For for SSL pass-through VIPs, but If I add it, what will happen. is the VIP still works?? I mean if the traffic is not offloading on BIGIP, can it ignore optional XFF http profiles and continue to work as it works earlier??

     

    By mistakenly today I have added XFF to one of our old VIP, which cause huge outage. Our backend (apache) was recieving invalid HTTP requests / invalid SSL handshakes and stalling as a result.

     

    I'm little confused here as BIGIP cannot add/modify http headers, how can the backend servers get invalid SSL handshakes. anyone have any idea!!

     

  • F5_Design_Engineer's avatar
    F5_Design_Engineer
    Icon for MVP rankMVP
    Nov 30, 2023

     If SSL is not offloaded on the bigip, there is no way it can decrypt the traffic coming from the servers and so nothing can be inserted into the headers.

    Thus for HTTPs packets will get corrupt if encrypted packets and someone will try to insert XFF headers in it.

    To insert XFF headers in HTTPs packets, F5 must have client SSL with SSL key to decrypt the packets before inserting the XFF header.

    Else dont insert XFF on encrypted packets where the decryption is happening on the backend servers , and F5 is just a SSL pasthrough XFF insertion will make the SSL packets looks tampered or MIM man in middle attack sort of thing and the backend server will complain the packets are corrupt on invalid SSL packets as they have ben tampered headers while trying to insert the XFF headers in an encrypted SSL packet. One must undertsnad the packet level headers and modifyling SSL packet headers make them useless.

     

    HTH

    🙏