opnsense / src Goto Github PK

Users of your software that enable DNSSEC will not be able to validate DNS after October the 11th 2018.

Your repository contains a unbound-anchor.c file without the new DNSSEC trust-anchors:

". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n";

It should also include:

". IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D\n";

More information can be found at: https://www.icann.org/resources/pages/ksk-rollover

Please don’t hesitate to get in touch.

Warmly,

Roy Arends
ICANN

FreeBSD added support for the MC7430 and MC7455 (they have same VID and PID) in freebsd/freebsd-src@0c22163

In OPNsense this doesnt seem to be present: https://github.com/opnsense/src/blob/master/sys/dev/usb/serial/u3g.c

Is it possible to cherrypick this into OPNsense?

Thank you in advance, you all do a great job with this project!

Side Note: It looks like pfsense did this in https://redmine.pfsense.org/issues/6832

Version
OPNsense 19.1-amd64

Issue appears
Packets are captured with OPNsense packet capture feature on IPS enabled interface

Issue
When I capture the traffic with the OPNsense packet capture feature on an interface with IPS enabled, all packets coming from the OPNsense appliance are showing twice. The IP packet ID of both packets are the same, so in real there is only one packet on the line. A simultanous running capture on the line approved this.
When I disable IPS the issue is gone. Hardware offloading and IDS/IPS promiscous mode are disabled.

Although not super important, it's quite annoying from time to time. When using tcpdump on additional loopback interfaces, there doesn't appear to be any traffic on them (which is not the case).
The traffic that is handled over the interface, seems to be landing on lo0 from bpf(4)'s perspective.

The earliest mention of this issue I could find was this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=112612, some of the code in the report seemed to be in the kernel but the end result appears to be the same still.

Users of your software that enable DNSSEC will not be able to validate DNS after October the 11th 2018.

Your repository contains a dnssec_test.py file without the new DNSSEC trust-anchors:

resolver.add_ta(". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")

It should also include:

resolver.add_ta(". IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")

More information can be found at: https://www.icann.org/resources/pages/ksk-rollover

Please don’t hesitate to get in touch.

Warmly,

Roy Arends
ICANN

Hi guys,

i think i've found a serious Bug. I've added 2 Devices like this to get Wireguard to Work and to configure policy based routing (Copy & Paste out of the backup.xml)

    <opt3>
      <if>wg0</if>
      <descr>WGVPN</descr>
     <enable>1</enable>
      <lock>1</lock>
      <spoofmac/>
    </opt3>
    <opt4>
      <if>wg1</if>
      <descr>WGAZIRE</descr>
      <enable>1</enable>
      <lock>1</lock>
      <spoofmac/>
    </opt4>

and i've configured wireguard to use these Interfaces. While activating these Interfaces the System reboot.

You can look at the Stack-Trace which i've already sent by Mail through the webinterface. I've uploaded it here: https://pastebin.com/dsApfGcz

Are you having any hints or suggestions or could fix my issue? I've posted already a Thread in the OPNSense Forum, but did not get an answer. Link: https://forum.opnsense.org/index.php?topic=14044.msg64586#msg64586

I need both Interfaces. One for VPN Incoming Connections, and the other for my VPN Provider. Is it possible to fix the crash? Could i change something to get rid of the bootloop?

Please, enable virtio_console kernel module per default
https://www.freebsd.org/cgi/man.cgi?query=virtio_console&sektion=4
https://hardenedbsd.org/article/op/2017-08-01/stable-release-hardenedbsd-stable-11-stable-v10000481
Thank you in advance

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[X] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
A clear and concise description of what the bug is, including last known working version (if any).

I just upgraded a box from 20.1 to 20.7 Since the upgrade I can detect errors on the VLANs. On the side of the switch I could not detect any errors.

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce
Steps to reproduce the behavior:

1. Use box with igb NICs and 20.1
2. Create VLAN on Parent Interface and create some Traffic, All interface Errors should be "0"
3. Upgrade to 20.7
4. Look at Interface Errors

