Messages

[only]

Actually, the system has only fixed IPs.

However, I haven't yet found out how to make it not acquiring an IPv6 in addition per interface - hence either there is the chance to set this (somewhere) and not in form of an OS configuration which is not saved, or at least from my point of view, the whole "Interface" selection is, in terms of IPv6, buggy.

[Network Interfaces]

If you configure Network Interfaces in Unbound DNS/General to use specific Interfaces and if you are using IPv6, Unbound DNS does not start...

When trying unbound -c /var/unbound/unbound.conf it appears that unbound can't bind (a) IP adress(es)...

The issue is the same as I described it under https://forum.opnsense.org/index.php?topic=33815.msg176314#msg176314. Due to the IPv6 configuration and (correct) protocol behavior and a - as I see it meanwhile bug in the current Interface, the Webconfigurator does, replicable, add a dynamic IPv6 address per interface to the configuration.

If, at reboot for example, the dynamic IPv6 changes (which is in default IPv6 configurations very likely and according to the protocol, wished / accepted), the configuration doesn't... unfortunate that the IP is then not existing on the specified interface and therefore the service can't bind it...

The issue does not appear if you leave Network Interfaces to reply on all interfaces. And again, the drop-down behavior is buggy, it does save 'changes' as described in the linked forum entry above :(

Temporarily work-around:
* fix the configuration file
* don't open the Webconfiguration Page of Unbound DNS

[/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf]

I had the same issue. Indeed I choose only a few interfaces from on Settings/Administration page (/system_advanced_admin.php) at "Listen Interfaces".

I configured my system with IPv4 and IPv6 as fixed IPs for (all) interfaces when possible and using virtual IPs on internal interfaces too, to realize at least one fixed IPv6 for each firewall interface. I haven't had IPv6 protocol behavior in mind if doing so which led to the above problem as I just found out.

What happened is, that the OPNSense interface did configure "/var/etc/lighty-webConfigurator.conf" and here the server sockets to these fixed addresses in IPv4 and IPv6 - and, sadly but correct, added the at the time of configuration given IPv6 address of that interface in addition to the configuration file ::)

If I am asked, I would suggest to at least ask the user, if virtual and or fixed IPs are configured, whether the dynamic IP address should be used as well - or alternatively, change that one each time the interface IP changes or the system reboots... (the first one would be proficient enough if it comes to me ;))

Correct behavior though ugly since from time to time, IPv6 adresses may change, e.g., during a system reboot after an update... Since the then expected IPv6 is not available to the specific interface, (re-)starting the WebGUI fails, it surely must fail.

In my case, I simply removed the entries in question from /var/etc/lighty-webConfigurator.conf, saved it and restarted the WebGUI according to @francos' answer in https://forum.opnsense.org/index.php?topic=9128.0 by using /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf afterwards.

Restarting the WebGUI via command line from /usr/local/etc/rc.restart_webgui
which I found at https://forum.opnsense.org/index.php?topic=1188.03, also by @franco, does work if the webConfigurator configuration file is valid. Same for using root console menu option (11).

As said, the problem by doing it the rc.restart or root console menu option (11) way is, there is, except for Starting web GUI...failed. or alternatively no hint at all :( no further note nor error message. You need either to dig yourself through the log-structures or start it as described above.

One last thing I found during my research and find it at least 'a bit annoying', if it should not be considered a bug is:

• Click on the Settings/Administration page (/system_advanced_admin.php) at "Listen Interfaces" drop-down is enough to change the configuration file, you do not need to change anything, just having a look on the configured stuff
• Independent whether you click Save at the end of the form or don't it saves the 'changes' you made from Listen Interfaces... I would bet that is on other pages the same thing - and it can be extremely frustrating when searching for reasons for issues like the here described.

I find this issue annoying since OPNsense 23.x.y-amd64 and it is still the case for OPNsense 23.7.5-amd64 with today's updates.

Temporarily work-around:
* fix the configuration file
* don't open the Webconfiguration Page of the service

Have you installed IDS plugin?

I had similar issue and noticed plugin wasn't installed.

As to my understanding, Suricata (IDS) is installed by default, except for the et_telemetry.token and the corresponding plugin for telemetry, I didn't also find a way to re-install it. However, as to my understanding from the answer that followed yours, this seems to be a known bug and should be fixed in 20.7.3 according to @mimugmail.

However, I did re-install the telemetry install after your answer here, it however didn't change the behavior.

Even though this is an older error, I do have, with OPNsense version (OPNsense 20.7.2-amd64
FreeBSD 12.1-RELEASE-p8-HBSD OpenSSL 1.1.1g 21 Apr 2020), a similar issue, except I do see the rulesets I wish to download, but can't with an error message (see screenshot) that is as worthy as saying nothing: Error reconfiguring IDS, Error (1)...

I do have the same issue - here it is even getting worse thanks to Multi-WAN, which is obviously an additional problem. A backup connection seems not to be part of the concepts in OPNsense if it comes to IPv6 - works however great in IPv4...

When I used pfSense before I decided to go to OPNsense due to its, from my point of view, better security policy when it comes to updates, etc., I was warned that - whysoever - IPv6 is in many cases a problem with OPNsense. And I must say, indeed, it seems to be still a problem.

I tried everything here, also I am in the situation to have different opportunities to test:
* Single WAN with Vodafone Cable in Germany
* Multi-WAN with Vodafone Cable and T-DSL business in Germany
* Single WAN within a Hetzner DC on different system configurations (e.g. HW and SW)
* Multi-WAN with COLT and Telekom (both fibre) in Germany

Where I use Multi-WAN, to figure out the issues, I tried a single-WAN configuration and found that it is more likely to work with Telekom and Colt than with Vodafone Cable. The ladder is due to some configuration obstacles with Vodafone Cable installations. The Single WAN Vodafone Cable works, however meanwhile stable and the Multi-WAN Vodafone Cable is at least steady providing IPv6/56 as well.

As here described, IPv6 works always from the FW itself, except for Hetzner where a number of more configuration things had to happen and some problems between COLT and OPNsense machines, with same HW the things here worked however like a charme with PF as FW system....

The routing of packages from the internal network to external network(s) in IPv6 is like playing Roulette, it works from time to time without clear evidence why, it is independent whether I
* reboot the FW
* restart only the services
* clear all states
* or do all this together  :o

I also tried at all places just Single-WAN, single internal network. This worked with Telekom connections like a charme, multiple internal networks as well. All testes with IPv4/IPv6 lazy networking rule (all allowed).

Exchanging the Telekom connection with any other connection, works in so far from time to time if a reboot isn't happening... a reboot is like 'rien ne va plus' in Roulette... the outcome is as with Roulette, you seldom win.

So I investigated the Telekom connection and tried to figure out whether there are 'significant' differences in the protocols - not at all there is something I could find; which doesn't say anything since I am far, far away from being a networking or firewall expert.

Same configuration works with pfSense as expected; both OPNsense and pfSense where tested with most recent updates, versions etc...

I had such issues with pfSense a year ago, including some security related issues - which where the reason to give OPNsense a chance before going to the 'established' Enterprise stuff, and costs... and security issues,....

So I still hope that OPNsense get's the issue solved.

I am happy to provide any information, configuration etc. needed - even test access for one location for the developers - to finally get the IPv6 issue solved.