Messages

1

23.1 Legacy Series / Regular IPv6 Kernel Panics in 23.1

« on: March 14, 2023, 03:06:40 pm »

I believe this is a continuation of the issue found here: https://forum.opnsense.org/index.php?topic=29467.0

I just wanted to make others aware; I swapped an Intel X520-DA2 into my system and immediately started noticing spontaneous kernel panics; sometimes in as little as 30 minutes but at least once a day.

Similar call stack:

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x10
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80eb8bed
stack pointer         = 0x28:0xfffffe00105994b0
frame pointer         = 0x28:0xfffffe00105995d0
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_0)
trap number = 12
panic: page fault
cpuid = 0
time = 1677909596
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0010599270
vpanic() at vpanic+0x17f/frame 0xfffffe00105992c0
panic() at panic+0x43/frame 0xfffffe0010599320
trap_fatal() at trap_fatal+0x385/frame 0xfffffe0010599380
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00105993e0
calltrap() at calltrap+0x8/frame 0xfffffe00105993e0
--- trap 0xc, rip = 0xffffffff80eb8bed, rsp = 0xfffffe00105994b0, rbp = 0xfffffe00105995d0 ---
ip6_forward() at ip6_forward+0x62d/frame 0xfffffe00105995d0
pf_refragment6() at pf_refragment6+0x164/frame 0xfffffe0010599620
pf_test6() at pf_test6+0xfdb/frame 0xfffffe0010599790
pf_check6_out() at pf_check6_out+0x40/frame 0xfffffe00105997c0
pfil_run_hooks() at pfil_run_hooks+0x97/frame 0xfffffe0010599800
ip6_tryforward() at ip6_tryforward+0x2ce/frame 0xfffffe0010599880
ip6_input() at ip6_input+0x60f/frame 0xfffffe0010599960
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe00105999b0
ether_demux() at ether_demux+0x138/frame 0xfffffe00105999e0
ng_ether_rcv_upper() at ng_ether_rcv_upper+0x88/frame 0xfffffe0010599a00
ng_apply_item() at ng_apply_item+0x2bd/frame 0xfffffe0010599aa0
ng_snd_item() at ng_snd_item+0x28e/frame 0xfffffe0010599ae0
ng_apply_item() at ng_apply_item+0x2bd/frame 0xfffffe0010599b80
ng_snd_item() at ng_snd_item+0x28e/frame 0xfffffe0010599bc0
ng_ether_input() at ng_ether_input+0x4c/frame 0xfffffe0010599bf0
ether_nh_input() at ether_nh_input+0x1f1/frame 0xfffffe0010599c50
netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe0010599ca0
ether_input() at ether_input+0x69/frame 0xfffffe0010599d00
iflib_rxeof() at iflib_rxeof+0xc27/frame 0xfffffe0010599e00
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe0010599e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame 0xfffffe0010599ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame 0xfffffe0010599ef0
fork_exit() at fork_exit+0x7e/frame 0xfffffe0010599f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0010599f30
--- trap 0x8038b000, rip = 0xffffffff80c30e8f, rsp = 0, rbp = 0 ---
mi_startup() at mi_startup+0xdf
KDB: enter: panic
panic.txt0600001214400557134  7134 ustarrootwheelpage faultversion.txt0600007414400557134  7537 ustarrootwheelFreeBSD 13.1-RELEASE-p6 stable/23.1-n250396-d34cd428508 SMP
I did build the official Intel ix driver against 23.1 sources because the official FreeBSD wasn't routing at 10G, per franco's method here. I only noticed these kernel panics begin after enabling VLAN hardware filtering on the NIC as my IOT VLAN was not working at all without.

Again, I just wanted to point this out in case others run into a similar issue and in case this is still a relevant issue being tracked by the opnsense team. Setting the tunable net.pf.share_forward6="0" did indeed resolve the issue for me.

2

22.7 Legacy Series / Re: IPv6: Disable EUI64 auto address assignment on WAN from ISP RA?