Expected behavior
Like in 20.1 in 20.7 there should be no Errors on the VLAN Interfaces

Screenshots

Relevant log files
If applicable, information from log files supporting your claim.

Additional context
Add any other context about the problem here.

Environment
Software version used and hardware type if relevant.
e.g.:

OPNsense 20.7-amd64
FreeBSD 12.1-RELEASE-p7-HBSD
OpenSSL 1.1.1g 21 Apr 2020

vendor     = 'Intel Corporation'
device     = 'I211 Gigabit Network Connection'
class      = network
subclass   = ethernet

As referenced in these forum threads:
https://forum.opnsense.org/index.php?topic=4512.0
https://forum.opnsense.org/index.php?topic=4516.0

I realized after reading these threads that my own port forwarding is also not working for my policy based routes. sysctl net.pf.share_forward=0 does restore it to working order.

After doing some testing with tcpdump, I realized that the issue is actually another NAT related problem. The "return" packets are not being NATed (the source address is from my LAN network on the external interface). I believe that the routing table, instead of the reply-to route, is being used to determine the translation address, since connecting from the external interfaces subnet does NAT the return packets properly.

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

I run OPNSense on UNRaid VM (Q35) using virtual NICs (VIRTIO).

On 19.1 only Q35-2.6 worked, using other Q35-x.x there were no NICs detected in OPNsense.
So I ran Q35-2.6, everything fine.

Since update to 19.7 there are no NICs detected anymore!! I tried other Q35 versions, also tried a fresh install an a new VM. => 19.1 shows NICs, 19.7 does not find NICs!!

Now I run a Backup on 19.1 again.

For FreeBSD 12.1 and HardenedBSD that is based on it, syslogd is partially broken. The same goes for OPNsense 20.1.

Entries in syslog.conf that rely on LogTag (or program name), e.g.

!filterlog
*.* %/var/log/filterlog

don't put any messages in the log files even though plenty are being sent by the filterlog program using the syslog() call. And, of course, since no messages are in those log files, OPNsense doesn't show them.

Entries in syslog.conf that use one of the 24 standard facilities (e.g. local7) allow messages to be forwarded by syslogd as expected. WebGUI/Firewall/Log Files/Plain View shows messages. However, messages that require parsing by OPNsense, like WebGUI/Firewall/Log Files/Live View or WebGUI/Firewall/Log Files/Overview show nothing.

Is the cause a change in syslog.c for FreeBSD 12.X (see the entry in /UPDATING dated 20180406)?

Apparently, syslogd and OPNsense haven't caught up to that change yet.

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[X] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
When configuring a LTE connection like described in https://docs.opnsense.org/manual/how-tos/cellular.html, the system soon reboots after the LTE connection has been enabled. About 2 seconds after enabling the LTE connection, a lot of outputs runs through the console and after a while the firewall reboots. On the next login the dashboard mentions "A problem was detected. Click here for more information." (I did this and submitted the output multiple times).
Info: Full report of my tests can be found on the forum here: https://forum.opnsense.org/index.php?topic=17417.0

LTE worked without an issue with OPNsense 18.7, 19.1, 19.7, 20.1. Now, 20.7 causes the following issue:

To Reproduce
Steps to reproduce the behavior:

1. Install OPNsense 20.7beta or 20.7-RC1
2. Configure the modem via "Interfaces -> Point-to-Point -> Devices" as described in https://www.thomas-krenn.com/de/wiki/OPNsense_LTE_Verbindung#Konfiguration_Modem. For a Quectel modem use /dev/cuaU0.2, for a Huawei ME909u-521 use /dev/cuaU0.0
3. Switch to "Interfaces -> Assignments" and configure for "WAN" the network port "ppp0". Click "Save"
4. Immediately after that, on the console there is the following output (in bold): "WARNING: attempt to domain_add(netgraph) after domainfinalize" This is OK, this warning is displayed also with OPNsense 20.1, 19.7, ... (with those older versions LTE works without any issues)
5. After 1-2 seconds a lot of outputs runs through the console and after a while the firewall reboots.

