Recent posts

#1

General Discussion / Re: Let's AI Opnsense!

Last post by meyergru - Today at 10:07:59 PM

Yes, and ironically, NetworkChuck gave the root API key to the AI agent... :-(

Well, before that he bought a chinese box with RealTek NICs, so what could we expect?

#2

General Discussion / Re: Let's AI Opnsense!

Last post by muchacha_grande - Today at 09:40:56 PM

Coincidentally this video was published today https://youtu.be/a3RI4DjFBzw

#3

General Discussion / Unexpected WAN DHCPv6-PD resta...

Last post by PoMpIs - Today at 09:38:18 PM

I am seeing an issue where a physical link change on a LAN interface causes IPv6 on the PPPoE WAN to be reconfigured/restarted.

Setup
OPNsense 26.7.2_2
WAN: PPPoE on pppoe0
ISP: DIGI Spain
DHCPv6-PD: /56
LAN interfaces: Intel E810 (ice0, ice1, ice2)
WAN interface: Intel X550-T2

The problem is easy to reproduce: if a device is connected directly to a LAN interface and that device is powered off or the cable is disconnected, the LAN interface goes LINK_DOWN.

Shortly afterwards, OPNsense triggers IPv6 processing on pppoe0 and DHCPv6-PD is restarted/reconfigured, causing loss of IPv6 connectivity on all LAN/VLAN interfaces using the delegated prefix.

The PPPoE WAN itself does not go down and IPv4 remains working.

This is not specific to the Intel E810. I have reproduced the same behaviour with several different NICs.

I also reproduced the issue after replacing Kea/radvd on the affected LAN with dnsmasq handling DHCPv6 and Router Advertisements, so the problem does not appear to be specific to Kea or radvd.

Behaviour after the LAN link event

When the issue is triggered, dhcp6c on pppoe0 gets stuck in the SOLICIT state and keeps retransmitting without receiving an ADVERTISE:

Code Select Expand

Sending Solicit on pppoe0
send so
licit to ff02::1:2%pppoe0
reset a timer on pppoe0, state=SOLICIT, timeo=6, retrans=72361

Sending Solicit on pppoe0
send solicit to ff02::1:2%pppoe0
reset a timer on pppoe0, state=SOLICIT, timeo=7, retrans=144580

Shortly afterwards, the LAN interfaces lose their delegated IPv6 prefixes and radvd reports errors such as:

radvd_configure_do(manual) found no suitable IPv6 address on opt11(ice0)
radvd_configure_do(manual) found no suitable IPv6 address on opt3(vlan011)
radvd_configure_do(manual) found no suitable IPv6 address on opt6(vlan050)
A normal DHCPv6-PD negotiation after boot completes almost immediately:

SOLICIT -> ADVERTISE -> REQUEST -> REPLY

So the failure only appears after DHCPv6-PD processing is triggered by the LAN link-state event.

Workaround

As a workaround, I modified /usr/local/etc/rc.linkup to ignore link events from the affected LAN interfaces.

With those LAN link events ignored, powering devices on/off or disconnecting the cable no longer affects the WAN IPv6 connection.

The added workaround is:

Code Select Expand

#!/usr/local/bin/php
<?php

/*
* Copyright (C) 2003-2005 Scott Ullrich <sullrich@gmail.com>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice,
*    this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*    notice, this list of conditions and the following disclaimer in the
*    documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
*/

require_once("config.inc");
require_once("auth.inc");
require_once("filter.inc");
require_once("interfaces.inc");
require_once("util.inc");
require_once("system.inc");

exit_on_bootup();

if ($argc < 3) {
   exit;
}

// Workaround for an issue where a physical LINK_UP/LINK_DOWN event on a LAN
// interface causes OPNsense to trigger IPv6 WAN processing on pppoe0.
//
// In my setup, powering off a device directly connected to ice0/ice1/ice2
// can indirectly trigger DHCPv6-PD reconfiguration on the unrelated PPPoE WAN,
// resulting in loss of IPv6 connectivity.
//
// Ignoring DEVD link events from these LAN interfaces completely prevents
// the unwanted DHCPv6-PD reset/reconfiguration.
//
// This is only a workaround for debugging/reporting purposes.
$ignored_interfaces = [
   'ice0',
   'ice1',
   'ice2',
];

$action = $argv[1];
$device = $argv[2];

// Stop processing LAN carrier events before they can propagate further
// through rc.linkup and eventually affect WAN IPv6/DHCPv6-PD handling.
if (in_array($device, $ignored_interfaces, true)) {
   log_msg(sprintf(
       "DEVD: Ignored Ethernet %s event for %s to avoid DHCPv6-PD reset",
       $action,
       $device
   ));
   exit;
}

function handle_argument_group($action, $device)
{
   global $config;

   $interface = convert_real_interface_to_friendly_interface_name($device);

   if (empty($interface)) {
       return;
   }

   if (empty($config['interfaces'][$interface])) {
       return;
   }

   if (!isset($config['interfaces'][$interface]['enable'])) {
       return;
   }

   switch ($action) {
       case 'stop':
           log_msg(sprintf("DEVD: Ethernet detached event for %s(%s)", $interface, $device));
           interface_suspend($interface);
           break;

       case 'start':
           log_msg(sprintf("DEVD: Ethernet attached event for %s(%s)", $interface, $device));
           interface_configure(false, $interface, true, true);
           break;

       default:
           log_msg(sprintf("DEVD: The action parameter passed is wrong (%s)", $action), LOG_ERR);
           break;
   }
}

handle_argument_group($action, $device);

I inserted this before handle_argument_group() in /usr/local/etc/rc.linkup.

Expected behaviour

I would expect a LINK_DOWN or LINK_UP event on an unrelated LAN interface not to restart or reconfigure DHCPv6-PD on pppoe0 while the PPPoE WAN itself remains up.

If I place a switch between OPNsense and the directly connected PC, the issue does not occur because the physical link on the OPNsense interface never goes down.

However, I use direct physical connections from OPNsense to some devices, so I would like to keep this topology without losing IPv6 every time one of those devices is powered off.

Thank you very much. 😊

#4

26.7 Series / Re: ath0 on 26.7

Last post by suur13 - Today at 09:31:20 PM

Looks to be working now after upgrade to 26.7.2_2

#5

General Discussion / Re: Please Make a Donation to ...

Last post by PoMpIs - Today at 07:57:44 PM

Well, I didn't know about the donations... I've been using Opnsense for two years and I don't think I'll ever stop, I love it...

So I've also sent a donation.

Thank you very much. 😊

#6

Web Proxy Filtering and Caching / Re: Caddy Reverse Proxy Not Re...

Last post by Monviech (Cedrik) - Today at 07:51:24 PM

If your OPNsense has eg 192.168.10.1 on thr LAN interface, your DNS overrides have to point proxmox.internal (and any other hostnames) to 192.168.10.1.

How else should Caddy get the traffic to proxy?

192.168.10.4 port 80 from 192.168.10.89:
Thats Proxmox directly from one of your clients, OPNsense and Caddy sees nothing.

#7

26.7 Series / No install on my new CWWK

Last post by JosselinFERREIRA - Today at 07:49:13 PM

Hardware: CWWK-style mini PC, Intel N150 (4c/4t), 8 GB RAM, AMI BIOS TW4L101 (2024-12-02).
4x Intel I226-V (igc), EEPROM V2.32-0. OPNsense 26.7 live (FreeBSD 15.1-RELEASE-p1).

Problem: IMG : vga and UFS install onto onboard NVMe fails with:
  nvme0: PRP_OFFSET_INVALID (00/13)
  retries exhausted, UFS forcibly unmounting gpt/rootfs

NVMe identify:
  PCI 126f:2261  Silicon Motion SM2261XT (DRAM-less)
  Model NV-128G  FW X0925A  SN SCRW26012201P0693
  NVMe 1.3  MDTS 256K  HMB 64MB preferred=min
  Namespace 119GB, LBA 512 only, no metadata
  SMART: media errors 0, spare 100%, used 0%, temp 55C, POH 3h
  Driver nda (hw.nvme.use_nvd=0). Reads OK; installer writes fail.

Tried: hw.nvme.hmb_max=0 ; install on nvd vs nda. Same PRP error.
eMMC controller present but no card. NICs fine.

Is there a known workaround for SM2261XT / 126f:2261 besides replacing the SSD?

#8

Zenarmor (Sensei) / Re: How to block Firefox VPN

Last post by dirtyfreebooter - Today at 07:48:42 PM

i tried this and couldn't get the custom application to hit. i assume i am setting things up wrong.

i tried adjusting the custom app like 10x different ways. when i go back to the live sessions after updating custom app / policy, i still just see the entry allowed (green shield)

Custom apps in ZA are broken. And for some time now.

I already did open a ticket (21.10. 2025) for it, but it's in a backlog.

Regards,
S.

this makes sense, but i tried also making some other custom apps, and none of those worked either. like real simple ones, by IP address or just a port, so try and see if any custom app was working. seems like you said, custom apps just doesn't work and they apparently have no tests around that.

#9

Zenarmor (Sensei) / Re: How to block Firefox VPN

Last post by Seimus - Today at 07:22:35 PM

i tried this and couldn't get the custom application to hit. i assume i am setting things up wrong.

i tried adjusting the custom app like 10x different ways. when i go back to the live sessions after updating custom app / policy, i still just see the entry allowed (green shield)

Custom apps in ZA are broken. And for some time now.

I already did open a ticket (21.10. 2025) for it, but it's in a backlog.

Regards,
S.

#10

Development and Code Review / Re: Zabbix >=7.0 template for ...

Last post by bran.ko - Today at 07:18:38 PM

Nice work. It works :)