os-squid: web proxy does not listen on all configured interfaces on startup

[meyergru]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• The title contains the plugin to which this issue belongs

Describe the bug

When using squid on several VLAN interfaces in order to regulate internet access, sometimes, it seems that it does not listen to all configured interfaces. Òn some, there is an ECONNREFUSED, meaning that the port 3128 seems to be closed.

To Reproduce

Reboot OpnSense and try to access Squid from all potential interfaces by using the interfaces IP address on port 3128, e.g. with nmap -p3128 192.168.7.1, of which I have multiple defined in squid.conf:

# Setup regular listeners configuration
http_port 192.168.5.1:3128
http_port 192.168.4.1:3128
http_port 192.168.3.1:3128
http_port 192.168.7.1:3128
http_port 192.168.8.1:3128
http_port 192.168.6.1:3128

From some interfaces, the port is closed.

After a restart, the ports open up. "Restart" meaning exactly: Disable and re-enable squid, restart via the recycle button does not work.

Expected behavior
Squid should listen on all interfaces from the get-go.

Additional context
I think this may be of different behaviour for interface startup. Either Squid should be allowed to use "all" interfaces - like the web GUI of OpnSense itself (we know that there are problems if the bind address is not 0.0.0.0).

Alternatively, the interface startup should restart Squid or its startup should be delayed until all interfaces are up.

Environment

OPNsense 24.7.2 (amd64), probably since 24.7 already.

[fichtner]

Squid is started very late and coupled with the fact that it only accepts static addresses (unless we talk about VIPs here) I can't see a good reason why this would fail during initial setup. I would think the daemon does something strange, which would also point to the fact that the reload doesn't recover in this case (although this could be an implementational detail I don't know about).

Listening to 0.0.0.0 is probably not going to happen as it will likely introduce other side effects.

[meyergru]

Most interesting was that I saw that the binding was done with "sockstat", however only one IP reacted to connection requests.

[fichtner]

The only other thing I can think of is some kernel-down/up related link activity that wedges the interface at least from squid's perspective and that's why it can't recover on reload as well because it thinks it's fine?

[meyergru]

Sure looks like it. But what activity is that? If Squid is started late and the interfaces are configured statically, what happens thereafter?

[fichtner]

Check dmesg for link events. I don't think I want to look any closer at what the problem could be.

[meyergru]

The only link events I can see is with initial setup of the VLAN interfaces. None after that. But I think that Squid gets started after that.