Expected behavior
When a LTE connection is configured the system should continue to run and not reboot.

Screenshots
If applicable, add screenshots to help explain your problem.

Relevant log files
ppps.log
system.log

Additional context
The interesting thing is that configuring the LTE connection on the command line does not cause this issue, it works without problems. To reproduce do:

1. Install OPNsense 20.7 20.7-RC1
2. Activate SSH access
3. Create /var/etc/mpd_opt1-wernertest.conf with the contents of the following file (adjust "set modem device" and APN according to your modem / LTE provider): mpd_opt1-wernertest.conf.txt
4. Execute:

# cp -a /usr/local/opnsense/scripts/interfaces/mpd.script /var/etc/
# /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_opt1-wernertest.conf -p /var/run/ppp_opt1-wernertest.pid -s ppp pppclient

Then it works.

Here are the log files of this manual connection process:
ppps-manual.log
system-manual.log

When I compare the entries in system.log when configuring via web interface compared to configuring via command line, I see following additionals entries (I think that they trigger the issue):
system-additional-when-configuring-via-web.txt

Environment
OPNsense OPNsense 20.7.r1-amd64
Intel(R) Celeron(R) CPU N3160 @ 1.60GHz (4 cores)
LTE Modem: "Quectel EG25-G" and "Huawei ME909u-521"

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[X] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
Realtek RTL8153 USB 3.0 LAN NICs not being fully recognised and limited to 100Mbit - no connectivity information is displayed by OPNsense and no settings for "media" are made available for the interface e.g. auto, force 1000Mbit etc

Confirmation on switch that NIC is connected to, shows a 1000Mbit connection.

To Reproduce
Steps to reproduce the behavior:

1. Plug in any Realtek RTL8153 USB 3.0 LAN based NIC, I have tried 3 from different manufacturers
2. Perform speed test e.g. I have 500Mbit service, perform test on firewall direct, I get close to 500Mbit, perform same test on LAN connected via USB NIC, never goes above 100Mbit

Expected behavior
Expect interface to show NIC connectivity information, make available media options, connect above 100Mbit

Additional context
I currently have two different USB3.0 adapters connected, one in USB3 (only have one) the other in USB2, they behave the same:

ugen0.4: <Realtek USB 101001000 LAN> at usbus0, cfg=1 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
ugen0.7: <Realtek USB 101001000 LAN> at usbus0, cfg=1 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)

I also have a TP-Link adapter (U300) that annoyingly changes the name from Realtek to TP-Link, but it's the same chipset, but it doesn't work at all with OPNsense even though the switch recognises the connection.

I have tried commands such as

usbconfig -d usbconfig list | grep "Realtek USB 101001000 LAN" | cut -c5-7 set_config 1

But does not do anything

Originally posted for help here: https://forum.opnsense.org/index.php?topic=17394.msg

Environment

OPNsense 20.1.7-amd64
FreeBSD 11.2-RELEASE-p20-HBSD
LibreSSL 3.0.2

;)

Hi,

I have found a problem that I could reproduce on our 3 OPNSense firewalls running version OPNsense 19.7.5_5-amd64.

running dtrace -n 'fbt:::entry { @[probefunc] = count(); }' -c 'any command here' results in the following error : "dtrace: invalid probe specifier fbt:::entry { @[probefunc] = count(); }: "/usr/lib/dtrace/io.d", line 45: operator -> cannot be applied to a forward declaration: no struct devstat definition is available"

This is not reproducible in FreeBSD 12.0.

Hi,
as stated here https://svnweb.freebsd.org/base?view=revision&revision=r290383
the sysctl option for fast forwarding has been removed quite a while ago...

Cheers,

Stephan

We use hardware from HP as OPNsense and as 10GBit NIC we also used cards from HP.
Unfortunately NC523 which uses a qlogic chipset.

1. You need to load the driver 'by hand'
   /boot/loader.conf.local ->

