Handling WebSockets through proxy

[Jodana]

I am using your library to setup pipes between a web-client and a C# server.

The client is initiating the connection through a proxy (using NGINX proxy_pass) and the main issue is the created websocket on the server got as a remote endpoint address, the IP of NGINX instead of the real IP address of the client.

For example:

1. Client with IP 10.10.4.2 is trying to connect to the server
2. Nginx forward the request to the websocket server
3. A websocket is created on the server, but instead of 10.10.4.2, I find 127.0.01 (since NGINX and the websocket server share the same IP)

I may be wrong but a network connection is identified by both LocalEndPoint AND RemoteEndPoint. Thus, if two distinct remote clients somehow initiates a connection using the same client port, the server will see two identical connection attempts (eg. 127.0.0.1:8002). In this case, won't the connection fail ? Two sockets can't be created using identical remote and local endpoints as I believe.
Plus, debugging is quite hard without referring to real remote IPs

Question is: is there any way to bypass this using your library ? I thought about adding custom headers including clients real IPs in Nginx configuration file, but I don't know how to force the library to refer to this header.

[vtortola]

You can bypass proxies using wss:// rather than just ws://. Otherwise, a server component cannot do anything to bypass proxies.

The WebSocket object contains a HttpRequest property you can use to inspect the HTTP headers. You can do that also during the HTTP negotiation if you like.

I hope this helps.

[Jodana]

Thank you. I will go with WSS then.

As for general knowledge, do you know if the situation I have described could happen (two distinct connections using same source port, altered by proxy to appear as sharing the same IP) ?
How would the server react to this and differentiate the two sockets ?

Regarding HTTPRequest, I am already intercepting the HTTP negotiation because I need to check if the user attempting the connection is already logged through NancyFX.

By the way, your documentation is clear and complete, which makes this listener easy to use.

[vtortola]

Thanks 👍

Are you sure they have the same source port? Even if the proxy is in port X, it does not mean that the connections from the proxy have X as source port. A client should not be able of creating two connections with the same origin port. I would say that the combination of the 4 should be unique.

[Jodana]

You are right, a unique client can't open two sockets on the same port (unless another network interface is selected).

At the moment, here is the scenario: two distinct connections are detected, without using proxy, as it should be => 192.168.1.15:47002 and 163.145.12.3:64017.
When using proxy, this changes to: 127.0.0.1:47002 and 127.0.0.1:64017 => their IP has been "masked" by the proxy IP (being on the same machine as the socket server, it becomes the loopback address).

What I am afraid of, and I may be wrong, is a conflit to happen if both had somehow selected the same port instead of 47002 and 64017 (which could be possible).
As I understood it the client port is selected randomly among all available ports on the client's machine. Thus, if two distinct clients machine select the same client port (say 27015), they should be differentiated thanks to their own unique IP address.
But, passing through the proxy is altering their IP which may give as a result : two incoming connections with endpoint being 127.0.0.1:27015 (Proxy IP).

[vtortola]

I would say that the proxy itself would prevent such situation, otherwise, it would be kind of sloppy. Probably you should ask to the people that develops the proxy itself. As far as this component is concern, it does not keep any collection of sockets anywhere, so it is no problem.