Messages

Hi,

after working for quite a long time, zenamor has stopped working for me some weeks ago following the latest major update. What essentially happens is nothing. While I can have a look at open web/dns/tls/... sessions (so it appears to be intercepting traffic), nothing is blocked or "protected" at all anymore.

The best guess I have about this is because in the new configuration my wan interface em0 is missing, see the attached screenshots.

Any ideas?

I know, this is an old thread, but any news on this?

Just wanted to give zenamor a try, but unfortunately the installation wizard doesn't even let me install it because of the jumbo frames.

Thanks.

Isn't this blowing a bit out of proportion?  :)

If I understand correctly, the OP simply suggested to make the wording in the release notes a bit more firm, i.e. along the lines of: "If a realtek NIC is used, install the driver before doing any update".

At least to me this doesn't seem like some unreasonable demand or blaming of the developers, but rather just a friendly suggestion to avoid more threads like this one. :)

I think this perfectly describes my intention. The last thing I had in mind was to blame anyone for anything.

At least in my opinion, after following the release notes for the update, I lost connectivity to 3 boxes after a while.

The flow of events was this:

1. The 22.1 release notes state this: "If unsure whether FreeBSD 13 supports your Realtek NIC ..."
2. So, I checked with FreeBSD if it supports my Realtek NICs and yes, FreeBSD 13 claims to support them, and I was assured that the NICs would work in opnsense 22.1 then
3. upgraded to 22.1
4. tested connectivity and all looked nice, then upgraded two more boxes and left the location
5. after a couple of hours, box by updated box lost network connectivity

That's why I thought it might be a good idea to warn others more explicitly that checking with FreeBSD if the NICs are supported or not might not be enough.

Peace.

LOL well then, if updates breaking production systems leads to irrelevant discussions about how unfair the word is, then so be it!

Really enjoying your professional tone! Enjoy your Sunday!

The issue is that the vanilla FreeBSD driver claims to support the devices. So if you go and check, things look fine at first when using with the FreeBSD driver and at least according to your release announcement, this should suffice.

But issues start to surface hours later, when you maybe have long left the physical site where the firewall is located, without the chance to intervene. So you need to go back and install the vendor driver (like I just had to do).

At least for my taste, this is a little bit too much trial and error for a production release.

Hi,

like some others, I have also been bitten by the realtek driver issue. Before upgrading to 22.1, I read the announcement that the vendor driver had been dropped in favor of the original FreeBSD variant and that I should have a look, if the FreeBSD driver supported my NIC. Here's what the release announcement says https://forum.opnsense.org/index.php?topic=26536.0:

The Realtek vendor driver is no longer bundled with the updated FreeBSD kernel.  If unsure whether FreeBSD 13 supports your Realtek NIC please install the os-realtek-re plugin prior to upgrading to retain operability of your NICs.

And so I did, I verified that my NICs were supported by the vanilla FreeBSD driver and so I decided that using the os-realtek-re drivers was not necessary and instead I gave the FreeBSD drivers a try.

Code Select Expand

re0@pci0:2:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:3:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet


Unfortunately, like some others have noticed, too, the FreeBSD driver would work for a while but then just drop all connections, constantly toggling between UP to DOWN state.

So at least from my POV, it might be a good idea to tell people that checking if the vanilla FreeBSD realtek driver supports a NIC or not is not sufficient and that things may break randomly any time later.

And if I could choose, I'd rather stick with the os-realtek-re vendor driver for the time being, until it is clear, which NICs are not only (allegedly) supported but also known to be working with the vanilla FreeBSD driver.

From time to time, the captive portal stops to work and the log show this:

Code Select Expand