if_qlxgb_load="YES"

But the driver has a bug and this bug is still not fixed in the latest FreeBSD 12 version.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226217

It results in a lot of warning messages after the NIC is configured by the OPNsense scripts and the NIC is not working.
You can resolve this by execute

ifconfig ql0 mtu 1500

for all interfaces

To automate this (needed for unattended reboots) we found a solution:
/etc/cron.d/qlfix ->

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin

# fix for qlogic
@reboot root /etc/qlfix

inside the /etc/qlfix we set the mtu:

#!/bin/sh

/sbin/ifconfig ql0 mtu 1500
/sbin/ifconfig ql1 mtu 1500

This works, but ...
If you change something inside the web GUI for one of these interfaces you have to run these script afterwards.

Now we have (big) 2 FreeBSD bugs which are not fixed since years.

This is a similar issue to #47, but it doesn't seem to be quite the same.

I recently started using OPNsense as a VM. Host runs Proxmox VE 6.1. The VM is set up with the i440fx machine type, not the q35 machine type (one difference from the issue in #47). Both NICs are of the virtio type.

I just upgraded from 19.7 to 19.7.8 (other difference from the issue in #47), and the virtio NICs are no longer being detected. When I switch the NICs to vmxnet3, the interfaces are detected, but CPU usage hits 100% before I can max out a 300 Mbps WAN connection, so not ideal.

Hi we ran into a strange situation:

In a working OPNsense master/slave configuration the master suddenly stops working.

No messages, no infos.
So we thought it is a hardware bug and replaced the complete master unit.
Same result.
So we thought it must be the software and we went back from 20.1.3 to 20.1.0, because at this time it was running already 4 weeks without problem.
Same result.

After searching a very long time we found a FreeBSD bug report from 2015 which is still not solved in the latest 12 version:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319

And yes, we added temporarily a bridge to our old datacenter.

As result:
You can not use a bridge on an interface where you run CARP !

Be aware of that.

via: https://forum.opnsense.org/index.php?topic=1269.0
refs: https://unbound.net/pipermail/unbound-users/2008-August/000166.html

Hello,

i have wired problems with latest build (latest source, armv7)

Everything seems to work so far, but i see the following errors in the dmesg log:

mmcsd0: Error indicated: 2 Bad CRC
g_vfs_done():ufs/OPNsense[WRITE(offset=1789820928, length=131072)]error = 5
mmcsd0: Error indicated: 2 Bad CRC
g_vfs_done():ufs/OPNsense[WRITE(offset=1793687552, length=131072)]error = 5
mmcsd0: Error indicated: 2 Bad CRC
g_vfs_done():ufs/OPNsense[WRITE(offset=1794113536, length=131072)]error = 5
mmcsd0: Error indicated: 2 Bad CRC
g_vfs_done():ufs/OPNsense[WRITE(offset=1794605056, length=131072)]error = 5
mmcsd0: Error indicated: 2 Bad CRC
g_vfs_done():ufs/OPNsense[WRITE(offset=1795522560, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1795948544, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1796079616, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1796440064, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1796866048, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1797357568, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1797783552, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1798701056, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1798832128, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1799192576, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1799618560, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1799913472, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1800044544, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1800470528, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1801682944, length=131072)]error = 5
g_vfs_done():sdhci_fdt0-slot0: ufs/OPNsense[WRITE(offset=1802108928, length=131072)]Got data interrupt 0x00000002, but there is no active command.
error = 5
sdhci_fdt0-slot0: ============== REGISTER DUMP ==============
sdhci_fdt0-slot0: Sys addr: 0x01182300 | Version:  0x00000202
sdhci_fdt0-slot0: Blk size: 0x00005200 | Blk cnt:  0x000000ef
sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000023
sdhci_fdt0-slot0: Present:  0x01f70000 | Host ctl: 0x00000025
sdhci_fdt0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_fdt0-slot0: Wake-up:  0x00000000 | Clock:    0x00000207
sdhci_fdt0-slot0: Timeout:  0x0000000d | Int stat: 0x00000000
sdhci_fdt0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00b3
sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_fdt0-slot0: Caps:     0x21fcc8b2 | Caps2:    0x00002f77
sdhci_fdt0-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_fdt0-slot0: ===========================================
g_vfs_done():ufs/OPNsense[WRITE(offset=1802240000, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1802371072, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1804206080, length=131072)]error = 5
g_vfs_done():ufs/OPNsense[WRITE(offset=1805680640, length=131072)]error = 5
mmcsd0: Error indicated: 2 Bad CRC
g_vfs_done():ufs/OPNsense[WRITE(offset=1783922688, length=131072)]error = 5

i tought that the trim code could be the cause, but i even if i comment out the code in /usr/local/etc/rc the problem still exists, or is a fresh install needed?

Even if offloading is disabled The checksums on my APU1 seem to be wrong (according to the output of tcpdump) this leads to dropped packets (no packets get out of my network). The device has already been rebooted and I also tried setting it manually via ifconfig but it does not work - so the driver is broken. Can I switch to another kernel with the old driver by installing it via scp (firmware update page or pkg update will not work)

CC @Farma12

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

I have random crashes in OPNSense. At the time of the crash i have no internet, no DHCP, no DNS (all which work via the router, DHCP and Unbound). if i log in the console i can ping internet however. but not from the lan, and routing doesn't work between lans or to internet.

I had a hard time finding logs that could give me an insight in what the problem was, but yesterday i had a log message on the console login page which gives me something, and i hope you guys can help me make sense of it and/or point me in the right direction.

The reason i created a issue here is because i saw there are some more problems with the HBSD SEGVGUARD, so i would like to help troubleshoot, but i need some directions where to look..

the message i get is:

[HBSD SEGVGUARD] [/user/sbin/arp (41031) Suspension expires.
-> pid: 41031 ppid: 71889 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT>

I would appreciate any help!

hello .
I'm trying to install "opnsense 19.1" on a device, after initializing the pendrive (using the serial image) and it boots normally until trying to recognize the interfaces the system restarts.
Does anyone know something about?

thank you :)

Hey @lattera,

On my vm (osx Parallels) I seem to have quite some of the following messages:

[585147] [HBSD SEGVGUARD] pax_segvguard_lookup:419 stat error. Bailing.
[585147]  -> pid: 44680 ppid: 1 p_pax: 0xa50<SEGVGUARD,ASLR,NOSHLIBRANDOM,NODISALLOWMAP32BIT> 

FreeBSD OPNsense.localdomain 11.2-RELEASE-p6-HBSD FreeBSD 11.2-RELEASE-p6-HBSD 5d1a9ca(master)-dirty amd64

I didn't notice any other odd behaviour.

Best regards,

Ad

When shared forwarding is enabled and traffic is send to a non existing interface it can lead to erratic panics it seems.

Tested on both HardenedBSD 11.2 and 12.1, where the latter seems to crash sooner (easier to reproduce).

Steps below are executed on the 12.1 version.

Test setup

[client 1] ---> [igb0 ----OPNsense--- igb4] <---- [client 2]

client 1 has a couple of tcp sessions (ssh, https) to igb0, while client 2 keeps pinging igb4's address.

Relevant rules:

pass in quick on igb4 route-to ( wg0 192.168.2.1 ) inet from {any} to {!(igb4:network)} keep state 
pass in quick on igb0 inet from {any} to {any} keep state

Interface wg0 doesn't exist during test.

Result

After some time, the machine panics, although the messages are not always exactly alike, I've added some partial textdumps below:

Example from 11.2:

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x8
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80cc19a0
stack pointer           = 0x28:0xfffffe0231e793b0
frame pointer           = 0x28:0xfffffe0231e793e0
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         = 12 (irq278: igb0:que 2)

Tracing pid 12 tid 100070 td 0xfffff800190b0000
sbcut_internal() at sbcut_internal+0x40/frame 0xfffffe0231e793e0
tcp_do_segment() at tcp_do_segment+0xfeb/frame 0xfffffe0231e794e0
tcp_input() at tcp_input+0xf5b/frame 0xfffffe0231e79640
ip_input() at ip_input+0x141/frame 0xfffffe0231e796a0
netisr_dispatch_src() at netisr_dispatch_src+0xa8/frame 0xfffffe0231e796f0
ether_demux() at ether_demux+0x140/frame 0xfffffe0231e79720
ether_nh_input() at ether_nh_input+0x336/frame 0xfffffe0231e79780
netisr_dispatch_src() at netisr_dispatch_src+0xa8/frame 0xfffffe0231e797d0
ether_input() at ether_input+0x26/frame 0xfffffe0231e797f0
igb_rxeof() at igb_rxeof+0x721/frame 0xfffffe0231e79890
igb_msix_que() at igb_msix_que+0x117/frame 0xfffffe0231e798e0
intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe0231e79920
ithread_loop() at ithread_loop+0xe7/frame 0xfffffe0231e79970
fork_exit() at fork_exit+0x83/frame 0xfffffe0231e799b0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0231e799b0

Example from 12.1:

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x8
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80d70680
stack pointer           = 0x28:0xfffffe003faf3300
frame pointer           = 0x28:0xfffffe003faf3330
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_2)
trap number             = 12
panic: page fault

db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe003faf2fb0
vpanic() at vpanic+0x1a2/frame 0xfffffe003faf3000
panic() at panic+0x43/frame 0xfffffe003faf3060
trap_fatal() at trap_fatal+0x39c/frame 0xfffffe003faf30c0
trap_pfault() at trap_pfault+0x49/frame 0xfffffe003faf3120
trap() at trap+0x29f/frame 0xfffffe003faf3230
calltrap() at calltrap+0x8/frame 0xfffffe003faf3230
--- trap 0xc, rip = 0xffffffff80d70680, rsp = 0xfffffe003faf3300, rbp = 0xfffffe003faf3330 ---
sbcut_internal() at sbcut_internal+0x40/frame 0xfffffe003faf3330
tcp_do_segment() at tcp_do_segment+0x22d5/frame 0xfffffe003faf3420
tcp_input() at tcp_input+0xdf6/frame 0xfffffe003faf35a0
ip_input() at ip_input+0x175/frame 0xfffffe003faf3650
netisr_dispatch_src() at netisr_dispatch_src+0xcf/frame 0xfffffe003faf36a0
ether_demux() at ether_demux+0x139/frame 0xfffffe003faf36d0
ether_nh_input() at ether_nh_input+0x346/frame 0xfffffe003faf3730
netisr_dispatch_src() at netisr_dispatch_src+0xcf/frame 0xfffffe003faf3780
ether_input() at ether_input+0x4b/frame 0xfffffe003faf37b0
iflib_rxeof() at iflib_rxeof+0xaae/frame 0xfffffe003faf38a0
_task_fn_rx() at _task_fn_rx+0x75/frame 0xfffffe003faf38e0
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x144/frame 0xfffffe003faf3940
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x98/frame 0xfffffe003faf3970
fork_exit() at fork_exit+0x83/frame 0xfffffe003faf39b0

Changing the route-to to a non existing address on an existing interface seems to be stable, which is expected.

3ware tws driver has TWS_MAX_NUM_LUNS set to 16 but this is not enough. I think the maximum LUN's should be 255.

I have the issue on my 3ware 9750-8i controller with a RAID array spanned into 21 volumes. Only volume the first 16 volumes are detected.

CAMCONTROL DEVLIST

<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 0 (pass0,da0)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 1 (pass1,da1)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 2 (pass2,da2)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 3 (pass3,da3)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 4 (pass4,da4)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 5 (pass5,da5)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 6 (pass6,da6)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 7 (pass7,da7)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 8 (pass8,da8)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun 9 (pass9,da9)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun a (pass10,da10)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun b (pass11,da11)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun c (pass12,da12)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun d (pass13,da13)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun e (pass14,da14)
<LSI 9750-8i DISK 5.12> at scbus0 target 0 lun f (pass15,da15)

DMESG

(probe0:tws0:0:0:10): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:tws0:0:0:10): CAM status: Invalid Lun
(probe0:tws0:0:0:10): Error 22, Unretryable error
(probe0:tws0:0:0:11): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:tws0:0:0:11): CAM status: Invalid Lun
(probe0:tws0:0:0:11): Error 22, Unretryable error
(probe0:tws0:0:0:12): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:tws0:0:0:12): CAM status: Invalid Lun
(probe0:tws0:0:0:12): Error 22, Unretryable error
(probe0:tws0:0:0:13): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:tws0:0:0:13): CAM status: Invalid Lun
(probe0:tws0:0:0:13): Error 22, Unretryable error
(probe0:tws0:0:0:14): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:tws0:0:0:14): CAM status: Invalid Lun
(probe0:tws0:0:0:14): Error 22, Unretryable error

