Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    CE 2.8.1-RELEASE OpenVPN client connection triggers Fatal trap 12: page fault while in kernel mode

    Scheduled Pinned Locked Moved General pfSense Questions
    49 Posts 3 Posters 1.1k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • E Offline
      elgranjeff
      last edited by

      Hello,

      I'm a home user with IT management and networking experience, I'd like to think a bit more than just enough to be dangerous.
      I've built my own router using a dell optiplex 3046 with Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz and 16 GB of DDR 4 that I'm using for my home router.

      I've been working to get my OpenVPN server configured so I can connect remotely and access internal services as if I'm home, but I've found that shortly after establishing a client connection (within a few seconds of getting assigned a tunnel address) I can see the VGA terminal scroll at warp speed for 20-30 seconds before the system reboots.

      I don't know how/where to find any kernel dump or stack trace if there is any, but when I load 1k lines from the system log, I see fatal trap 12 page fault while in kernel mode before the ---<<BOOT>>--- line.

      This may be unrelated, I honestly don't know, but static arp entries are failing "Cannot allocate memory" and unbound also fails to start and logs message:

      [1766093223] unbound[46009:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766093223] unbound[46009:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value).

      But my system has 16GB of RAM, so perhaps I just need to adjust some system tunables, but I'm not very familiar with freebsd.

      I've included the full log since my last boot (there was nothing meaningful before that doesn't get displayed every boot.

      Any assistance or guidance would be appreciated!

      FYI, I'm using a Realtek-based 2.5G NIC for my WAN and I have a chelsio n320-sr dual sfp+ with both interfaces in a LAGG as my LAN with a number of VLANs for various purposes (home services, lab tinkering, etc).

      My interfaces:

      0_WAN 2500Base-T <full-duplex> [redacted]
      1_LAN LAGG Ports: cxgb0 (ACTIVE,COLLECTING,DISTRIBUTING), cxgb1 (ACTIVE,COLLECTING,DISTRIBUTING) 10.0.0.1
      1_LAN_0002_JEFF autoselect 10.0.2.1
      1_LAN_0003_NETWORK autoselect 10.0.3.1
      1_LAN_0010_MANAGEMENT autoselect 10.0.10.1
      1_LAN_0040_PRINT autoselect 10.0.40.1
      1_LAN_0050_SERVICES autoselect 10.0.50.1
      1_LAN_0060_SAN autoselect 10.0.60.1
      1_LAN_0061_SAN_BACKUPS autoselect 10.0.61.1
      1_LAN_0070_IOIT autoselect 10.0.70.1
      1_LAN_1010_HOME autoselect 10.10.10.1
      1_LAN_1020_KIDS autoselect 10.10.20.1
      1_LAN_1030_WORK autoselect 10.10.30.1
      1_LAN_1031_MPULSE_SANDBOX autoselect 10.10.31.1
      1_LAN_1040_GUEST autoselect 10.10.40.1
      1_LAN_1050_GAMES autoselect 10.10.50.1
      1_LAN_2000_SANDBOX autoselect 10.20.0.1
      OVPNS1_ADMIN 10.30.0.1

      To get the WAN interface to be discovered, I've already ran pkg install realtek-re-kmod, and I've added the following to my /boot/loader.conf.local:

      if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"

      I know that everyone says realtek NICs don't perform well under heavy load, but I don't know how to validate those claims yet -- perhaps that will be the case here, but perhaps not.

      I've read that the static arp has caused issues in the past, but this system has far more memory than I can get it to utilize, so I'd rather not remove all of those entires just to test unless it definitely might be the cause. I would much prefer to tweak some tunables to be more generous with my relatively higher-power hardware.

      Here's the log entries since my last boot with my WAN IP redacted.
      2025-12-18-crash-boot-log-sample.txt

      tinfoilmattT 1 Reply Last reply Reply Quote 0
      • tinfoilmattT Offline
        tinfoilmatt LAYER 8 @elgranjeff
        last edited by

        @elgranjeff What do you have for these settings under System / Advanced / Networking / Network Interfaces:

        65a91618-f7be-43eb-8453-28c8db726b17-image.png

        This feels like an unsavory suggestion for a wait-and-see-if-it-happens-again, elusive-type crash. But I'd suggest matching those settings (i.e., checkboxes checked) if not already.

        E 1 Reply Last reply Reply Quote 0
        • E Offline
          elgranjeff @tinfoilmatt
          last edited by elgranjeff

          @tinfoilmatt I just now (before seeing this message, actually) checked all three of those boxes to see if it would help, but it hasn't helped.

          This is actually a very consistently triggered issue. Using my laptop connected to my phone's hotspot (phone is on 5G, wifi disabled) I establish an openvpn connection and the system crashes.

          I also removed all of my static arp entries because I was tired of seeing those errors on boot (though that may be worth investigating on it's own)

          Unbound is not able to load on boot and I see this in the general system log in the web GUI (I formatted the quoted error string for readability)

          Dec 18 16:29:55 	php-cgi 	593  rc.bootup: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] warning: setsockopt(..., SO_SNDBUF, ...) was not granted: No buffer space available 
