[SOLVED] "Initial Connection" is taking long to load, after 2min idle

[nono]

Hi there,

I'm on OPNsense 22.7.9_3-amd64 with os-nginx (installed)   version 1.31

I'm currently working with the nginx plugin, in order to act a TLS Certificate proxy for all the machine behind the firewall.

When dealing with Data Streams & Upstream (as far as I understood, one way to achieve my goal), I noticed that the action of Editing either the Data Stream or the Upstream I created is taking very long (around 20sec) to load.

Way to reproduce :
Going on Services > Nginx > Configuration > Data Streams (or Upstream)
Then edit the entry there (clicking on the "edit" button) (launching : https://xxxx/api/nginx/settings/getupstreamserver/xxx-xxx-xxx-xxx-xxx )
=> Wait for 20sec <=
See the actual edition page.

The network pan of my "Developer tools" indicate that it's the "Initial connection" which took very long to load).

Here is a screenshot of the network load showing the issue :

[Fright]

Hi
Initial connection. The browser is establishing a connection, including TCP handshakes/retries and negotiating an SSL.
so its not plugin\page\request specific imho. try to take a look at overall server load

[nono]

Server load is really low. (we are currently 2 users using this instance).
Only 1 of them having this issue so far.

[Fright]

In that case i would take a closer look at the client. Queueing time also looks significant

[nono]

Any lead what and where to look for exactly ?
What do you call "the client" ? The web browser ?

Indeed my colleague confirm that it's not only this plugin, but the whole page (when I never experienced issue myself) and it's always the state "Initial Connection" which is taking time to load.

He also told me that to reproduce the issue he has to :
1) Open the OPNSense interface
2) go on another website for ~2min
3) Go back to OPNSense interface => And things got slow.

EDIT: I'm changing the title of my post accordingly.

[Fright]

client browser, yes.
it happens to me when the browser finally gets tired of 120 tabs open by me (some of which constantly request something)  ;)
I think that the same effect can be if the stack is busy not only with browser requests (torrents or some)

[nono]

Well,
Same OS (Windows 10 Pro)
Same BRower ( Chrome, latest)
He's doing NOTHING on the network with 2 tabs => issues
I'm doing SOME and have 62 tabs open ...

Guess who's having the issue  ;D

Any other lead by any chance ?

[Fright]

sorry, too many guesses (av, chrome plugins\extensions, vpn etc.)
would try with another browser and further on the results

[nono]

Hi Fright,

We're still experiencing the same issue, with 3 users now.
Me : no issue
Two colleagues : Having same issue and same "Initial Connection" time at ~20sec.

We all use : Same OS, Same Browser (and tested other, without plugins installed), all using the same VPN / Client and same AV version as well.

The difference would be for them to have both IPv4/IPv6 provided by their ISP when I only have IPv4. Could this be somehow a culprit ?

[Patrick M. Hausen]

The difference would be for them to have both IPv4/IPv6 provided by their ISP when I only have IPv4. Could this be somehow a culprit ?

Of course. The "happy eyeballs" algorithm in more or less all desktop OSs prefers IPv6 over IPv6 if it thinks IPv6 is available and working. If that is not the case it will still try and eventually time out, then try IPv4.

Can your coworkers disable IPv6 for a test and if that "fixes" the problem, then you probably need to get into the details of your IPv6 setup.

HTH,
Patrick

[nono]

I'll check with them and revert, but I switch to my mobile connection (providing both v4 and v6) and I can't reproduce the issue so far.
I assume it can still be a cache issue, even though I used incognito mode.

[Fright]

@nono
starting to think that the problem may be in name resolution (old hosts records, old dns records?)  - so the browser spends some time before it starts knocking the correct address.
can you compare the behavior when using ip address instead of hostname ?

[nono]

Ok, so we made some test and indeed, using the IP is faster.

I then noticed that a "nslookup" return all the interface IP for the hostname, including the WAN (public IP) one.

I then check unbound DNS service which was listening on all interfaces, and decided to remove WAN from it.
The Public IP wasn't resolved anymore, which fix the slowness issue but still make me wonder :

Even if unbound isn't listening to WAN interface, it shoulds still resolve the IP of all interfaces, right ?

How could it be that I "remove" the WAN ip, simply by asking unbound to not listen on WAN interface ?

[Fright]

yes, it's meant to be - see help message for "System A/AAAA records" option at Services: Unbound DNS: General

[nono]

Thanks, I'll mark the topic solved