In tws(4) driver sources I see:
if (ccb_h->target_lun >= TWS_MAX_NUM_LUNS) {
...
ccb_h->status |= CAM_LUN_INVALID;
}

Where TWS_MAX_NUM_LUNS is 16. So it is clear why it does not work. The only question is whether a higher value could provoke issues on other controllers.

I changed the value to 32 (to be safe) and it works like a charm.

See topic https://forum.opnsense.org/index.php?topic=7277.0. When upgrading to 18.1 I immediately lost my ability to route to many sites, namely Video and Streaming music sites as well as Android upgrades over wifi. After trying nearly everything, I finally booted to the old 11.0 kernel and it routes every bit as well as it did in 17.7.x. Something happened in the 11.1 kernel that is messing me up.

To be clear I am running the FreeBSD 11.0-RELEASE-p17 kernel on 18.1.3 to be able to use it.

For those brave users who want to enable procfs, import procfs hardening from HardenedBSD so attackers can't abuse it.

Important notices

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

• I have searched the existing issues and I'm convinced that mine is new.

Describe the bug

The internal eMMC of my Upboard could be detected by both FreeBSD 11.2 and OPNsense v18 . On v19.1, it fails with a "Error reading EXT_CSD Bad CRC". I thought the board was bad and so went back to reinstall FreeBSD 11.2 and the problem was not there.

