search

opnsense / plugins

OPNsense plugin collection
https://opnsense.org/
BSD 2-Clause "Simplified" License
845 stars 639 forks source link

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

Open meyergru opened 2 months ago

meyergru commented 2 months ago

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

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 commented 2 months ago

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 commented 2 months ago

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

fichtner commented 2 months ago

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 commented 2 months ago

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

fichtner commented 2 months ago

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

meyergru commented 2 months ago

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.