Messages

Wir betreiben mehrere OPNsense Firewallsysteme, die via OPNcentral verwaltet werden. Benutzer werden über LDAP eingebunden, die einzelnen FW Systeme haben einen Token, der im OPNcentral hinterlegt ist.
Mit Version 24.10 ist/war alles in Ordnung. Wir haben heute auf OPNsense 25.4 aufgerüstet - über den Zwischenschritt eines letzten 24.10 Update (Endung _8). Das Update ist vial Konsole erfolgt und verlief problemlos. Nach dem erfolgreichen Update aller Systeme - inklusive OPNcentral - schien alles in Ordnung und in gewohnter Manier. Nach einer Weile ließen sich allerdings der Firmwarestand, die Resourcen und die Provisionierungen nicht mehr auf OPNcentral abrufen - aus dem gelben Zahnradsymbol wird ein schwarzer Punkt. Schwebt man über diesem, wird eine cURL Fehlermeldung sichtbar (die ich hier nicht wiedergeben kann, da kein Zugriff), allerdings sticht core/api und 401 als Fehlercode hervor. Das automatische Einloggen via Click in der OPNcentral funktioniert nicht mehr.

In den Migrationshinweisen steht etwas von einer Änderung der Benutzerverwaltung und API Token Generierung. OPNcentral propagiert Autorisierung/Authentifizierung und LDAP Server/Benutzer via CRON auf die angebundenen FW Systeme. Ich habe sämtliche API Token auf den OPNsense FW mit dem neuen Interface neu generiert und auf die OPNcentral Konfiguration übertragen.
Und hier erlebe ich jetzt mein blaues Wunder (obwohl nicht in Dresden wohnend). Die Token sind scheinbar nur für eine kurze Weile auf den OPNsens FW verfügbar und "verschwinden". Oder es wird ein alter Token propagiert - und ich weiß nicht, wo dieser herkommen soll, auf der OPNcentral sind die Token gelöscht, es wird entweder root oder ein spezieller User für die OPNcentral Provisionierung verwendet. Eigentlich sollte das Prinziep geradlinig sein - API Token auf Zielsystem generieren, zur entsprechenden Konfiguration desselbigen auf der OPNcentral transferieren.

Was geht hier schief? Was habe ich überlesen?

The problem is still persistent in

FreeBSD 14.1-STABLE #2 stable/14-n267607-7e10c2d27a53: Sat May  4 08:33:15 CEST 2024 amd64

and I guess OPNsense will hit the fan when reaching the base of FreeBSD 14.

So, this is kind of dog's chasing its tail. I have to evaluate the use of OPNsense for my department and I'm officially not a certified customer paying fees, but pushing upstream a request as customer requires me to be a qualified customer? If not, how can I state such a request?

On the other hand, mirroring results in the same way in a not easily to solve problem without a webservice as I asked in another thread recently when I had my issues with stating the URL's target as "file:///" versus OPNsense's internal expansion of this URL into "pkg+file:///" (for reasons unknown FreeBSD's libfetch doesn't allow this kind of URL ... ).

Our complete network is behind a PROXY. Within this network, we intend to use OPNsense as the main FW solution. But it seems to be a problem for the OPNsense confid to adapt to HTTP_PROXY environment settings to reach the PROXY.

As FreeBSD user/administrator, it is common to setup the environment with HTTP_PROXY, HTTPS_... and NO_PROXY and its lower case counterparts. For FreeBSD's pkg the place for configure this environment is /usr/local/etc/pkg.conf or whatever config file pkg is delegated to. Settings within pkg.conf do survive a major system update/upgrade.
For OPNsense's configd, the correct place seems to be /usrLocal/opnsense/service/onf/configd.conf, there is a section [environment] and putting the HTTP_PROXY configs there makes OPNsense work through the PROXY as expected.
But the configd.conf configurations vanish after an upgrade/update.

How can this be fixed to be made static and non-volatile?

Thanks for the reply.

If you do not support this scheme from GUI (supposed the pkg tool maintainer will manage it to make pkg+file working), what is the strategy for updating/upgrading an OPNsense FW completely isolated from the internet?

The OPNsense installation is a test case for validating the use of OPNsense within a secure network, so OPNsense does not have any kind of access to the world-wide-network.

Mirroring the repository as suggested to a local host and then copying the whole repo as it is to a large USB flash drive, works fine. Also the mounting of the USB flash drive via ZFS pool import works fine (one has to have access to the console since the automated or GUI delegated importing of USB flash drives is not supported).

The ZFS flash drive is mounted to /mnt/OPNSENSE00/, the repo is located beneath /mnt/OPNSENSE00/repo.

In the GUI of a OPNsense running 21.7.3_3 OpenSSL, commit 17aec4ed4, the config is as follows to reflect the local repository:

Mirror: other
file:///mnt/OPNSENSE00/repo/
Flavour: default (or OpenSSL, doesn't matter)
Type: Community (or Development, doesn't matter)

Updating via option 12 on the console gives several errors like

pkg: invalid scheme pkg+file
pkg: Cannot parse configuration file!


or from the GUI:
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 21.7.3_3 (amd64/OpenSSL) at Fri Nov 19 12:18:07 CET 2021
Fetching changelog information, please wait... done
pkg: invalid scheme pkg+file
pkg: Cannot parse configuration file!
pkg: invalid scheme pkg+file
pkg: Cannot parse configuration file!
***DONE***

I have no clue what causes the problem.Setting in /usr/local/etc/pkg.conf:

pkg_env={
MIRROR_TYPE: "NONE",
}

did not resolve anything so far.

Need some advise. Thanks in advance.

Hello out there.

Running OPNsense with a dedicated bridge modem at my ISP's network, recent OPNsense 21.1.6 seemingly fails to provide essential informations. The provider offers exclusively Dual-Stack lite (DS-lite). Defining the WAN access interface and connection techniques via PPPoE works perfect with OPNsense, but I can not get the AFTR, which is obviously provided via DHCPv6 (Option 64 according to IANA, OPTION_AFTR_NAME, see RFC6334).
Somehow the GUI of recent OPNsense 21.1.6 offers an option field for DHCP6 requests, but I do not know nothing about the syntax of this option field, nor can I find some informations about in the OPNsense documentation. I guess a valid request tag would be what is symbolically defined in the WIDE-DHCP6c package, used these days in recent OPNsense 21.1.6, but the documentation of the WIDE-DHCP6 project doesn't provide me with a plethora of informations as requested.

Maybe I missed something here, so I'd like to ask here.

What is the syntax of the request field for the DHCP6c? The syntax of the parameters send via the send options is clear, but not the options itself, it would be nice if there would be a list of options known by their symbolic name for both send and request (assuming that each vendor has its own nomenclature ...). Especially "option 64 " is of interest, how to issue the request (option-64? opt-64? option_64? aftr-name? aftr_name?) and how and where does the dhcp6c client store returned values? I found some files conataining values in /var/db, like opt24_ip or opt24_ipv6 containing the IP and IPv6 addresses of the WAN (pppoe) interface, but I can not fathom how optional values issued via request could be retrieved or whether they are stored in files in the filesystem anyway by default.

Maybe someone could enlighten me?

Thanks in advance.

After upgrading OPNsense 19.1.1 to 19.1.5_1 today (2019-04-09) the service radvd and dhcpd6 are rejecting to start. I can see an empty /var/etc/radvd.conf file, which is strange, since we have had already configured that service and running. When entering the web-gui for configuration of Router Advertisement beneath Services, configuring works fine and it seems persistent, but  trying to start the service via clicking on the start symbol fails.

radvd is configured "Router only" and we use NPTv6 (uplink is dial-in via pppoe).
DHCPv6 is also not willing to start anymore.

Thanks in advance for helping

After upgrading OPNsense 18.7.10_3 to 19.1 recently, I face severe issues with firewalling and NPTv6.

The setup is a point-to-point uplink to our ISP (Telekom, vlan tag 7), dual-stack.  Inbound LAN is one interface, FreeBSD desinates it with re0. External interface is designated re1 towards the MODEM. The modem is not capable of handling vlan tags. The WAN connection is performed via PPPoE.

The outbound "interfaces"  in OPNsense terminology is WAN: it is comprised from binduing EXTIF (re1) and VLAN7 (re1_vlan7, vlan  tag 7 on re1) and WAN, which is pseudo device pppoe0 and derived from  re1_vlan7.

We use static routes for IPv4 and IPv6.

Internally we use ULA IPv6 addresses and on our FreeBSD 12/13 installations, we use successfully IPFW's NPTv6 for prefix translation. In 18.7.10_3 I tried a similar setup via the GUI, but for every change of the prefix (due to ISP interruptions or forced reset of the assigned IPv6), I had to change the translated prefix in OPNsense. So far, that setup worked in 18.7.10_3: the hosts were able to traverse OPNsense as desired.

The setup worked, so far perfectly in 18.7.10_3. It doesn't anymore in 19.1. For reasons unknown, IPv4 also doesn't work anymore. From time to time, not exactly to reproduce, reloading services from OPNsense's console via option 11 leads to "Configuring firewall.....failed". Services radvd, dhcpd6 and unbound sporadically do not load and are marked disabled in the lobby/dashboard.
It gets really weird when disabling NPTv6: after confirming, IPv4 works again and the hosts of the internal LAN are able to connect to the outside world again.

Another very strange observation in comparison to our FreeBSD experiences with PPPoE uplinks is the fact, that when OPNsense derives the link local address for the outbound EXTIF/VLAN7 interface (physical re1) the MAC of the internal NIC (re0) is used! So, I find the MAC of re0, the internal LANIF encoded in the link local IPv6 address of pppoe0, fe80::..., abd 2003::.... I'm not quite sure whether this is an issue, but from the experiences I can rely on with FreeBSD, the OS derives the MAC of cloned devices usually from the root device, which would be re1.

I feel a bit helpless here.

Hi out there.

After we upgraded our OPNsense device, I receive a "Configuring firewall.....failed" message on the console and obviously routing from attached internal networks via the one attached uplink (to ISP) doesn't work anymore.

The system is configured to utilize dual-stack.

It is something strange, login onto the OPNsense device and pinging IPv4/IPv6 destinations on both the external, outer network and internal networks works perfectly - the OPNsense also aquires its prefix and IPv4 from the ISP. From the internal networks, the OPNsense is also ping-able from all network segments and devices.

Also, the firewall logging realt-time view, for instance, and other log views do not show anything.

After restarting all services (either after reboot or via console, option 11), dpinger fails to start as well as dhcpd6 and radvd.

Routes are configured statically .

Any ideas?

Thanks in advance.

I ran into the very same situation: After updating the official recent installation image (18.7, amd, vga from the OPNsense website) to 18.7.9, after a reboot the web GUI failed to start! The problem seems symptomatic for this update, it happened on two test sites were we try OPNsense. Most frustrating, one site is remote and ssh is disabled.

As the thread indicates, the last question was how to revert the binding to a specific address/interface? I guess the last response is a kind of ironic, since no web GUI, no chance to change. Funny.

Is there a way to configure/uncheck this manually?

Regards