« on: December 04, 2022, 06:35:04 pm »

I opened another support ticket with Webpass after looking over this again; the gist is that opnsense (really FreeBSD) is diligently and correctly obeying the flags set in the RA which suggests it should grab a SLAAC address in the 2604:5500:30c8::/64 prefix, which it is doing EUI-64 style. Per the advertisment the address is valid and routable, but Webpass is dropping traffic from it claiming it is not assigned or in a valid range.

The fix here is for Webpass to stop flagging L+A and just flag L. The workaround (which I haven't figured out how to accomplish) would be to tell FreeBSD to ignore SLAAC on this IF and just used DHCPv6.

Webpass has escalated to their engineering team to have a look at the configuration, hopefully they'll realize they either need to permit valid SLAAC addresses in the range they are advertising or move to stateful only RAs.

I am already pulling a /56 PD via DHCPv6 and the DHCPv6 server will (optionally) provide my WAN IF with an address. The issue is FreeBSD sees the SLAAC RAs first and generates the EUI-64 address early/with a higher priority metric so local IPV6 traffic from the router itself originates from the EUI-64 address and gets dropped (making things like unbound time out or extremely slow when resolving upstream). This change actually prevents unbound from respecting prefer IPv4 and causes the pitifully slow DNS performance when the router itself doesn't have a valid WAN facing IPv6 assignment.

3

22.7 Legacy Series / IPv6: Disable EUI64 auto address assignment on WAN from ISP RA?

« on: December 02, 2022, 07:26:25 pm »

Hello! I recently switched over to opnsense after leaving pfsense behind at the 2.4.5 release.

Both router distros have had IPv6 issues with my ISP (Google Webpass) since I moved here and started service with them. Don't get me wrong the service is great, but something about their IPv6 configuration just does not cooperate with FreeBSD routers by default.

More specifically, their router always sends me IPv6 RAs with prefix information with L+A flags set. As a result FreeBSD is taking the prefix and auto assigning an EUI64 address from it for the WAN interface; in my case the Router Advertisement looks like this.

Despite the fact that I think opnsense is "technically correct" here; Webpass is sending 2604:5500:30c8::/64 and telling me to autoconfig inside that prefix, Webpass blackholes traffic from the EUI64 auto configured address on the WAN interface (2604:5500:30c8:0:ae1f:6bff:fe83:22f7):

Code: [Select]

igb1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN
        options=4e0002b<RXCSUM,TXCSUM,VLAN_MTU,JUMBO_MTU,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
        ether ac:1f:6b:83:22:f7
        inet6 fe80::ae1f:6bff:fe83:22f7%igb1 prefixlen 64 scopeid 0x2
        inet6 2604:5500:30c8:0:ae1f:6bff:fe83:22f7 prefixlen 64 autoconf
        inet6 2604:5500:30c8::662 prefixlen 128
        inet 136.30.119.91 netmask 0xfffffc00 broadcast 136.30.119.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

I need to find a way to prevent opnsense from assigning that autoconf EUI64 address on the WAN IF or else all IPv6 traffic originating from the firewall itself fails. By default the router is using 2604:5500:30c8:0:ae1f:6bff:fe83:22f7 instead of the DHCPv6 assigned address 2604:5500:30c8::662; all my LAN clients do get an IPv6 address via either SLAAC or DHCPv6 from the valid /56 PD that they serve me, so they all work fine, but stuff like DNS from the router grinds to a halt or barely works at all.


I *think* the fix is to simply remove the ACCEPT_RTADV from the WAN if (igb1) and allow the DHCPv6 client to grab a prefix to pass to the LAN if and a WAN IP for the router to use. I just can't figure out the appropriate place to patch opnsense to ensure that flag is no longer set for my WAN if. (I'm also not really clear if doing so is going to break the IPv6 routing table; maybe I would rather just have radvd ignore the A flag on the RA?)

Thanks for any advice!