Hostname resolution happens too early in case of proxied websocket connections.

[GrafBlutwurst]

Observed behavior

c.f. #913

The problem is that even with the isNoResolveHostnames option set, if the connection is proxied the actual tunneled connection to the NATS server happens by IP and not by hostname.

This can lead to issues in presence of a firewall as it requires both whitelisting of the domain/host as well as its IP.

Expected behavior

All connections should be done by hostname if isNoResolveHostnames is set.

Server and client version

I think only the library version matters here as the issue is purely client side. We're at 2.16.14

Host environment

No response

Steps to reproduce

Happens on any proxied websocket connection.

[GrafBlutwurst]

So an update to that @scottf your concerns were well warranted. The adjustment the linked MR makes works only if there's a proxy but in such cases might be necessary in case there's a picky firewall involved. Here's what's going on.

Note that this might only pertain to the websocket connection which is what we use in our project.

In the current implementation when the isNoResolveHostnames network connections are initiated using both Hostname and IP. In case of a picky Firewall/Proxy (we're not in control of that, in fact that part of the software is deployed on-site at a customer) this leads to failure because the Firewall is configured only hostnames.

Suppressing hostname resolution as the MR does, works in such cases because the proxy will eventually handle this for us. Disabling the proxy and leaving the new isNoResolveHostnames blows up however with an exception complaining about the unresolved hostname.

I think what is necessary to do is:

• check if this IP/Hostname behaviour is the same on the native protocol (so following steps can be applied either in both cases or WebSocket only)
• Suppress hostname resolution as the linked MR does only if a proxy is configured.