[1766104183] unbound[8190:0] warning: so-sndbuf 4194304 was not granted. Got 57344. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. or set so-sndbuf: 0 (use system value). 
[1766104183] unbound[8190:0] error: can't bind socket: Can't assign requested address for fe80::207:43ff:fe0a:8964 port 53 
[1766104183] unbound[8190:0] fatal error: could not open ports'
          tinfoilmattT 1 Reply Last reply Reply Quote 0
          • tinfoilmattT Offline
            tinfoilmatt LAYER 8 @elgranjeff
            last edited by

            @elgranjeff Can you post an updated boot log?

            E 1 Reply Last reply Reply Quote 0
            • E Offline
              elgranjeff @tinfoilmatt
              last edited by

              @tinfoilmatt, thanks again for reviewing this with me! 🙏

              Do you want a log from the point of a normal reboot or do you want to see the log when the crash is triggered by establishing an OpenVPN connection?

              tinfoilmattT 1 Reply Last reply Reply Quote 0
              • tinfoilmattT Offline
                tinfoilmatt LAYER 8 @elgranjeff
                last edited by

                @elgranjeff Same as you did in your first post—trigger the crash and then post subsequent boot log containing the kernel panic/crash details.

                E 1 Reply Last reply Reply Quote 0
                • E Offline
                  elgranjeff @tinfoilmatt
                  last edited by

                  @tinfoilmatt Thanks for confirming. I triggered the error just now and I've included the boot log starting with the last entry before triggering the crash.

                  2025-12-19-10-54-11-crash-boot-log.txt

                  tinfoilmattT 3 Replies Last reply Reply Quote 0
                  • tinfoilmattT Offline
                    tinfoilmatt LAYER 8 @elgranjeff
                    last edited by

                    @elgranjeff MUCH cleaner without those static ARP entries, so that's good. Let me see if anything else catches my eye now.

                    What I can see right off the rip is that something related to your WAN interface...

                    Dec 19 10:56:59 	kernel 		current process = 0 (re1 taskq)

                    ...is specifically what's triggering the kernel panic. There's a buncha 'Google-able' stuff in that pre----<<BOOT>>--- section alone.

                    E 2 Replies Last reply Reply Quote 0
                    • tinfoilmattT Offline
                      tinfoilmatt LAYER 8 @elgranjeff
                      last edited by

                      @elgranjeff The 2.5 GbE Realtek NIC is a discrete card, correct? Can you confirm a model number?

                      I still see...

                      Dec 19 10:56:59 	kernel 		re1: Using defaults for TSO: 65518/35/2048

                      ...which indicates to me that the system is still configured to use TCP segmentation hardware offloading. Do you have any system tunables custom configured?

                      1 Reply Last reply Reply Quote 0
                      • tinfoilmattT Offline
                        tinfoilmatt LAYER 8 @elgranjeff
                        last edited by

                        @elgranjeff Notice also that something different is happening with the Chelsio NICs when they come up:

                        [ . . . ]
