proxy_protocol_port variable should store the PROXY_PORT rather than CLIENT_PORT

[Janusz M]

Thanks for the detailed description! The use case that you described
explains all:
"... to uniquely identify client even if it is behind a NAT or we need to
find out a particular process which established the connection."

Both 56324 and 443 values could be used in certain scenarios and now we'd
need to introduce new variable to satisfy all valid use cases.

Perhaps this could evolve into a new feature and new var?

Kind regards,
Janusz

2017-05-15 17:04 GMT+02:00 Maxim Dounin <mdounin at mdounin.ru>:

> Hello!
>
> On Mon, May 15, 2017 at 04:00:07PM +0200, Janusz M wrote:
>
> > Hi Maxim,
> >
> > First of all thanks for your quick reply. I read the nginx 1.11.0 and
> > 1.11.4 release notes, thanks. Perhaps I wasn't as clear in my description
> > as possible.
> >
> > Please consider the following scenario:
> >
> > * a client (user) with IP 185.12.12.12 makes an HTTPS request to the app
> > and hits the load balancer
> > * load balancer forwards both HTTP and HTTPS requests to nginx server on
> > port 80 (standard Amazon AWS setup)
> > * Proxy Protocol is turned on, load balancer adds the following line to
> the
> > request:
> >
> >   PROXY TCP4 185.12.12.12 172.31.0.11 56324 443
>
> So, as per PROXY protocol specification, source address is
> 185.12.12.12, source port is 56324.  Destination address is
> 172.31.0.11, destination port is 443.
>
> > * nginx with proxy_protocol on reads port 56324 to $proxy_protocol_port.
> >
> >
> > The point is that with the current implementation, either nginx's
> behaviour
> > or proxy protocol itself feels inconsistent.
> > You wrote:
> > "The $proxy_protocol_port, much like $proxy_protocol_addr, reflects
> client
> > port for the proxy protocol header. "
> > but in fact, what we see in those variables is the client IP (public IP
> of
> > the client's computer) and the load balancer port (not the client port).
>
> When the original client connection uses 185.12.12.12 source
> address and 56324 source port, $proxy_protocol_addr will contain
> 185.12.12.12, and $proxy_protocol_port will contain 56324.  This
> is perfectly consistent and will allow to uniquely identify client
> even if it is behind a NAT or we need to find out a particular
> process which established the connection.
>
> Both destination address and destination port are not available
> via nginx variables.  As previously suggested, if you want to
> distinguish between different destinations, you can easily do so
> by using distinct listening sockets in nginx.
>
> It looks like you somehow think that "client port" means "the port
> which client used as a destination of a connection".  This is
> certainly not what it used to mean.  Each TCP connection has two
> sides, and each side has an address and a port.  When one of the
> sides is a client, "client address" is the address of this side,
> and "client port" is the port of this side.  Please refer to TCP
> protocol description for more information.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170515/f75e0589/attachment.html>