Forum Discussion
snester23
Nimbostratus
NimbostratusAllowing source IPs to be visible behind a BIG-IP
We have a big-IP version BIG-IP 14.1.0.3 Build 0.0.6 Point Release 3 with a few services running on it. One of the services takes in telemetry data from 100 client devices, passes through the BIG-IP to a pool of 3 identical listening devices, all on a custom port. The listening devices have a simple web console mainly used for internal status checking and troubleshooting.
We previously had these devices behind a Barracuda Load Balancer. On the three listening devices, the client connections would be displayed showing their outside, originating IP, which helped in identifying what client site it was. Now that we've moved these devices behind the BIG-IP, everything seems to be working properly, except the devices are all displaying the floating self-IP of the BIG-IP. We have 100 connections, all showing the same IP.
Is there a way to have them display their actual, originating IP address? I was working with a support engineer who suggested disabling Address Translation and then setting the WAF's floating Self-IP as the default gateway on the three listening devices, but that results in the outside devices being unable to connect at all.
Any other suggestions? I'd be happy to try and provide any addition information, if needed. This is a standard virtual server passing traffic via TCP.
HamishCirrocumulus
The support engineer is correct. However that assumes that the BigIP will actually act as the default gateway.
You have several choices
- Insert host routes to the BigIP for the clients instead of default gateway
- Use policy routing and only route traffic to the clients FROM tyhe service port via the BigIP
- Actually turn the BigIP into your default gateway
That's assuming you're not picking up the original IP via X-Forwarded-For headers or something that you haven't enabled.
- freestyle
Hello,
You can do as stated by the support engineer.
Also, to resolve the connectivity of outside devices ,you can configure a forwarding IP virtual server for communication of internal servers to outside.
Thanks,
onchoaWhere is the reply from the support engineer?
Or somebody please answer this question, it is my question too.
Hi,
Do you know how the orginating ip address was previously being seen?
What i think you are stuggling with here is the SNAT, from the f5 being a full proxy.Doing what the support engineer suggests will mean that the return traffic will always be from the pool members not the f5 which will mean you network and applications will have to be able to cope with that. (not always easy, and secruity wise that has issues)
You've said this was a tcp Virtual Server, now is this actually a HTTP application? (so you could turn the http profile on?)
What you could do / or may have been done in the past is that the application on the aplication servers is looking for the X Forword For parameter, this is added to the HTTP header as it leaves the f5 with the orginating IP that came into the f5. You need to turn on the http profile, and inside the profile there is a tick box to turn it on.That's the simplest method to achieve what you are looking for, there are other solutions like proxy protocol but that would need the backend applciation to support it as well and as you are just in a replacement process i doubt that's been there,
I would try to find out how its been monitored in the past and try to work back, i'd be amazed if the f5 can't reproduce it.
