Messages

1

24.1 Legacy Series / Properly recover from WAN outages (dpinger bug)?

« on: August 04, 2024, 01:15:25 am »

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

2

24.1 Legacy Series / Re: 24.1.2 Wireguard does not work after updating

« on: July 20, 2024, 02:05:34 am »

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?

3

24.1 Legacy Series / Re: Wireguard issues after upgrades now leads to weird issues...

« on: July 18, 2024, 11:08:15 pm »

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

4

19.7 Legacy Series / Re: Upgrade 19 -> 20 fails (RESOLVED with a few manual steps)

« on: April 29, 2020, 02:30:49 am »

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

5

19.7 Legacy Series / Re: Upgrade 19 -> 20 fails

« on: April 27, 2020, 11:48:25 pm »

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

6

19.7 Legacy Series / Upgrade 19 -> 20 fails

« on: April 27, 2020, 03:44:27 am »

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

7

18.7 Legacy Series / OPNsense as Xen guest - only one interface?

« on: March 27, 2019, 02:08:34 am »

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

8

18.1 Legacy Series / Re: [FEATURE REQUEST] Sort / group / filter Authorities and Certificates

« on: February 17, 2018, 12:57:10 am »

Hi Franco, Mimu,

Thanks for your reply!

kind regards,
Jan

9

18.1 Legacy Series / [FEATURE REQUEST] Sort / group / filter Authorities and Certificates

« on: February 02, 2018, 01:15:36 am »

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

10

17.7 Legacy Series / Issue with NetFlow

« on: December 19, 2017, 09:19:32 pm »

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

11

17.1 Legacy Series / Re: Fatal trap 12

« on: April 25, 2017, 07:44:59 am »

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

12

17.1 Legacy Series / Re: Fatal trap 12

« on: April 06, 2017, 02:41:31 am »

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

13

17.1 Legacy Series / Re: Fatal trap 12

« on: April 05, 2017, 06:15:27 am »

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

14

17.1 Legacy Series / Re: Fatal trap 12

« on: April 01, 2017, 09:43:49 am »

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

15

17.1 Legacy Series / Re: Fatal trap 12

« on: March 27, 2017, 10:18:05 pm »

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