Messages

1

24.7 Production Series / Re: Multi-WAN gateway monitoring dashboard problem with virtual adapaters

« on: October 15, 2024, 11:37:30 pm »

OK, I know what you mean. I run latest version of OPNSense (24.7.6) with paravirtualized vtnet adapters (on PVE)  and I do not have this issue. When I unplug the physical network cable to DSL modem, OPNsense interface stays connected (plug symbol stays green), packet loss rises in the gateway stats and that green dot changes first to orange then to red. I do not think the issue has anything to do whether you use paravirtualized or physical/redirected NICs in your VM. I cannot recreate it here so cannot help anymore. But I believe it is some kind of misconfiguration somewhere.

2

24.7 Production Series / Re: Multi-WAN gateway monitoring dashboard problem with virtual adapaters

« on: October 15, 2024, 09:30:36 pm »

Yes, physical NIC state connected to Linux bridge does not propagate to (para)virtualized (not virtual :-) NICs. That would be undesireable in most server applications - that is where we use KVM. You want VMs always to be able to talk to each other, even if physical NIC link went down. You can always simulate link down for virtualized NIC if needed, by setting link down option for given NIC in VM's options.

Such propagation makes sense on desktop virtualization though. I'm not sure if WVware workstation has such option, VirtualBox has it for sure.

I'm trying to find a place in the dashboard you are talking about...
Packet loss is gateway's statistic, not network interface's. And it will be reported correctly because when physical NIC link goes down, you are not able to ping your test IP even if link on virtualized NIC is still up. Interfaces do not have packet loss statistic, I cannot see it. They have packet in/out, bytes in/out or errors.

3

24.7 Production Series / Re: Unbound Query Forwarding exclusions?

« on: October 15, 2024, 07:47:14 pm »

