Messages

1

24.7 Production Series / renewed user certificates are not (visibly) linked to the users anymore

« on: November 24, 2024, 04:08:03 pm »

Some releases ago, we got the new "renew certificate" feature in System->Trust (via edit->"reissue and replace certificate").

We mostly use certificates to authenticate users against the OpenVPN instance running on OPNsense and the renewal itself works just fine. What seems to get lost however is the link to the users. The "in use" column shows that most certificates don't appear to be "used" when instead they do actually belong to an user, see the attached screenshot. Only original certificates created using Access->Users->User certificates have the user icon in the "in use" column. But once they get renewed, they loose the user icon in the System->Trust list and also, they are not listed in the user's profile page in Access->Users.

But OpenVPN nevertheless seems to correctly link them to the users. Looks like a bug to me, or is there a reason for this behaviour?

Thanks

2

High availability / HA when OPNsense also acts as a WAN router

« on: December 20, 2023, 03:56:28 pm »

Hi all,

I'm just planning a new OPNsense deployment where we have been assigned a public /28 network plus a public gateway address from a different /29 range. Both the public /28 network and the gateway are being managed by OPNsense, see the attached image for an graphic description.

So in other words, OPNsense acts as a router via the public 1.2.3.2/29 address and as a firewall for the /28 public addresses.

This has been working as a standalone installation for a while, but now I need to convert this into a more failsafe version.

As far as I understood from reading the docs, doing some research on the FreeBSD forums and google in general, the only thing that can be made highly available are the public /28 adresses, but not the gateway/router functionality. We've been assigned only one gateway address out of the /29 upstream network and afaik CARP on the other hand requires 3 public IPs to achieve HA. Is that correct or did I miss something here?

One way I can think of was asking to my ISP to assign us more than one IP from the /29 upstream network and then configure a different metric value for the two potential routes into our public /28 network in their routers, but I have no clue if they would do it and also, if I could make this work in OPNsense.

Another option I can think of is to squeeze a dedicated router between upstream and OPNsense, but that wouldn't exactly be highly available ...

Or is there another reasonable way to do this?

3

Virtual private networks / Re: OpenVPN peer2peer broken after update to 23.7.5

« on: October 07, 2023, 11:20:46 pm »

Alright, so after a day of debugging and trying to figure out what was doing on I also investigated the remote firewall settings that I was trying to connect to.

What helped there was to disable the OpenVPN address pool that was configured at the server side to keep client IP tunnel addresses stable over disconnects.

After disabling the pool on the server side (peera.example.com in my example), I could connect to the server from peerb.example.com as a client, now assigned a new peer to peer tunnel address.

So for the time being, things are working again, but I am still flabbergasted what went wrong after the update in the first place ...

4

Virtual private networks / Re: OpenVPN peer2peer broken after update to 23.7.5

« on: October 07, 2023, 01:14:44 pm »

thanks for that idea. From a network POV, I should be able to assign the same IP address to multiple interfaces (for very exotic configurations), but that isn't the case here anyways:

Code: [Select]

root@peerb:~ # ifconfig | grep -2 '10.19'
root@peerb:~ #
root@peerb:~ # ifconfig ovpnc1
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
groups: tun openvpn
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@peerb:~ # /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
ifconfig: ioctl (SIOCAIFADDR): File exists
root@peerb:~ #
root@peerb:~ # /sbin/ifconfig ovpnc1 10.19.0.16 10.19.0.15 mtu 1500 netmask 255.255.255.255 up
root@peerb:~ # ifconfig ovpnc1
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 10.19.0.16 --> 10.19.0.15 netmask 0xffffffff
groups: tun openvpn
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@peerb:/var/etc/openvpn #

... so how weird is that ... I cannot assign 10.19.0.6, but I can assign 10.19.0.16 ...

5

Virtual private networks / OpenVPN peer2peer broken after update to 23.7.5

« on: October 07, 2023, 11:24:00 am »

Hi,