Dec 19 10:56:59 	kernel 		cxgb0: tso4 disabled due to -txcsum.
Dec 19 10:56:59 	kernel 		cxgb0: tso6 disabled due to -txcsum6.
[ . . . ]
Dec 19 10:57:00 	kernel 		cxgb1: tso4 disabled due to -txcsum.
Dec 19 10:57:00 	kernel 		cxgb1: tso6 disabled due to -txcsum6.
[ . . . ]
                        E 1 Reply Last reply Reply Quote 0
                        • E Offline
                          elgranjeff @tinfoilmatt
                          last edited by

                          @tinfoilmatt Yeah.. that doesn't bode well.. maybe I'll need to get a proper 2.5G NIC after trying the cheapest one I could find 😁 and finding out for myself.

                          Yeah, I see that apic id = 06 suggests a potential CPU/Memory hardware failure.. I can run some hardware tests.

                          Regarding System Tunables, I have these lines added to my /boot/loader.conf.local

                          if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"

                          And via the web gui I set kern.ipc.maxsockbuf=4194304 because it was at a slightly lower value previously and unbound would crash every time i started it -- googling (I don't have the url linked) showed some post somewhere where someone did a bit of math suggesting 4194304, but I can't find my source for that.

                          Is there a way to determine from the GUI which tunables have been adjusted away from defaults?

                          1 Reply Last reply Reply Quote 0
                          • E Offline
                            elgranjeff @tinfoilmatt
                            last edited by

                            @tinfoilmatt my guess (otherwise, I have no idea) is that it's related to those three checkboxes you referenced above to disabled hardware offloading -- I can confirm that those are checked in my current configuration.

                            tinfoilmattT 1 Reply Last reply Reply Quote 0
                            • tinfoilmattT Offline
                              tinfoilmatt LAYER 8 @elgranjeff
                              last edited by

                              @elgranjeff Can you post the output of kldstat and pkg info realtek-re-kmod?

                              E 1 Reply Last reply Reply Quote 0
                              • tinfoilmattT Offline
                                tinfoilmatt LAYER 8
                                last edited by tinfoilmatt

                                Also looks like net.inet.tcp.tso may be a System Tunable included by-default under System / Advanced / System Tunables.

                                I'd say it's worth flipping to 0, rebooting, and attempting the OVPN connection to see if the crash is triggered—if only to potentially rule this line of troubleshooting out completely.

                                E 1 Reply Last reply Reply Quote 0
                                • E Offline
                                  elgranjeff @tinfoilmatt
                                  last edited by

                                  @tinfoilmatt

                                  # kldstat
Id Refs Address                Size Name
 1   34 0xffffffff80200000  2dc8ee0 kernel
 2    1 0xffffffff82fca000   60a278 zfs.ko
 3    1 0xffffffff835d5000   11eda0 if_re.ko
 4    1 0xffffffff836f4000    1e2a8 opensolaris.ko
 5    1 0xffffffff847f9000     23a0 cpuctl.ko
 6    1 0xffffffff847fc000     2110 pchtherm.ko
 7    1 0xffffffff847ff000     4250 ichsmb.ko
 8    1 0xffffffff84804000     2178 smbus.ko
 9    1 0xffffffff84807000     9290 aesni.ko
10    1 0xffffffff84811000     4b18 cryptodev.ko
11    1 0xffffffff84816000     20f0 coretemp.ko

                                  # pkg info realtek-re-kmod
realtek-re-kmod-1100.00.1500029_1
Name           : realtek-re-kmod
Version        : 1100.00.1500029_1
Installed on   : Sun Dec  7 12:41:26 2025 PST
Origin         : net/realtek-re-kmod
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : net kld
Licenses       : BSD4CLAUSE
Maintainer     : ale@FreeBSD.org
WWW            : https://github.com/alexdupre/rtl_bsd_drv
Comment        : Kernel driver for Realtek PCIe Ethernet Controllers
Annotations    :
	FreeBSD_version: 1500029
	build_timestamp: 2025-09-09T15:50:36+00:00
	built_by       : poudriere-git-3.4.99.20250601
	repo_type      : binary
	repository     : pfSense
Flat size      : 1.12MiB
Description    :
Realtek PCIe FE / GBE / 2.5G / 5G Ethernet Family Controller
kernel driver.

This is the official driver from Realtek with a few patches to
improve stability and performance. It can be loaded instead of
the FreeBSD driver built into the GENERIC kernel if you experience
issues with it (eg. watchdog timeouts), or your card is not supported.

Supported devices:

* 5G Gigabit Ethernet
  - RTL8126

* 2.5G Gigabit Ethernet
  - RTL8125 / RTL8125B(G)

* 10/100/1000M Gigabit Ethernet
  - RTL8111B / RTL8111C / RTL8111D / RTL8111E / RTL8111F / RTL8111G
    RTL8111H / RTL8118(A) / RTL8119i / RTL8111L / RTL8111K
  - RTL8168B / RTL8168E / RTL8168H
  - RTL8111DP / RTL8111EP(P) / RTL8111FP
  - RTL8411 / RTL8411B

* 10/100M Fast Ethernet
  - RTL8101E / RTL8102E / RTL8103E / RTL8105E / RTL8106E / RTL8107E
  - RTL8401 / RTL8402

See also: https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software
                                  1 Reply Last reply Reply Quote 0
                                  • E Offline
                                    elgranjeff @tinfoilmatt
                                    last edited by

                                    @tinfoilmatt can confirm that net.inet.tcp.tso was set to 1. I set it to 0, rebooted, confirmed that the tunable was still 0 at boot, then successfully triggered the crash again.

                                    Unbound is still unhappy and needs to be manually started after each boot regardless of whether it was due to a crash or graceful reboot.

                                    Here's the log after the crash:
                                    Dec 19 11 47 22 syslogd.txt

                                    tinfoilmattT 2 Replies Last reply Reply Quote 0
                                    • tinfoilmattT Offline
                                      tinfoilmatt LAYER 8 @elgranjeff
                                      last edited by

                                      @elgranjeff Nothing relevant in any other logging (System and OpenVPN in particular) captured in the immediate lead-up to crash?

                                      E 1 Reply Last reply Reply Quote 0
                                      • E Offline
                                        elgranjeff @tinfoilmatt
                                        last edited by

                                        @tinfoilmatt nothing interesting to my knowledge. Admittedly I'm in a bit over my head, but I find immersion with assistance from experienced peers to be super beneficial.

                                        Here's the leadup to the latest boot including the page fault that I included in my previous post with logs for posterity:

                                        Dec 19 11:44:18 	kernel 		done.
Dec 19 11:44:18 	sshguard 	21140 	Exiting on signal.
Dec 19 11:44:18 	sshguard 	17662 	Exiting on signal.
Dec 19 11:44:18 	syslogd 		exiting on signal 15
Dec 19 11:44:18 	syslogd 		kernel boot file is /boot/kernel/kernel
Dec 19 11:44:18 	sshguard 	87014 	Now monitoring attacks.
Dec 19 11:44:18 	php-fpm 	443 	/rc.start_packages: Restarting/Starting all packages.
Dec 19 11:44:18 	php-fpm 	443 	/rc.start_packages: Starting service avahi
Dec 19 11:44:18 	root 	54557 	Bootup complete
Dec 19 11:44:18 	avahi-daemon 	39710 	Found user 'avahi' (UID 558) and group 'avahi' (GID 558).
Dec 19 11:44:18 	avahi-daemon 	39710 	Successfully dropped root privileges.
Dec 19 11:44:18 	avahi-daemon 	39710 	avahi-daemon 0.8 starting up.
Dec 19 11:44:18 	avahi-daemon 	39710 	No service file found in /usr/local/etc/avahi/services.
Dec 19 11:44:18 	avahi-daemon 	39710 	Joining mDNS multicast group on interface lagg0.1010.IPv6 with address fe80::207:43ff:fe0a:8964.
Dec 19 11:44:18 	avahi-daemon 	39710 	New relevant interface lagg0.1010.IPv6 for mDNS.
Dec 19 11:44:18 	avahi-daemon 	39710 	Joining mDNS multicast group on interface lagg0.1010.IPv4 with address 10.10.10.1.
Dec 19 11:44:18 	avahi-daemon 	39710 	New relevant interface lagg0.1010.IPv4 for mDNS.
Dec 19 11:44:18 	avahi-daemon 	39710 	Joining mDNS multicast group on interface lagg0.70.IPv6 with address fe80::207:43ff:fe0a:8964.
Dec 19 11:44:18 	avahi-daemon 	39710 	New relevant interface lagg0.70.IPv6 for mDNS.
Dec 19 11:44:18 	avahi-daemon 	39710 	Joining mDNS multicast group on interface lagg0.70.IPv4 with address 10.0.70.1.
Dec 19 11:44:18 	avahi-daemon 	39710 	New relevant interface lagg0.70.IPv4 for mDNS.
Dec 19 11:44:18 	avahi-daemon 	39710 	Joining mDNS multicast group on interface lagg0.40.IPv6 with address fe80::207:43ff:fe0a:8964.
Dec 19 11:44:18 	avahi-daemon 	39710 	New relevant interface lagg0.40.IPv6 for mDNS.
Dec 19 11:44:18 	avahi-daemon 	39710 	Joining mDNS multicast group on interface lagg0.40.IPv4 with address 10.0.40.1.
Dec 19 11:44:18 	avahi-daemon 	39710 	New relevant interface lagg0.40.IPv4 for mDNS.
Dec 19 11:44:18 	avahi-daemon 	39710 	Network interface enumeration completed.
Dec 19 11:44:18 	avahi-daemon 	39710 	Server startup complete. Host name is pfsense.local. Local service cookie is 38507700.
Dec 19 11:44:20 	login 	21031 	login on ttyv0 as root
Dec 19 11:44:20 	login 	22698 	login on ttyu0 as root
Dec 19 11:44:37 	php-fpm 	442 	/index.php: Successful login for user 'jeff' from: 10.0.2.101 (Local Database)
Dec 19 11:47:22 	syslogd 		kernel boot file is /boot/kernel/kernel
Dec 19 11:47:22 	kernel 		Fatal trap 12: page fault while in kernel mode
Dec 19 11:47:22 	kernel 		cpuid = 3; apic id = 06
Dec 19 11:47:22 	kernel 		fault virtual address = 0x10007
Dec 19 11:47:22 	kernel 		fault code = supervisor read data, page not present
Dec 19 11:47:22 	kernel 		instruction pointer = 0x20:0xffffffff80e3e390
Dec 19 11:47:22 	kernel 		stack pointer = 0x28:0xfffffe00d5fd3d30
Dec 19 11:47:22 	kernel 		frame pointer = 0x28:0xfffffe00d5fd3d70
Dec 19 11:47:22 	kernel 		code segment = base 0x0, limit 0xfffff, type 0x1b
Dec 19 11:47:22 	kernel 		= DPL 0, pres 1, long 1, def32 0, gran 1
Dec 19 11:47:22 	kernel 		processor eflags = interrupt enabled, resume, IOPL = 0
Dec 19 11:47:22 	kernel 		current process = 0 (re1 taskq)
Dec 19 11:47:22 	kernel 		rdi: 0000000000000002 rsi: 000000000000ffff rdx: 0000000000000001
Dec 19 11:47:22 	kernel 		rcx: 0000000000000001 r8: 0000000000000001 r9: 0000000000000002
Dec 19 11:47:22 	kernel 		rax: 0000000000000000 rbx: fffff80102a2b000 rbp: fffffe00d5fd3d70
Dec 19 11:47:22 	kernel 		r10: 00000000a6c5e4be r11: 0000000043a38fb0 r12: 000000000000ffff
Dec 19 11:47:22 	kernel 		r13: fffffe00d93949c0 r14: 0000000000000000 r15: 0000000000008803
Dec 19 11:47:22 	kernel 		trap number = 12
Dec 19 11:47:22 	kernel 		panic: page fault
Dec 19 11:47:22 	kernel 		cpuid = 3
Dec 19 11:47:22 	kernel 		time = 1766173573
Dec 19 11:47:22 	kernel 		KDB: enter: panic
Dec 19 11:47:22 	kernel 		---<<BOOT>>---
                                        tinfoilmattT 1 Reply Last reply Reply Quote 1
                                        • tinfoilmattT Offline
                                          tinfoilmatt LAYER 8 @elgranjeff
                                          last edited by tinfoilmatt

                                          @elgranjeff Nothing remarkable comparing the two. And the Using defaults for TSO line (which may be a red herring) appears even after that tunable change. Just to keep stock—that's the only change we've made so far. Easy enough to revert back.

                                          Was there anything in particular that led you to install the custom Realtek driver? Just wondering aloud if the crash would still occur without it loaded and utilizing the generic driver.

                                          What's the Realtek NIC model?

                                          E 1 Reply Last reply Reply Quote 0
                                          • tinfoilmattT Offline
                                            tinfoilmatt LAYER 8 @elgranjeff
                                            last edited by

                                            @elgranjeff What's in the OpenVPN log? Curious how far along that's getting before crash.

                                            The line...

                                            Dec 19 11:47:22 	kernel 		current process = 0 (re1 taskq)

                                            ...points squarely at that NIC. That's been consistent.

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post
                                            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.