I'm using AdGuard at home but I'm doing it differently. My AdGuard runds on separate VM (other than OPNsense).
I'm putting AdGuard in front of OPNsense i.e. DHCP clients revceive AdGuard's IP address as primary DNS server (OPNsense's IP is secondary - as backup in case AdGuard fails) and talk to AdGuard and AdGuard then forwards all (already filtered) queries to OPNSense.
In OPNsense I use DNS over TLS to Cloudflare servers to send/forward DNS queries as encrypted ones over WAN and not to let know my cable operator what I'm browsing that easily.

I tried to use Unbound resolver mode once but it did not work well with my dual-WAN setup.
If primary WAN (DSL) was operational (99% of the time) resolver worked fine.
If DSL failed and traffic went through backup link (LTE modem) then resolver was malfunctioning.
Resolver sends a lot of queries outside to resolve a single (uncached) name and it was taking too much time over LTE/cellular link to resolve a name so I had a lot of DNS timeouts then.
I could not find a way how to use resolver mode with DSL link and forwarder with LTE so eventually I switched from resolver to forwarder mode and then Unbound works fine over (slow) backup WAN link too.

Then I implemented DNS over TLS to enhance my privacy in forwarder mode.

4

24.7 Production Series / Re: Multi-WAN gateway monitoring dashboard problem with virtual adapaters

« on: October 15, 2024, 07:44:07 pm »

So with "virtual" you mean VirtIO paravirtualized NICs plugged into Linux bridge on KVM hypervisor side ? In such case I guess you meant "vtnet" not "vnet" ? (that's how these are visible in FreeBSD so in OPNsense). I use these on my PVE OPNsense VMs.

I have never paid attention to how they work in OPNsense but my understanding will be same as with PCIE passthrough with SR-IOV - driver always reports their link state to be up and will not replicate physical NICs state that is connected to the underlying Linux bridge. So they will always show up as green in OPNsense, unless you forcibly/manually put link down on such virtualized NIC in KVM VM's configuration.

I'm surprised there were any changes around 24.7.6 in this regards.

Gateway state reporting will still work fine becuase if physical link dies, you are not able to ping gateway anymore (assuming you are monitoring gateway IP behind the physical cable but not another VM's IP for example).

If VirtIO link went down when physivcal link of the NIC connected to the bridge went down then you would lose ability to talk to another VMs in the same bridge when physical link goes down. I'm guessing in most cases it is undesirable.

I saw an option to replicate physical NIC linkstate to virtualized NIC linkstate in standalone desktop hypervisors (e.g. VirtualBox) but not in KVM.
With KVM, if you want physical link state be replicated to NIC in the VM then my best guess would be to stay with PCIe passthrough and effectively reassign physical NIC from hypervisor to VM.

5

24.7 Production Series / Re: Push DNS not working with OpenVPN Connect Client 3.5.0

« on: October 14, 2024, 05:27:30 pm »

As far as I'm informed OpenVPN Connect is the recommended Client for use with OpenVPN-Servers.

As long as OpnSense is so widly used as VPN-Server, as log concerns with those clients do belong in this forum. To inform other users, that failures might belong to these faulty clients.

I think your misunderstanding comes from the fact that OpenVPN Connect is in fact client dedicated to commercial OpenVPN solutions (Access Server etc.). It "should" work with "most" OpenVPN opensource solutions but that does not sound like "supported" or "guaranteed". It should not be your first go to option for OPNsense.

The dedicated client for opensource OVPN solutions (so the one in OPNsense for example) is the "communtity OVPN client" (available in Community downloads of OpenVPN), not OVPN Connect which is dedicated for their commercial solutions.

6

24.7 Production Series / Re: Unbound Query Forwarding exclusions?

« on: October 14, 2024, 03:32:19 pm »

"I do know the settings under System: Settings: General don’t really matter as far as Unbound is concerned, it’s an actual recursive resolver."

Yes, they do. You control behavior of UnboundDNS be defining or not forwarders. No forwarders = pure resolver mode. Forwarders defined for specific domains only - acts as a forwarder for these domains only, for rest - as resolver. Forwarder set for all domains - forwarder only mode.

If checkbox "Use System Nameservers" checkbox in Query Forwarding section is set then it means it work as forwarder for all domains and uses DNS servers from Settings/General. This checkbox also disables DNS over TLS forwarders defined in another section.
Only the specific domains deifnied in Query Forwarding will be forwarded to different servers defined here if this checkbox is set.

I have never tried to set a "global" forwarder by setting forwarder in Query Forwarding with no domain name set. I'd rather check "Use System Nameservers" and use System/General DNS server settings. Generally speaking queriess to "local" domain (set in System/General) should be resolved locally but unsure how it works if it is done your way.

7

24.7 Production Series / Re: Multi-WAN gateway monitoring dashboard problem with virtual adapaters

« on: October 14, 2024, 02:03:23 pm »

Hi,

What do you mean with "virtual adpater" here ?
 
I have not been running any VMs on TNS. But I run my OPNsense instances on PVE, albeit not with passthrough PCIe NICs. I do have PCIe passthrough devices on other VMs on PVE though (my TNS is a VM on PVE and has passthorugh NICs).

My expierence is that if you passthrough entire network adapter (=port) to a VM then its physical link state is properly indicated inside the VM - it replicates state of the physical link. But in fact then it is not "a virtual adapter" (as you called it) but just a physical adapter (physical function = PF) that is passed through/redirected to a VM. In other words VM sees a physical NIC.

If you are using SR-IOV on the other hand then you are redirecting a "virtual" instance of the adapter (VF - virtual function), not a PF.

My experience says that link state for VFs is always up, no matter whether link state of PF is up/down. Maybe that behavior depends on NIC type or its driver but makes sense to me. Even if link is down in PF then you may have other VFs on the same PF and they will still be able to communicate to each other via an integrate switch inside SR-IOV capable NIC. It would not be possible if VF link went down when PF link goes down.

So my question is what are you actually redirecting to VM if you are calling it "virtual adapter" ? Entire adapter (PF) or VF of SR-IOV ?

8

24.7 Production Series / Re: Push DNS not working with OpenVPN Connect Client 3.5.0

« on: October 14, 2024, 01:48:27 pm »

Hi,

I thought OVPN Connect was primarily intended to be used with their OVPN Access Server, not with the open-source OVPN servers (the one being part of OPNsense) ?

Why just not use OVPN community client which works very well with OVPN open-source server (built into OPNsense) ?
My colleague once tried to use OVPN Connect to connect with OVPN server on my OPNsense and he could not make it work at all (I forgot to instruct him to use community OVPN client, not OVPN Connect).

Besides this complaint should be rather posted on OVPN forums :-)

9

24.7 Production Series / Monit issues after recent 24.7.6 release

« on: October 14, 2024, 01:30:48 pm »

Hi,

I have been using Monit on OPNsense for some time to monitor HTTP connectivity to some hosts or to montor HTTPS connectivity + certificate validity period reporting. This worked well so far.

Starting from 24.7.6, I'm flooded with false-negative alerts that given monitoring host experienced "Connection failed" and then in a minute or so "Connection succeeded". Then there is a period of silence (a couple of minutes) and again failed/succeeded alerts repeat.

Alerts look like that:

Code: [Select]

        Action:      alert
        Host:        opnsense2.localdomain
        Description: failed protocol test [HTTP] at [192.168.7.1]:443 [TCP/IP TLS] -- Poll failed: Interrupted system call
The common message for all failed alerts is "Interrupted system call".

Only some monitored hosts are affected and both my HTTP and HTTPS monitors are affected. But no changes have been made to these hosts, it was OPNsense upgraded to 24.7.6 and it all started right after it.

Has anyone expierenced similar behavior ?

Thanks

10

24.1 Legacy Series / Re: Fatal trap 12: page fault while in kernel mode - supervisor read data

« on: February 23, 2024, 11:47:51 pm »

No, none of installations where I experience these reboots periodically use PPPoE.
One coindicence that I noticed is that they happen more frequently under high data transfers, or especially when downloading Torrents.

11

24.1 Legacy Series / Re: Rebooting on 24.1.1

« on: February 23, 2024, 11:43:44 pm »

Are you running your OPNsense on baremetal or as VM ?
If VM, then by any chance, aren't you experiencing this:

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

12

24.1 Legacy Series / Re: Fatal trap 12: page fault while in kernel mode - supervisor read data

« on: February 23, 2024, 03:11:12 pm »

Really no one expeirencing this here ?

On variuos forums there are multiple reports of the same repeating crash (Fatal trap 12: page fault while in kernel mode - supervisor read data, page not present) over few last years and still no solution/still not fixed.

Both OPNsense and pfSense are affected when running as virtual machines (both KVM e.g. Proxmox and ESXi). Only running firewall on baremetal is fully trouble free.

It's a corner case though - running firewall on VM alone is not sufficient for this to happen. My primary instance was not affected when it was running on ESX on i3-10100, i7-10700 or i5-12500. It started to happen obnly when I moved VM to chinese miniPCs with N5105 or Pentium 7505. But cannot blame these chinese PCs since the same started to happen recently  on my collegaue's instance (OPNsense on KVM on Synology on AMD CPU).

13

24.1 Legacy Series / Fatal trap 12: page fault while in kernel mode - supervisor read data

« on: February 20, 2024, 01:48:22 pm »

Hi,

Has anyone ever found a definitive solution to these periodic crashes of OPNsense ? They are still present in 24.1.

I have seen these for the first time when I migrated my OPNsense VM instance (running on ESXi) from regular generic PC to chinese MiniPC with N5105 + I226V's.
Then read about chinese PC's with N5105's being possible cluprit.

So replaced this MiniPC with another one with Pentium 7505 - same story.

You can blame chinese MiniPC's. But... Recently I have seen the same crashes on OPNsense running on KVM on Synology device with AMD V1500 CPU.

So it's not caused by specific CPU or hypervisor.

Moreover all my other VMs are perfectly stable, including those running non-OPNsense FreeBSD 13.2. So it's something wrong with OPNsense but it's a corner case specific to some config since not all OPNsense VMs under my supervision are experiencing this.

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff8238d57f
stack pointer         = 0x0:0xfffffe000b9af6c0
frame pointer         = 0x0:0xfffffe000b9af720
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (if_io_tqg_3)
trap number = 12
panic: page fault
cpuid = 3
time = 1706361743
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe000b9af480
vpanic() at vpanic+0x151/frame 0xfffffe000b9af4d0
panic() at panic+0x43/frame 0xfffffe000b9af530
trap_fatal() at trap_fatal+0x387/frame 0xfffffe000b9af590
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe000b9af5f0
calltrap() at calltrap+0x8/frame 0xfffffe000b9af5f0
--- trap 0xc, rip = 0xffffffff8238d57f, rsp = 0xfffffe000b9af6c0, rbp = 0xfffffe000b9af720 ---
pf_test_state_udp() at pf_test_state_udp+0x28f/frame 0xfffffe000b9af720
pf_test() at pf_test+0xc57/frame 0xfffffe000b9af890
pf_check_in() at pf_check_in+0x25/frame 0xfffffe000b9af8b0
pfil_run_hooks() at pfil_run_hooks+0x97/frame 0xfffffe000b9af8f0
ip_input() at ip_input+0x799/frame 0xfffffe000b9af980
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe000b9af9d0
ether_demux() at ether_demux+0x159/frame 0xfffffe000b9afa00
ng_ether_rcv_upper() at ng_ether_rcv_upper+0x8c/frame 0xfffffe000b9afa20
ng_apply_item() at ng_apply_item+0x2bf/frame 0xfffffe000b9afab0
ng_snd_item() at ng_snd_item+0x28e/frame 0xfffffe000b9afaf0
ng_apply_item() at ng_apply_item+0x2bf/frame 0xfffffe000b9afb80
ng_snd_item() at ng_snd_item+0x28e/frame 0xfffffe000b9afbc0
ng_ether_input() at ng_ether_input+0x4c/frame 0xfffffe000b9afbf0
ether_nh_input() at ether_nh_input+0x1f2/frame 0xfffffe000b9afc50
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe000b9afca0
ether_input() at ether_input+0x69/frame 0xfffffe000b9afd00
iflib_rxeof() at iflib_rxeof+0xbcb/frame 0xfffffe000b9afe00
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe000b9afe40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame 0xfffffe000b9afec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc3/frame 0xfffffe000b9afef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe000b9aff30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000b9aff30
--- trap 0x6c617470, rip = 0x5ac8b830975c0, rsp = 0x8b8d4820000005a8, rbp = 0x30646870 ---
KDB: enter: panicThanks.

14

Development and Code Review / Certfifcate management improvement suggestion

« on: February 20, 2024, 01:32:55 pm »

Hi,

Consider pls adding this in System/Trust/Certificates:

- add "by CA" filter (display certificates belonging to specific CA - I have multiple CAs)
- make Valid From/To separate columns (not part of DN)
- add column sorting (especially on "Valid To" column - to quickly identify which certificates expire first)

Current layout is good as long as you have one CA ond just a handful of certs to manage.

Thanks !

15

Development and Code Review / Re: Improvement of CARP VIP creation GUI

« on: November 21, 2023, 11:05:39 pm »

Thanks a lot for taking my suggestion into consideration ! Everything will be better than silently adding /32 netmask when no netmask was provided. Dropbox with netmask length, checking if netmask was provided etc etc.