after doing a minor update from 23.7.x to 23.7.5, one of our firewalls fails to establish a previously working OpenVPN peer-to-peer connection to another firewall. No setting has been changed and looking at the logs, I don't see much of a difference, except that after the upgrade I see a "FreeBSD ifconfig failed: external program exited with error status: 1", but have a look for yourself (IP addresses and host names etc redacted):

logs from before the upgrade:

Code: [Select]

<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="26"] WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="27"] DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="28"] OpenVPN 2.6.6 amd64-portbld-freebsd13.2 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD]
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="29"] library versions: OpenSSL 1.1.1v  1 Aug 2023, LZO 2.10
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="30"] MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="31"] WARNING: using --pull/--client and --ifconfig together is probably not what you want
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="32"] WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="33"] NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="34"] TCP/UDP: Preserving recently used remote address: [AF_INET]233.252.0.237:1195
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="35"] Socket Buffers: R=[42080->42080] S=[57344->57344]
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="36"] UDPv4 link local (bound): [AF_INET]233.252.0.103:0
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="37"] UDPv4 link remote: [AF_INET]233.252.0.237:1195
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="38"] TLS: Initial packet from [AF_INET]233.252.0.237:1195, sid=74dd58be 5cba6ac3
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="39"] VERIFY OK: depth=2, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com CA 2022, emailAddress=foobar@example.com
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="39"] VERIFY OK: depth=1, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com HTTPS CA 2022, emailAddress=foobar@example.com
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="39"] VERIFY OK: depth=0, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=peera.example.com, emailAddress=foobar@example.com
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="58"] Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="59"] [peera.example.com] Peer Connection Initiated with [AF_INET]233.252.0.237:1195
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="60"] TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="61"] TLS: tls_multi_process: initial untrusted session promoted to trusted
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="62"] PUSH: Received control message: 'PUSH_REPLY,route 172.21.1.0 255.255.255.0,route 172.21.254.0 255.255.255.0,route 172.16.5.0 255.255.255.0,route 172.21.7.0 255.255.255.0,route 172.22.0.0 255.255.255.0,route 172.22.1.0 255.255.255.0,route 172.21.253.0 255.255.255.0,route 10.9.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.19.0.6 10.19.0.5,peer-id 0,cipher AES-256-GCM'
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="63"] OPTIONS IMPORT: --ifconfig/up options modified
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="64"] OPTIONS IMPORT: route options modified
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="65"] ROUTE_GATEWAY 233.252.0.242/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="66"] TUN/TAP device ovpnc1 exists previously, keep at program end
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="67"] TUN/TAP device /dev/tun1 opened
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="68"] /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="69"] /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpnc1 1500 0 10.19.0.6 10.19.0.5 init
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="70"] /sbin/route add -net 172.21.251.0 10.9.0.5 255.255.255.0
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="71"] /sbin/route add -net 172.16.5.0 10.9.0.5 255.255.255.0
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="72"] /sbin/route add -net 172.21.1.0 10.9.0.5 255.255.255.0
[...]

logs from after the upgrade with the failing connection:

Code: [Select]

