OPNsense 19.1 released update!

[4r7ur]

First of all: thank you for your great work and this excellent product!

Just upgraded to 19.1 on one of my two APU2C4. Upgrade took about 15 minutes and no issues so far. Configuration set up with 2 wan connections (although currently only one is in use), OpenDNS, OpenVPN site 2 site, vlans.

[Edit: unattended upgrade on 2nd APU in remote location also completed without issues]

[lattera]

Can you post a backtrace with the `bt` command (without the backticks)?

@lattera at the 'db>' prompt, it seems the keyboard mapping gets all messed up.  When I hit 'b', it actually prints 'mm'. When I hit 't', it prints 'zz'.  It then seems to get all locked up and non-responsive as I try different keys.  I tried in safe mode, but same thing.  Tried a different keyboard with the same result.

Ah, this is a problem that has plagued FreeBSD for a while. I take it your keyboard is not a US ASCII keyboard?

[Steven]

I had a failed upgrade on an APU2C4 I had to manually resolve. I logged into the serial console to fix it. I would received the following error that would stop the required reboot for upgrade:
Cannot 'stop' flowd_aggregate. Set flowd_aggregate_enable to YES in /etc/rc.conf or use 'onestop' instead of 'stop'.

System would hang at that message and them timeout. If I was in the WebGUI it would timeout and reset the WebGUI to the dashboard, and if I was in the root console it would timeout and reset the console back to the menu options.

I did two things to fix the issue, so I'm not sure what fixed it:

• I recently turned off and cleared all my NetFlow > Capture settings because I no longer wanted to use it. I suspect that didn't properly remove some items from startup and stop scripts so I re-enabled it and set everything back up for NetFlow.
• I went to shell and did a "shutdown -h now" to force a shutdown

[erickengelke]

I upgraded to 19.1 tonight at 6 and have been struggling for the next six hours.

Some IP connects get through but not others.   My provider is solely IPv4, I've disabled IPv6 in all the locaitons I could find, but no difference.

I can get PINGs through to my work subnet 129.97.50.x, but I cannot ssh there from my NATed subnet, though I can ssh there from SSH from a shell in my OpnSense box. 

And I get my client VPN client to work when I want it to, that works all night,  but I can't Google or Netflix without my VPN client ever tonight. 

So something is selectively disabling NAT through connections, but I don't know what.   I don't have any firewall rules.  I've done clean installs, but it stilll fails.

BTW, my OpnSense box is an i3 with two realtek cards. 

Very weird.  I;ve reinstalled several times, no luck.  Unfortunately, I can't find an online copy of 18.x or I would downgrarde temporarily, all you have listed is 19.1, which is a bit  optimistic on a new release.

Thanks for any advice you can give.
Erick

[erickengelke]

More on the case I mentioned where NAT's not working: ssh to a work server from my laptop behind opnsense times out, but the TCP connection is marked as established.  So the Syn and SYN ACK get through, but not the subsequent data.

Erick

[erickengelke]

More on my problem.  Looking at packet captures, I see the data coming in from the LAN side, but nothing is generated going to the outside interface for that IP address.   But it works for some addresses, because I can turn on a VPN. 

Very strange.
Erick

[mimugmail]

Can you check this one? Also using Realtek

https://forum.opnsense.org/index.php?topic=11425.0

[skyeci2018]

Updated via console. No issues to report so far.

[iam]

Hi,

I've upgraded two systems (PcEngines APU & APU2). On the APU there is IPv6 enabled. After the upgrade the APU has no public IPv6 anymore. On the APU2 there was no IPv6 configured because this caused problems with the PPPoE WAN connection.

Cheers,
iam

[mb]

I just saw, it might be Sensei blocking the upgrade...

For OpenSSL:

# opnsense-update -fp -n "19.1\/latest"

Or LibreSSL:

# opnsense-update -fp -n "19.1\/libressl"

worked for us (Sensei installed). I guess it was because of the typo in the command.

Any Sensei users, who are having any issues while upgrading to 19.1, please refer to this thread:

https://forum.opnsense.org/index.php?topic=9521.msg51688#msg51688

Just upgraded two of our firewalls to 19.1, went flawless. Thanks :)

[stoked-security]

Just upgraded my OPNsense VM running on ESXi 6.7 from 18.17.10_4 to 19.1 and also experienced the kernel trap 12 error.  I've run a backtrace as requested, here's the output:

Code Select Expand


db> bt
Tracing pid 0 tid 0 td 0xffffffff8202d260
fpuinit() at fpuinit+ox179/frame 0xffffffff81c1fbd0
hammer_time() at hammer_time+0x11cb/frame 0xffffffff81c20070
btext() at btext+0x24
db>


[Davesworld]

Mine went painlessly on both a fanless machine with a Jetway NF592 Motherboard and an Intel  Core i7-7700T running in non hyperthreaded mode and my second machine running a Jetway NF9J-Q87 with an Intel Core i5-4570S. Both are running ZFS. The first one running ZFS with the equivalent of Raid 6 on Six M.2 drives since the board has six SATA ports. The second one running ZFS in mirrored RAID.

Franco or anyone who cares to opine, what is the consensus on hyperthreading with an edge appliance? I have it turned off in which case a quad core Core i5 would be all one would need.

[lattera]

From a security perspective, it really depends on your threat landscape. I don't think the average person is likely to see network-based attacks targeting the various microarchitectural vulnerabilities plaguing SMT and speculative execution as of late. However, if you feel that you might be of interest to someone with the ability to carry out successful attacks remotely, it'd be best to leave SMT disabled.

In short: determine your risk and plan and mitigate accordingly.

[Davesworld]

From a security perspective, it really depends on your threat landscape. I don't think the average person is likely to see network-based attacks targeting the various microarchitectural vulnerabilities plaguing SMT and speculative execution as of late. However, if you feel that you might be of interest to someone with the ability to carry out successful attacks remotely, it'd be best to leave SMT disabled.

In short: determine your risk and plan and mitigate accordingly.

The only other question is whether or not there is any performance advantage for a firewall/router to use hyperthreading or if it is even utilized by anything in this OS.

[Deku]

Ah, this is a problem that has plagued FreeBSD for a while. I take it your keyboard is not a US ASCII keyboard?

No, it is a US ASCII keyboard.  Default Dell Keyboard.  Sorry for the delayed response - was out of the office for a couple weeks.  I was able to set up a new system on 18.7.10 with the backup config before I left.  Now I'm back to try and rebuild it and test.