Expected behavior
OPNsense should distribute a version of HardernedBSD 11.2 that supports all the eMMC modules that FreeBSD 11.2 supports.

Relevant log files
If applicable, information from log files supporting your claim.

Environment

OPNsense 19.1.4 (amd64, OpenSSL).
Intel Atom® x5-Z8350 Processor (2M Cache, 1.44 GHz up to 1.92 GHz) CPU with 64-bit architecture; Quad Core
Network Realtek RTL8111G (LDO)

https://www.intel.com/content/www/us/en/support/articles/000022699/emerging-technologies/intel-realsense-technology.html

你好，请问如何进行多语言翻译？

Penetration testing / vulnerability assesment team reported that Unbound instance installed on OPNSense appliance is vulnerable to CVE-2008-1447
"Synopsis: The remote name resolver (or the server it uses upstream) is affected by a DNS cache poisoning vulnerability."

The security.bsd.unprivileged_proc_debug sysctl node allows unprivileged users (non-root users) to use debugging facilities. FreeBSD defaults this to 1 and HardenedBSD defaults it to 0. Follow HardenedBSD.

As 10.0 approaches EOL end of this February, it's time to move to 10.1 instead.

Hi,
Yes, this is not a real issue, sorry for this :)
I'm asking if is it possible to have netdiscover, or arpscan, into OPNsense, it could be helpfull in Interfaces/Diagnostic tools to see what IP is available in a LAN.