<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="26"] WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="27"] DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="28"] OpenVPN 2.6.6 amd64-portbld-freebsd13.2 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD]
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="29"] library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.10
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="30"] MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="31"] WARNING: using --pull/--client and --ifconfig together is probably not what you want
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="32"] WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="33"] NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="34"] TCP/UDP: Preserving recently used remote address: [AF_INET]233.252.0.237:1195
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="35"] Socket Buffers: R=[42080->42080] S=[57344->57344]
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="36"] UDPv4 link local (bound): [AF_INET]233.252.0.103:0
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="37"] UDPv4 link remote: [AF_INET]233.252.0.237:1195
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="38"] TLS: Initial packet from [AF_INET]233.252.0.237:1195, sid=ece7d1b9 47113c63
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="39"] VERIFY OK: depth=2, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com CA 2022, emailAddress=foobar@example.com
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="40"] VERIFY OK: depth=1, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com HTTPS CA 2022, emailAddress=foobar@example.com
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="41"] VERIFY OK: depth=0, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=peera.example.com, emailAddress=foobar@example.com
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="58"] Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="59"] [peera.example.com] Peer Connection Initiated with [AF_INET]233.252.0.237:1195
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="60"] TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="61"] TLS: tls_multi_process: initial untrusted session promoted to trusted
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="62"] PUSH: Received control message: 'PUSH_REPLY,route 172.21.1.0 255.255.255.0,route 172.21.254.0 255.255.255.0,route 172.16.5.0 255.255.255.0,route 172.21.7.0 255.255.255.0,route 172.22.0.0 255.255.255.0,route 172.22.1.0 255.255.255.0,route 172.21.253.0 255.255.255.0,route 10.9.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.19.0.6 10.19.0.5,peer-id 0,cipher AES-256-GCM'
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="63"] OPTIONS IMPORT: --ifconfig/up options modified
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="64"] OPTIONS IMPORT: route options modified
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="65"] ROUTE_GATEWAY 233.252.0.242/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="66"] TUN/TAP device ovpnc1 exists previously, keep at program end
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="67"] TUN/TAP device /dev/tun1 opened
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="68"] /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
<27>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="69"] FreeBSD ifconfig failed: external program exited with error status: 1
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="70"] Exiting due to fatal error

In the meantime, I've tried all kinds of things (like recreating the connection in new "Instances" page), but all to no avail unfortunately.

little update: when trying to initiate the connection directly on the shell, I see that ifconfig fails with "ifconfig: ioctl (SIOCAIFADDR): File exists":

Code: [Select]

# /usr/local/sbin/openvpn --log /var/log/foobar.log --errors-to-stderr --config /var/etc/openvpn/client1.conf
root@peerb:/usr/local # tail -5 /var/log/foobar.log
2023-10-07 12:46:27 TUN/TAP device /dev/tun1 opened
2023-10-07 12:46:27 /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
ifconfig: ioctl (SIOCAIFADDR): File exists
2023-10-07 12:46:27 FreeBSD ifconfig failed: external program exited with error status: 1
2023-10-07 12:46:27 Exiting due to fatal error

Any ideas?

6

Zenarmor (Sensei) / Re: zenamor missing wan interface em0 (and not blocking anything anymore)

« on: September 29, 2023, 09:33:27 pm »

Hi Beki,

thanks for the information. I wasn't aware that the WAN interface wouldn't be shown on purpose and subsequently didn't really check the new config UI, because I thought that all my issues were due to the "missing" interface.

However, after checking the available config options, it seems that I simply didn't configure any blocks and after enabling them, everything works now.

Thanks again!

7

Zenarmor (Sensei) / zenamor missing wan interface em0 (and not blocking anything anymore)

« on: September 29, 2023, 09:45:16 am »

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?

8

Zenarmor (Sensei) / Re: MTU Size - Jumbo's

« on: March 18, 2022, 06:27:29 pm »

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.

9

22.1 Legacy Series / Re: bring back the vendor realtek driver

« on: January 30, 2022, 07:22:38 pm »

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.

10

22.1 Legacy Series / Re: bring back the vendor realtek driver

« on: January 30, 2022, 02:12:39 pm »

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!

11

22.1 Legacy Series / Re: bring back the vendor realtek driver

« on: January 30, 2022, 01:21:14 pm »

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.

12

22.1 Legacy Series / bring back the vendor realtek driver

« on: January 30, 2022, 01:09:44 pm »

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]

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.

13

Tutorials and FAQs / Captive Portal: how to recover a broken database

« on: December 10, 2020, 10:24:43 pm »

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

Code: [Select]

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]

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

Code: [Select]

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

14

Tutorials and FAQs / Re: Installation on Proxmox - Good tutorial

« on: December 10, 2020, 10:16:08 pm »

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?

15

20.1 Legacy Series / Re: firewall stopped logging after upgrade

« on: November 03, 2020, 10:40:25 pm »

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