os-squid: Segmentation fault (signal 11) on reload when using tcp_outgoing_address with WireGuard

[archlame]

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

Title:
os-squid: Segmentation fault (signal 11) on reload when using tcp_outgoing_address with WireGuard

Describe the bug
When using the os-squid transparent proxy, adding a tcp_outgoing_address directive mapped to a WireGuard interface IP in custom.conf causes the Squid service to crash with a Segmentation Fault (Signal 11) whenever a soft reload (squid -k reconfigure) is triggered via the GUI or CLI.

Because the reload command crashes natively, the OPNsense background script aborts, leaving zombie Squid processes running and preventing the service from restarting cleanly without a manual pkill -9 squid. This setup worked flawlessly prior to the OPNsense 26.1 update. Removing the tcp_outgoing_address directive completely resolves the segfaults during system reloads. Furthermore, a clean start (service squid start) works perfectly with the directive included; the crash is strictly limited to reloads.

To Reproduce
Steps to reproduce the behavior:

1. Configure and enable a WireGuard interface with a designated IP.
2. Enable os-squid in transparent proxy mode.
3. Add tcp_outgoing_address [WireGuard_IP] to the Squid custom.conf.
4. Start the Squid service (starts normally without crashing).
5. Trigger a configuration reload (e.g., click "Apply" in the Squid GUI, or run /usr/local/etc/rc.d/squid reload via CLI).
6. Observe the immediate Segmentation fault in the shell or system logs.

Expected behavior
Squid should gracefully re-evaluate its configuration and re-bind to the interface without throwing a memory access violation. Alternatively, if this is an upstream FreeBSD/Squid socket bug, OPNsense should forcefully execute a restart instead of a reload upon configuration changes to prevent the service from crashing and leaving zombie processes.

Screenshots
Not applicable.

Relevant log files
In the OPNsense system logs:
<6>[958908] pid 13409 (squid), jid 0, uid 100: exited on signal 11 (no core dump - bad address)

When running the reload manually via CLI:
root@opnsense:~ # /usr/local/etc/rc.d/squid reload
Segmentation fault

Additional context
We verified this is tied specifically to the reload command combined with tcp_outgoing_address. Attempting to map the directive to a static dummy Virtual IP (loopback lo1) instead of WireGuard resulted in the exact same Segmentation Fault upon reload, isolating the issue to Squid's socket re-binding behavior during a soft reconfigure in this specific build.

Environment
OPNsense 26.1.4 (amd64)
os-squid / Squid Cache Version 6.14 (amd64-portbld-freebsd14.3)
OpenSSL 3.0.19 27 Jan 2026
Intel e3-1585 v5
Intel X710-DA2

[archlame]

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

Title:
os-squid: Segmentation fault (signal 11) on reload when using tcp_outgoing_address with WireGuard

Describe the bug
When using the os-squid transparent proxy, adding a tcp_outgoing_address directive mapped to an interface IP (like WireGuard) in /usr/local/etc/squid/pre-auth/custom.conf causes the Squid service to crash with a Segmentation Fault (Signal 11) whenever a soft reload (squid -k reconfigure) is triggered.

Because the native reload command crashes, the OPNsense background script aborts, leaving zombie Squid processes running and preventing the service from restarting cleanly. Removing the tcp_outgoing_address directive completely resolves the segfaults during system reloads. Furthermore, a clean start (service squid start) works perfectly with the directive included; the crash is strictly limited to reloads.

To Reproduce
Steps to reproduce the behavior:

1. Configure and enable a WireGuard interface with a designated IP (e.g., 10.2.0.2).
2. Enable os-squid in transparent proxy mode.
3. Add tcp_outgoing_address 10.2.0.2 to the Squid custom.conf.
4. Start the Squid service (starts normally without crashing).
5. Trigger a configuration reload via GUI or CLI (squid -k reconfigure).
6. Observe the immediate Segmentation fault in the shell output.

Expected behavior
Squid should gracefully re-evaluate its configuration and re-bind to the interface without throwing a memory access violation. Alternatively, if this is an upstream socket bug, OPNsense should forcefully execute a restart instead of a reload upon configuration changes to prevent the service from crashing and leaving zombie processes.

Screenshots
Not applicable.

Relevant log files
In the OPNsense system logs:
<6>[958908] pid 13409 (squid), jid 0, uid 100: exited on signal 11 (no core dump - bad address)

When running the reload manually via CLI with the custom config in place:

root@opnsense:~ # cat /usr/local/etc/squid/pre-auth/custom.conf
tcp_outgoing_address 10.2.0.2

root@opnsense:~ # squid -k reconfigure
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)
2026/04/03 01:11:45| Starting Authentication on port 127.0.0.1:3128
2026/04/03 01:11:45| Disabling Authentication on port 127.0.0.1:3128 (interception enabled)
2026/04/03 01:11:45| Starting Authentication on port [::1]:3128
2026/04/03 01:11:45| Disabling Authentication on port [::1]:3128 (interception enabled)
2026/04/03 01:11:45| Starting Authentication on port 127.0.0.1:2121
2026/04/03 01:11:45| Disabling Authentication on port 127.0.0.1:2121 (interception enabled)
2026/04/03 01:11:45| Starting Authentication on port [::1]:2121
2026/04/03 01:11:45| Disabling Authentication on port [::1]:2121 (interception enabled)
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/pre-auth/40-snmp.conf (depth 1)
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/pre-auth/custom.conf (depth 1)
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/pre-auth/dummy.conf (depth 1)
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/pre-auth/parentproxy.conf (depth 1)
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/auth/dummy.conf (depth 1)
2026/04/03 01:11:45| Processing Configuration File: /usr/local/etc/squid/post-auth/dummy.conf (depth 1)
2026/04/03 01:11:45| WARNING: HTTP requires the use of Via
2026/04/03 01:11:45| Set Current Directory to /var/squid/cache
Segmentation fault

Additional context
Verified this is tied specifically to the reload command combined with tcp_outgoing_address. Attempting to map the directive to a static dummy Virtual IP (loopback lo1) instead of WireGuard resulted in the exact same Segmentation Fault upon reload, isolating the issue to Squid's socket re-binding behavior during a soft reconfigure. As seen in the CLI output, the segfault occurs immediately as it processes the files and attempts to assign the current directory.

Environment
OPNsense 26.1.5-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19
os-squid / Squid Cache Version 6.14 (amd64-portbld-freebsd14.3)
CPU: Intel e3-1585 v5
NIC: Intel X710-DA2