I do not have any preferences if netdiscover or arpscan even if i use netdiscover frequently, arpscan is good enough.

I can also develop it by myself and then ask you a pull request, here in github, first I need to know if this feature is needed by others users.

It could be great having also a generic arpping and a arpwatch process, if possibile :)
These could alert when ip collisions happens.

let me know if interested,
bye

• Branding
• Review ngctl change
• ASLR
• ports.git/opnsense/syslogd update

Is it possible to bring in a pf patch from FreeBSD?
https://svnweb.freebsd.org/base?view=revision&revision=301998
freebsd/freebsd-src@b06d3a6

This would bring in functionality that pfSense had with it's custom patches, but with an official patch.

It appears that set-tos in scrub rules alone is not enough to support google fiber's full upload speeds; even though ToS is somewhat backwards compatible with CoS, the ToS is put inside the tagged vlan packets, whereas CoS is in the ethernet frame itself, outside the tagged vlan, and therefor is only compatible with CoS when using the native (untagged) vlan.

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[x] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199489. Patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201695

To Reproduce
Configure an IPv6 port forwarding rule. tcpdump will show that pf alternates between a link local and a global IPv6 address.

Expected behavior
Expect to not have the link local address used.

I created an IPv6 firewall rule using a gateway (GIF, WireGuard). The rule matches but traffic is sent to the default gateway (netstat -6rn)

