Recent posts

#1

26.7 Series / openvpn keepalive timeout

Last post by fengchen_opn - Today at 03:51:56 AM

It seems there is no keep-alive setting in the OpenCPN server.
OPNsense 26.7.3_8-amd64
client  Openvpn

#2

German - Deutsch / Re: Extrem Schlechte Download-...

Last post by Maurice - Today at 02:03:06 AM

Könnte schon der axp-Treiber sein bzw. dessen Interaktion mit PPPoE + VLAN-Tagging.

Hast Du die Möglichkeit, das Glasfasermodem 2 an den SFP-Ports zu testen, und / oder die GPON-SFPs an den Intel-Ports (mittels Kupfer-SFP / Medienkonverter / Switch )?

#3

26.7 Series / Re: Fetching base-26.7.3-amd64...

Last post by newsense - Today at 01:19:18 AM

Change the mirror.

Try this in the terminal. If it finishes successfully reboot. Else post the output here

Code Select Expand

opnsense-update -bkr 26.7.3

#4

Development and Code Review / Re: netflector available as pl...

Last post by UnicronHD - Today at 01:16:09 AM

Can you create a PR for https://github.com/opnsense/ports preferably under opnsense/netreflector to avoid clashing with an eventual FreeBSD inclusion? The files can stay the same, but so we know it's out of tree.

Done: https://github.com/opnsense/ports/pull/286.

#5

German - Deutsch / Frage zur neuen Default allow ...

Last post by Jayfrog - September 01, 2026, 11:34:19 PM

Hallöchen!

Früher war es ja so:

Man hat OPNsense installiert und unter LAN waren IPV4/6 Default allow LAN to any rule aktiv.

Dann hat man selbst Regeln definiert und konnte später die Regeln einfach deaktivieren.

Jetzt gibt es diese Möglichkeit allerdings nicht mehr.



Die Lockout Rule zu deaktivieren brachte keine Erfolg und ich wüsste zwar wie ich sie mit einer Gegenregel aushebel, aber ist das wirklich im Sinn des Erfinders?

#6

Development and Code Review / Re: netflector available as pl...

Last post by UnicronHD - September 01, 2026, 10:50:15 PM

Careful that you don't accumulate too many edge cases and turning it into an unmaintainable swiss army knife without a clear identity.

Thanks for the insight. I will definitely get familiar with the Roon/RAAT before making a decision. So far, everything netflector supports (except WSD) is something I actually use in my setup. WSD was added mostly because of its similarity to what I had already implemented by then.

[Warning]

#7

General Discussion / Re: DHCP Issues on VLAN 90 wit...

Last post by 350flyer - September 01, 2026, 10:47:33 PM

1. What is the best way to capture DHCP traffic on the VLAN 90 interface in OPNsense?

When troubleshooting it's worth checking the log files - https://docs.opnsense.org/manual/logging_services.html

The simplest way to see if OPNsense is seeing a DHCP request on VLAN 90 is to look at Kea's log file: Services -> Kea DHCP -> Log File

This will most likely open with a view listing Warning. To see DHCP requests and acknowledgements, from the drop-down list select Informational.

To capture packets use the packet capture tool - https://docs.opnsense.org/manual/diagnostics_interfaces.html#packet-capture

Interfaces -> Diagnostics -> Packet Capture

 - Select the interface
 - Enable Promiscuous
 - Set Protocol to UDP
 - Set Port to 67
 - Set Count to 2
 - Click on 'Start'

Connect a device to VLAN 90. If after a few minutes the job is still running it would be worth seeing if a request was received by clicking on the "View capture in standard detail" icon.

I have now done packet captures, although I initially wasn't seeing any DHCP traffic on OPNsense. I will also check the Kea log specifically at the Informational level as you suggest, because that should independently tell me whether Kea is actually receiving a DHCP request.

One interesting result so far is that I captured traffic directly on the EAP773 and can see the client's DHCP Discover with VLAN ID 90.

I then captured on OPNsense, including the VLAN 90 interface and the physical parent interface, while forcing the client to release and renew its DHCP lease. I did not see the DHCP Discover arriving at OPNsense.

So at the moment I have:

Client → EAP773: DHCP Discover visible, VLAN 90 tagged
EAP773 → switch: expected VLAN 90
Switch → OPNsense: DHCP Discover not currently visible
Kea: still checking the log for confirmation

I'll repeat the OPNsense capture using your exact settings:

Interface: VLAN 90
Promiscuous: enabled
Protocol: UDP
Port: 67
Start capture
Force the client to renew DHCP
Inspect the live capture

I'll also check the Kea log under Services → Kea DHCP → Log File with the filter set to Informational.

Like you I'm largely self-taught and still fairly new to this, but I can at least offer a couple of suggestions:

• Connect a laptop (or other device that you can manually configure) to the Wifi network, configure a static IP appropriate to the network, and then see if it can ping the router's IP on that network. That can tell you if there's any communication getting to the router at all.
• Maybe also try setting up a VLAN 90 access port on the switch and see if your tests change at all there.
• If you're using a centralized management interface for the network hardware, maybe check the switch and APs directly as well and make sure the configs are what you think they are.

I have actually been trying to isolate the problem in exactly this way.

I have now confirmed that the VLAN 90 interface on OPNsense is 192.168.90.1/24, and the client is associated with the CCTV_WIFI SSID but receives a 169.254.x.x address.

I also performed a packet capture directly on the EAP773. The interesting part is that I can see the client's DHCP Discover being transmitted with 802.1Q VLAN 90.

However, when I capture on OPNsense, I cannot see the DHCP Discover arriving on the VLAN 90 interface. I also tried capturing on the physical parent interface and filtering for DHCP/UDP 67/68, but still didn't see it.

So your static-IP suggestion is a good next test because it removes DHCP completely from the equation (in theory ). I'll temporarily configure the laptop with something like:

192.168.90.200 / 255.255.255.0
Gateway: 192.168.90.1

and then try to ping 192.168.90.1.

I'll also configure an unused switch port as an untagged/access port for VLAN 90 and connect the laptop directly. That should give us two very useful tests:

1. Wi-Fi + static IP → ping 192.168.90.1

2. Wired VLAN 90 access port + DHCP

If the static Wi-Fi client cannot reach 192.168.90.1, then this isn't really a DHCP problem — the VLAN 90 traffic isn't reaching the OPNsense interface correctly.

If the static Wi-Fi client can reach 192.168.90.1, then the VLAN path is working and we can concentrate on Kea DHCP.

And if the wired VLAN 90 client gets a DHCP lease, that would strongly point toward the EAP773/SSID side of the problem.

Thanks  for that,  I think the static-IP test is one of the best ways to separate the possibilities

#8

26.1, 26,4 Series / Re: Cron scheduled missing?

Last post by DEC740airp414user - September 01, 2026, 09:56:33 PM

I should create my posts while I am in front of the console.   Yes Cron is where you said but

  My full reason for the post is seeing scheduled jobs under system.   It can do similar but with less instructions?

I still have an ids rule I can't delete under Cron from a year ago. 

Which should be used going forward

#9

26.7 Series / Re: Fetching base-26.7.3-amd64...

Last post by nerd - September 01, 2026, 09:09:16 PM

Nobody has an idea?

#10

German - Deutsch / Re: SSD Killer gesucht

Last post by stulpinger - September 01, 2026, 08:30:46 PM

Zenarmor am Laufen ?