Messages

Well, it seems like the system is still stable, so I guess it's time to look for other packages.

Performed the update and reboot.

Code Select Expand

FreeBSD <redacted> 11.0-RELEASE-p17 FreeBSD 11.0-RELEASE-p17 #0 14a0f7db3(stable/17.7): Tue Dec 12 03:19:44 CET 2017     root@sensey64:
/usr/obj/usr/src/sys/SMP  amd64


I don't know if I want to keep my fingers crossed that something crashes, or that nothing happens. : /

I'd like to get to 5 days of uptime before going all-in on diagnostics, just so I can be reasonably sure that the problem has gone away with this version. 2 days is statistically a little thin for my taste, even with the previous frequency of crashes.

If you have the time right now though, please do give me the directions on what to do once I've hit that benchmark, and I'll get it done.

My experience is more with Gnu/Linux and not *BSD, so please bear that in mind. Thank you.

Still ticking upwards on uptime.

In the upgrade I performed, I didn't make any config changes. If there were any, it would have been in migrations done during the upgrade, and not something I changed myself. (I also would have reverted them first instead of pestering you on the forum). I saved my config.xml from the 17.7.11 and pushed that to the 17.7.5 without issue, so if it were a configuration issue I gave it the perfect chance to persist and vex me. So far it hasn't.

The system is a Jetway embedded device with passive cooling. It's environment hasn't changed.

I hear what you're saying about hardware issues and such (I've been a PC technician for 15 years) but the rollback seems to have stopped the reboots, pointing at a software issue, not a hardware one.

Stability so far with 17.7.5 is much enhanced, with no spurious reboots. 1.7.7.11 had 2-4 reboots a day. Continuing to monitor.

It wasn't.

I found instructions on how to enable it in freebsd and set the partition as swap in the fstab file.

Is there anything else I need to do?

Did you restore an old config after doing your initial setup? Only thing I can think of.

Alright, I've re-installed opensense with 17.7.5 (I was running 17.7.6 before the upgrade, so this should suffice) and I'll observe its relative stability for several days before reporting back.

I used the manual option during partitioning (which forced me to break out a calculator to use since it made me deal in raw sectors? Didn't realize the manual option was this unpolished) and unless I missed it it never gave me the chance to assign the 1GB I set aside as a swap partition.

Was there something else I should have done? Or is setting up a swap partition a 'custom' post-setup step?

I'm guessing a /dev/mdNN device isn't a real swap partition?
The issue started after upgrading to this .11 release. I'll try walking it back a few and going from there I guess.

My opnsense running 17.7.11 crashes every 8-10 hours ( I hear the boot chime going off) and when I look in the system.log in the gui all I see is stuff like

Code Select Expand

kernel:

and

Code Select Expand

kernel: OK

just before the usual boot messages.

I gather that actual dump files aren't enabled, but I can't seem to find an option anywhere and the documentation wiki says nothing about it (search for 'crash' just gives irrelevant results).

The contents of /var/crash are a 'minfree' file that contains the string "2048". The webgui reporter says that everything is fine.

I memtested the machine, which has been running opnsense steadily since 15.x, and found no issues.

I have the same hardware you do, with a similar config, but haven't updated it yet to the 17.x releases.

Definitely hoping the production software works better for you, or I'll be using 16.x for a long while yet.

Okay...I suppose that's true. I'm comfortable enough with opnsense that I generally don't enable the help text, so it would be useful if those links were simply shown by default, especially if the installer is to be removed.

You and me both man. I had the exact same issue, couldn't ever make it work, had to go with a similar alternative 'cause no answers were forthcoming.

I wonder if a setup like this is part of the testing framework opnsense uses? Seems like a fairly common use-case that isn't getting attention.

Easy things to check are that the OpenVPN is configured to listen on the proper interface, which since you had a multi-WAN before might not have defaulted to a sane value after removing the previous multi-WAN setup.

Or you might try destroying the current OpenVPN server and re-creating with a new one that never had the multi-WAN at all.

If you have a TAP set up, make sure your Bridge interface is still set up properly.

You can also try (though I assume you have already done so) making sure the clients are up to date.

Essentially, if the firewall rules are correct, which you say they are, then the next-most-likely source of error is the config of the server itself.

Just as some user feedback, I would prefer a link to the official OpenVPN binaries in the client export section if opnsense isn't going to track and ship them itself. The plugin isn't a bad idea either, but I don't personally consider "just use Viscosity" as an alternative, as it is not Libre software.

As an aside, one of the reasons that I migrated away from the Sophos UTM (which was Astaro before that) software was the ridiculous licensing requirements for "commercial" use of OpenVPN and other features that are themselves libre software.

I will pay for human support; I will not pay for "integration" work that just amounts to slapping a gui on a tool/service, much less $xxxx/yr because you have 50+ total clients...

Maybe that just makes me a jerk, but whatever.