Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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!

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

2
Comments on this Answer
Comment made 05-Feb-2016 by Hannes Rapp 3890
Where do you get all that patience and willingness to go deep with the answers? You're probably using some sort of doping since last 2 months.
1
Comment made 05-Feb-2016 by Kai Wilke 7294
I can garantee that I'm not using any kind of doping exept coffee, joy and the willingness to self-improve while thinking about others problems. Note: But you're right, I was community clean for almost a decade, but then somehow it has catched me again. I should definitely take a therapy... ;-)
1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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,

1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

0
Comments on this Answer
Comment made 08-Feb-2016 by Kai Wilke 7294
You're welcome. Cheers, Kai
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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!!

0