Messages

Hi all,

I finally made the move to OPNsense from having using a plain Linux system for decades. So while not new in the field, I¨m still learning about the OPNsense (and BSD) way of doing things. Many thanks to all that have contributed to this over the years.

The OPNsense router/firewall has multiple WAN's. All traffic via one of those WANs needs to go via an OpenVPN tunnel, so that OpenVPN's tunnel is taking part in my gateway groups, not the WAN itself. This all works reasonably well, except for the fact that when that WAN goes down, the VPN reroutes via another WAN despite me trying to restrict that to one specific WAN only. This is not a big issue though, just not as tidy was I would like it.

What is of more concern is that when the WAN comes back online, OPNsense doesn´t see that. When the WAN is offline, OPNsense shows RTT=0.0ms, RTTD=0.0ms, loss=100%. This remains so when the WAN comes back onilne (the requested IP address, by DHCP in this case) is shown and the WAN surely is online. A restart of the dpinger process for that particular gateway  resolves the issue (ie. signals that the WAN is back online).

In this particular case, the physical ethernet link stays up (as OPNsense is connected to a switch) when the WAN is down.

It looks to me like a bug in/around dpinger. While I put that forward for your consideration, is there a way to restart the dpinger process, preferably only for a specific gateway, via the commandline / cron? I'm looking for ways to have this work fully automatically and reliably, ie. if this particular WAN disappears, the OpenVPN tunnel should go down (not reroute via another WAN). When this particular WAN reappears, the OpenVPN tunnel should be re-established. If that is difficult to implement with OPNsense, then it's fine if the OpenVPN tunnel reroutes via another WAN as long as it goes back to the WAN it is supposed to go through when that reappears.

It very simple for me to reproduce, so will happily test potential fixes.

Any ideas / suggestions are most welcome.

Regards,
Jan

Hi all,

Running 24.1.10 and running out of hours I can spend on trying to get Wireguard to work reliably so back to the good old trusted OpenVPN it is for the time being.

I noticed that OPNsense adds this route:

0.0.0.0/1 link#39 US wg0

My intention is that nodes on the LANs can use a gateway group with the wg0 interface being one of the gateways and for that to work I need to add 0.0.0.0/0 to the AllowedIPs.

Does anyone know what the logic is for adding that 0.0.0.0/1 (ie. (only) half of the internet) route?

Hi,

For what it's worth I'm struggling from what seems the exact same issue. First I thought I must have missed something obvious but now I'm no longer ruling out that this is a bug. I added 0.0.0.0/0 to the AllowedIP (in addition to the internal WG subnet) which then works for a while. Sometime during the night, OPNsense changed that route to 0.0.0.0/1 (??) and the Wireguard gateway (I intend to use Wireguard as one of the available gateways / WANs went down.

I haven't put my finger on it yet, but am fairly sure that there is something not quite right with the Wireguard subsystem.

Jan

Hi Franco,

pkg check -da

shows missing dependencies
hostapd is missing a required shared library: libssl.so.9
hostapd is missing a required shared library: libcrypto.so.9
pkg: No packages available to install matching 'openssl102' have been found in the repositories

pkg check -sa

shows heaps of checksum mismatches.

I have a few plugins from the OPNsense repositories. No self-built ports or customisation; everything is out of the standard box. After:

pkg update
pkg upgrade

I got OPNsense back up & running.

Then I ran the update from the webinterface once again and am now running 20.1.5. As far as I can tell the configuration of the system has been retained successfully.

Not sure what went on here though...!

Thanks for your help!

regards,
Jan

Hi Franco,

Thanks for the quick response :-)

After bringing OPNsense online, I did:
# opnsense-bootstrap
# reboot

and I end up with the same Fatal Error. In other words opnsense-bootstrap completed very quickly (didn't appear to download anything from the internet or did it with the speed of light).

What could be the reason for not retaining all files during the upgrade? The system surely has stable power.

Jan

Hi all,

The upgrade of an OPNsense firewall from 19 -> 20 just failed. I am running OPNsense as VM on a Xen host, which has worked beautifully since 17.x or so. I initiated the upgrade in the evening and noticed the firewall was unresponsive in the morning after which I virtually powercycled the VM.

The boot process crashes with a Fatal Error:
Uncaught Error: Call to undefined function OPNsense\Core\ctype_digit() in /usr/local/opnsense/mvc/app/library/OPNsense/Core/Config.php:82.  Line 82 contains:

return ctype_digit(implode('', array_keys($arrayData)));

See attached screenshot.

Any suggestions how I can pull OPNsense off the ground?

kind regards,
Jan

Hi all,

I've having consistent (ie. on different hardware) trouble running OPNsense as Xen (open source) guest with more than one network interface. With one interface, OPNsense boots fine but as soon as I add another network interface, OPNsense get's stuck during the boot process and remains unresponsive (presumably because the network interface has not been brought up yet). Any suggestions?

Jan

Hi Franco, Mimu,

Thanks for your reply!

kind regards,
Jan

Hi,

First of all thanks for 18.1!

I've started to use OPNsense to manage a whole bunch of Certificate Authorities and Certificate/Key pairs. It would be great if it would be possible to enter a filter that only shows names matching that filter. Sorting / grouping on issuer would also be very useful.

thanks,
Jan

Hi,

OPNsense 17.7.10-i386
FreeBSD 11.0-RELEASE-p17
OpenSSL 1.0.2n 7 Dec 2017

I found this post https://forum.opnsense.org/index.php?topic=5308.msg21559#msg21559

but the patch mentioned in there is no longer available (dead link). Also the post was related to 17.1 Legacy - I guess the patch has since made it into OPNsense?

configd.py: [8b5c1824-7d7e-486c-8960-c47ba994b321] Inline action failed with OPNsense/Netflow OPNsense/Netflow/rc.conf.d 'collections.OrderedDict object' has no attribute 'targets' at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 507, in execute return ph_inline_actions.execute(self, inline_act_parameters) File "/usr/local/opnsense/service/modules/ph_inline_actions.py", line 50, in execute filenames = tmpl.generate(parameters) File "/usr/local/opnsense/service/modules/template.py", line 321, in generate raise render_exception Exception: OPNsense/Netflow OPNsense/Netflow/rc.conf.d 'collections.OrderedDict object' has no attribute 'targets'
Dec 20 09:10:08    

kind regards,
Jan

Hi Franco,

Would you be able to give me a rough estimate when you think this bug might be resolved?
I'm evaluating various systems and would very much like to keep OpnSense on the list...
Please let me know if I can help with this.

kind regards,
Jan

Hi Franco,

Many thanks, looking forward to hearing from you. It's quite easy for me to reproduce (just clicking around in the web interface seems to be sufficient); let me know if I can help beta test a new kernel.

Jan

Hi Franco,

Hope the "bt" output helps to close in on the problem?
Please let me know if there's anything I can do to help,
At this stage the trap is a show stopper for me...

kind regards,
Jan

Hi Franco, ngo,

Sorry for the delay in my answer. Please see the output of "bt" attached. I've left the VM sitting at the debugger prompt, just in case you need more info. Happy to help debug this further with a debug kernel. I have many years of experience with Linux but unfortunately not much with FreeBSD. Am a reasonably quick learner - well at least I like to think I am ;-)

Jan

Hi all,

A Google search for "xen freebsd trap 12" has many results... it seems I'm not the only one having that problem. When OPNsense boots I see that it realises it's running on a hypervisor and subsequent is disabling TCP offloading. My gut feeling is that this is a problem in the FreeBSD Xen drivers. I'll keep digging - I like what I've seen so far from OPNsense and would like to make it work.

Jan