2

I am using a Nginx Ingress Controller in a Kubernetes Cluster. I've got an application within the cluster, which was available over the internet. Now I'm using the Ingress Controller to access the application, with the intent of showing some custom errors.

If i access the application (which is not written by myself, therefore I can't change things there), it receives the IP address of the nginx-ingress-controller-pod. The logs of the nginx-ingress-controller-pod indicate that the remote address is a different one.

I've already tried things like use-proxy-protocol, then I would be able to use $remote_addr and get the right IP. But as I mentioned I am not able to change my application, so I have to "trick" the ingress controller to use the $remote_addr as his own. How can i configure the ingress, so the application will get the request from the remote IP and not from the nginx-ingress-controller-pod IP? Is there a way to do this?

Edit: I'm using a bare metal kubernetes installation with kubernetes v1.19.2 and the nginx chart ingress-nginx-3.29.0.

Improve this question
2
  • 1
    Hello @black_hawk, welcome to StackOverflow. How did you set up your cluster? Did you use bare metal or some cloud providor? Which version do you have Kubernetes and nginx? Please add your errors to the question.
    – Mikołaj Głodziak
    Commented Jun 30, 2021 at 14:31
  • Hey @MikołajGłodziak, i updatet the question, but i can't provide any errors, because there are none. I just know, that my application rejects the ip of the ingress controller and needs the remote adress. For example: The logs of the ingress controller showing a remote adress of 192.168.13.0 and my application got a clientip of 192.168.90.2, which is the ip of the ingress-controller-pod. The application then forwards this ip to another pod/service, which rejects it, because its not 192.168.13.0. I hope i could make the problem understandable.
    – black_hawk
    Commented Jul 1, 2021 at 7:53

1 Answer 1

Reset to default
2

It could not achievable by using layer 7 ingress controller.

If Ingress preserves the source IP then response will got directly from the app pod to the client, so the client will get a response from a IP:port different from what he connected to. Or even worse - client's NAT drops the response completely because it doesn't match the existing connections.

You can take a look at this similar question on stackoverflow with accepted answer:

As ingress is above-layer-4 proxy. There is no way you can preserve SRC IP in layer 3 IP protocol. The best is and I think Nginx Ingress already been set by default that they put the "X-Forwarded-For" header in any HTTP forward. Your app supposes to log the X-Forwarded-For header

You can try to workaround by following this article. It could help you to preserve your IP.

I also recommend this very good article about load balancing and proxying. You will also learn a bit about load balancing on L7:

L7 load balancing and the OSI model As I said above in the section on L4 load balancing, using the OSI model for describing load balancing features is problematic. The reason is that L7, at least as described by the OSI model, itself encompasses multiple discrete layers of load balancing abstraction. e.g., for HTTP traffic consider the following sublayers:

  • Optional Transport Layer Security (TLS). Note that networking people argue about which OSI layer TLS falls into. For the sake of this discussion we will consider TLS L7.
  • Physical HTTP protocol (HTTP/1 or HTTP/2).
  • Logical HTTP protocol (headers, body data, and trailers).
  • Messaging protocol (gRPC, REST, etc.).
Improve this answer
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.