Traceback (most recent call last): File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/cp-background-process.py", line 207, in main bgprocess.db.cleanup_sessions() File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/lib/db.py", line 403, in cleanup_sessions """) sqlite3.DatabaseError: database disk image is malformed

This seems to have been an issue occurring for a long time, see https://forum.opnsense.org/index.php?topic=12843.0 for example.

The solution laid out there is pretty brute force, however. Instead of deleting the database altogether and losing all session and state information, the right way to do it is to simply repair the database:

1. stop the captive portal
2. move away the broken database

Code Select Expand

mv /var/captiveportal/captiveportal.sqlite /var/captiveportal/captiveportalbad.sqlite
3. recover the database

Code Select Expand

sqlite3 /var/captiveportal/captiveportalbad.sqlite ".recover" | sqlite3 /var/captiveportal/captiveportal.sqlite

There is nothing special about running it on proxmox. I'm running a number of opnSense VMs under proxmox.

What kind of special issues do you expect when running under proxmox?

investigating further, I found that syslog is broken in the latest 20.1 version

https://github.com/opnsense/src/issues/49

... and that 20.7 solves the issue, so that's what I will do :)

I just noticed, that the firewall stopped logging after I upgraded on of our firewalls to the latest 20.1 version (OPNsense 20.1.9_1-amd64) some weeks ago.

Neither the live view nor the plain view show new log data, only data from before the upgrade.

Any ideas what how to debug the issue appreciated :)

Hi,

I run OPNsense 20.1 in a proxmox 6.1 virtualized environment on a GA-IMB310TN mainboard with two on board Intel NICs.

Unfortunately, my WAN download speed refused to exceed 12 or 13Mbit, usually it was even lower, despite my 200Mbit uplink speed.

I've tried a lot of things, changing drivers from virtio to e1000e, PCI passthru of the physical NIC, FreeBSD tuning guides and a lot more, all to no avail.

After days of trial and error testing I finally found a solution, maybe it will help someone in the same situation:

The trick is to disable hardware checksum offload and hardware TCP segmentation offload on the physical linux (=proxmox) side as well.

This can be done by changing the WAN bridge configuration in /etc/network/interfaces in proxmox like this:

Code Select Expand

auto vmbr1
iface vmbr1 inet manual
        bridge_stp off
        bridge_fd 0
        bridge_ports eno1
        pre-up ethtool -G eno1 rx 1024 tx 1024
        pre-up ethtool -K eno1 tx off gso off
        post-up ethtool -K vmbr1 tx off gso off
#uplink

As you see, the settings are made both for the bridge vmbr1 and the physical device eno1. The eno1 NIC is a Intel Corporation Ethernet Connection (7) I219-V, controlled by the e1000e driver. No idea if the same applies to other hardware, too. To be honest, I've actually never had a problem like this even though I have virtualized a lot of OPNsense installations.

All the credits for this nice workaround go to this subreddit: https://www.reddit.com/r/PFSENSE/comments/842unp/having_an_issue_with_virtualized_pfsense_speeds/

Cheers

I've an issue that has bothering me for quite some time, and each time I thought it had been solved by some update, it reappears again. So maybe someone here can shed a little light on my problem.

OPNsense is connected to the internet using a Netgear LB1110 4G LTE Modem, which is configured for bridge mode, so OPNsense gets a routeable, public IP address via DHCP from the ISP.

Now, from time to time OPNsense loses internet connectivity and marks the gateway as "offline" in System->Gateways->Single

At the same time, if I look at Interfaces->Overview->WAN interface, I see that both status and DHCP are "up".

My first idea was an issue with gateway monitoring, and so I checked in System->Gateways->Single, if "Disable Gateway Monitoring" was active, but it was not and I see dpinger up and running. I've also entered a dedicated "Monitor IP", but to no avail.

I can manually "fix" the situation by either releasing or renewing the DHCP connection in Interfaces->Overview->WAN interface, but manual intervention is the last resort.

I've hacked together a simple cronjob checking connectivity every minute and restart the DHCP connection, if the connection goes down, but I really hope there's a better solution to this :)

Ah yes, and this currently happens on a 19.1.6 installation, but it has also happened previously, IIRC with 18.x versions, too.

Any ideas?

happens on my stable FF 45.1.0 as well.

Workaround is to enable decoding URL hashes:

• open 'about:config'; in the address bar
• search for dom.url.getters_decode_hash
• change its value to "true"

confirming as well, the downgraded package solves the issue for us, too

ok, thanks, an updated package sounds good. My architecture is amd64/OpenSSL.