Documentation for using OPNsense behind a web proxy using optional configd configuration files

[dominikborkowski]

Important notices

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

• [x] I have read the contributing guide lines at https://github.com/opnsense/docs/blob/master/CONTRIBUTING.md
• [x] I have searched the existing issues and I am convinced that mine is new.

Is your feature request related to a problem? Please describe.

Current documentation does not provide information on how to configure OPNsense to work with an existing web proxy to fetch updates. Appending custom configuration to /usr/local/opnsense/service/conf/configd.conf is short lived, because every update resets it.

Describe the solution you like

With the release of latest 23.7.12 there's a new feature: 'backend: support optional configd configuration files', which presumably can be used to have a persistent proxy support. Potentially something along the lines of:

cat <<EOF | sudo tee /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf
[environment]
HTTP_PROXY=http://your_proxy:3128
HTTPS_PROXY=http://your_proxy:3128
http_proxy=http://your_proxy:3128
https_proxy=http://your_proxy:3128
FTP_PROXY=http://your_proxy:3128
ftp_proxy=http://your_proxy:3128
ALL_PROXY=http://your_proxy:3128
all_proxy=http://your_proxy:3128
EOF

sudo service configd restart

Perhaps there's a more appropriate approach, but it would be lovely to have this as part of the dopcumentation.

Describe alternatives you considered

There are no viable alternatives.

Additional context

We'd love to see examples of how to inject this type of configuration into an initial deployment of OPNsense.

Thank you!

[dominikborkowski]

Additionally, it would be great to see canonical documentation on setting permanent environment variables for user accounts.

For example, when executing /usr/local/etc/rc.firmware from a shell it does not use environment variables set via /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf. One has to set HTTP_PROXY for superuser account for that tool to successfully execute.

Cheers!

[fichtner]

We did talk about this but it’s neither easy nor overly desired. I recently hooked some env cars into launcher.sh but it’s always going to be tricky to enforce a functional (clean) env and have the user selection on top. Some env vars may even break connectivity.

[dominikborkowski]

The problem is, without those env vars, there's no connectivity. We'd be content without having the tools hook into env variables set in /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf, rather to make sure whatever we set is not removed during upgrades.

Would ~/.profile be a safe location for root & individual users?

[fichtner]

It’s exactly why I prefer the launcher.sh for firmware related env vars, but it’s not yet pluggable but at least it’s controllable and scope is targeted.

.profile can be used, but like configd its scope is also limited to the executing user / global exec env. So ideally you can only use root if env vars do not propagate through sudo.