To Reproduce
Steps to reproduce the behavior:

1. Create an IPv6 firewall rule using a default gateway
2. Test it

Expected behavior
Routing over the gateway which is specified in the rule

Environment
Software version used and hardware type if relevant.
e.g.:

OPNsense 19.1.6 (amd64, OpenSSL).
AMD APU, KVM VM, ..

Also see https://forum.opnsense.org/index.php?topic=10846.0, https://forum.opnsense.org/index.php?topic=11988.msg57209

To better track down shared forwarding (SF) issues popping up the last days/weeks, I'll create this issue to get a better overview since most of them are here but also one in the forums:

• Broken port forward, works with disabling SF, asked for detailed steps to reproduce https://forum.opnsense.org/index.php?topic=12099.0
• Dual Master cause of "dropped" carp packets when SF is enabled opnsense/core#3411 all (2) users report back it works without SF; asked for more details about switches
• IPv6 policy routing not working https://github.com/opnsense/core/issues/3424
• opnsense/core#2376 bit confusing to read, disable sticky session + SF enabled works, sticky session enabled + SF enabled fails (this affects LB setups), sticky session eanbled and SF disabled works. The thread OP just disabled sticky session, this is OK in failover setups

I'll now try to reproduce where possible ... anyone who wants to jump in, very welcome :)
New problem descriptions please in separate issues as this one only collects them.

HardenedBSD/hardenedBSD@71fab80
freebsd/freebsd-src@fe94e6f

Both are possible CVE candidate ...

https://forum.opnsense.org/index.php?topic=4183.0
http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false

Please is possible to add support for Intel 802.11ac cards? For example for 8260NGW etc... thanks a lot.

I am trying to open a VPN IPSec tunnel between an Opnsense and another VPN IPSec capable server (freebsd). If both equipements are on differents subnets, it works like a charme. But, if both equipements are on the same subnet, when the Opnsense is the initiator I cannot mount up the tunnel.

I try to explain you the issue:

A) Mounting the tunnel

[ 192.168.0.0/24 ] [ 192.168.1.0/24 ]
[opnsense] <-----------> [router] <-------------> [VPN serveur]

It works.

B) Mounting the tunnel

[ 192.168.0.0/24 ]
[opnsense] <--> [VPN serveur]

It doesn't work if the opnsense is the initiatior.

Taking dumps I can see that the packets MAC destination address is the Opnsense gateway. It is not correct, because both equipments are on the same subnet so the MAC destination address of the packet must be the MAC of the equipement and not the gateway's MAC.

Coud you confirme the problem? If I remember well, I think that the same problem is present on Pfsense.

Do not hesitate to ask me more questions about the problem. I couldn't give you configurations or dumps because of the security context.

Alejandro

In multiple files, there is a typo in the copyright header for AS IS.

...
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES
...