Messages

Could you give an example of what kind of missing bugfix could cause something like this? There is not a single service exposed to the internet, and only NTP and DNS from selected internal IPs. I do read the release notes of every new release. I don't tend to apply every update immediately, as these are rather frequent, and we did experience some issues in the past. So we developed a slower staging process.

If you feel this is not a safe way to run OPNsense and I am missing something important here, please let me know.

Thanks!
Urban

Hi all, we had a severe outage at a customer's site a few days ago (OPNsense stopped responding on all interfaces). After going through the logs I am baffled how this could happen. Maybe someone can help finding the cause for this.

The firewall in question is running 26.7.1_1 on a Protectli VP2440.

There is a multi WAN-Setup:
- igc0 has a PPPoE connection to the primary ISP
- igc1 has an ethernet connection to the backup ISP

On the LAN side there is a lagg0 with 2 10G Interfaces (ixl0, ixl1); all internal traffic is routed via a number of VLANs on this bond.

This is how the problem developed:

1) At first, dpinger alerted that both ISPs had packet loss:

<165>1 2026-09-29T17:18:18+02:00 hwk-gw01.c.cibex.net dpinger 10740 - [meta sequenceId="1"] ALERT: WAN1_PPPOE (Addr: 8.8.8.8 Alarm: none -> loss RTT: 17.9 ms RTTd: 0.1 ms Loss: 12.0 %)
<165>1 2026-09-29T17:18:18+02:00 hwk-gw01.c.cibex.net dpinger 10740 - [meta sequenceId="2"] ALERT: WAN2GW (Addr: 1.1.1.1 Alarm: none -> loss RTT: 22.2 ms RTTd: 0.4 ms Loss: 12.0 %)
<165>1 2026-09-29T17:18:30+02:00 hwk-gw01.c.cibex.net dpinger 10740 - [meta sequenceId="3"] ALERT: WAN1_PPPOE (Addr: 8.8.8.8 Alarm: loss -> down RTT: 17.9 ms RTTd: 0.2 ms Loss: 33.0 %)
<165>1 2026-09-29T17:18:30+02:00 hwk-gw01.c.cibex.net dpinger 10740 - [meta sequenceId="4"] ALERT: WAN2GW (Addr: 1.1.1.1 Alarm: loss -> down RTT: 22.1 ms RTTd: 0.4 ms Loss: 33.0 %)


2) In system.log error messages regarding PPPoE started to show:

<29>1 2026-09-29T17:18:34+02:00 hwk-gw01.c.cibex.net ppp 35846 - [meta sequenceId="17"] [opt15_link0] LCP: no reply to 1 echo request(s)
[...]
<29>1 2026-09-29T17:19:04+02:00 hwk-gw01.c.cibex.net ppp 35846 - [meta sequenceId="20"] [opt15_link0] LCP: no reply to 4 echo request(s)
<29>1 2026-09-29T17:19:14+02:00 hwk-gw01.c.cibex.net ppp 35846 - [meta sequenceId="21"] [opt15_link0] LCP: no reply to 5 echo request(s)
<29>1 2026-09-29T17:19:14+02:00 hwk-gw01.c.cibex.net ppp 35846 - [meta sequenceId="22"] [opt15_link0] LCP: peer not respond ing to echo requests
<29>1 2026-09-29T17:19:14+02:00 hwk-gw01.c.cibex.net ppp 35846 - [meta sequenceId="23"] [opt15_link0] LCP: state change Opened --> Stopping


3) And now starts the part that is baffling me: a few seconds later, system.log reported that the LAN interface was detatched, and shut down both interfaces:

<13>1 2026-09-29T17:19:29+02:00 hwk-gw01.c.cibex.net opnsense 80063 - [meta sequenceId="57"] /usr/local/etc/rc.linkup: DEVD: Ethernet detached event for opt2(lagg0)
<13>1 2026-09-29T17:19:30+02:00 hwk-gw01.c.cibex.net kernel - - [meta sequenceId="58"] [3363137] ixl1: Interface stopped DISTRIBUTING, possible flapping
<13>1 2026-09-29T17:19:30+02:00 hwk-gw01.c.cibex.net kernel - - [meta sequenceId="59"] [3363137] ixl0: Interface stopped DISTRIBUTING, possible flapping
<13>1 2026-09-29T17:19:30+02:00 hwk-gw01.c.cibex.net kernel - - [meta sequenceId="60"] <6>[3363137] lagg0: link state changed to DOWN


-


Some time later the firewall was physically reset, and started working without problems again.

What kind of problem can cause a shutdown of *all* available interfaces in the matter of less than a minute? I checked CPU temp, RAM usage, state table, nothing out of the ordinary there. If anyone has an explanation or could tell me how to further debug this issue any input would be very welcome.

Thanks
Urban

Hi,

I am currently setting up 2 new DEC3852 routers in a HA configuration. While everything is working perfectly so far, I noticed that the values displayed under Reporting - Traffic are not correct for the 10G LAN interface (ax0, using the axp driver I think), they show next to none traffic. The values are correct on the 1G WAN interface though.

You see an example on the attached screenshot. This is an iperf-Test through both interfaces, with the shaper active limiting the bandwidth to 10Mbps (this is just for testing, I see the same problem without shaping).

The WAN interface (purple) shows the correct bandwidth, then LAN interface (red, called "TRANSFER") does not show a significant amount of traffic.

OPNsense version is the most recent one (25.1.6_4).

Any ideas?

Thanks in advance!

I apologize for the long delay, we could not test this again on this particular firewall. Today I am having the same problem with an identical setup - unfortunately we have to ship this firewall this evening, so I am unable to debug this further. With the current shortage of firewall hardware we are not able to set up a more permanent test environment for the time being.

Anyway, I tried to gather some more information.

The DHCP request is received on the LAN interface:

# tcpdump -ni igb0 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:03:53.391100 IP 10.0.192.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 316

It is then sent on over the VPN tunnel to the DHCP-server by the relay agent, and is answered correctly:

# tcpdump -ni ovpnc2 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
14:03:53.391159 IP 10.0.192.1.67 > 10.8.0.64.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 324
14:03:53.415025 IP 10.8.0.64.67 > 10.0.192.1.67: BOOTP/DHCP, Reply, length 320

If I check the answer packet with wireshark, I see only correct information there (ip, dns-servers, gateway, as configured on the DHCP server).

But this answer is then never forwarded back to the requesting client by the relay agent.

I do not see any blocked packets, and can´t seem to find a relevant log. Also, the dhcprelay-binary does not seem to offer more verbose logging or a debug mode.

Our current workaround is to use DHCP directly on the opnsense, but this is not a permanent solution. Any ideas would be welcome.

Thanks
Urban

Well, I might be barking up the wrong tree here.

After my clients did not get the DHCP offer (even if the DHCP server did send it), I thought the reason might be that I cannot select the ovpn-interface in the GUI for dhcp-relay, so the relay agent dismisses the offer.

Also, if I manually start

/usr/local/sbin/dhcrelay -i igb0 -i ovpnc1 10.248.0.64

.. i get:

Unsupported device type 23 for "ovpnc1"

After having re-read the dhcrelay-manpage, it seems like I only need to specify the interfaces where the agent listens to DHCP broadcasts, not (additionally) the interface where the answer is received. It makes perfectly sense that the tun-interface from OpenVPN is not able to receive a broadcast.

So my problem does not seem to be the dhcp-relay configuration, sorry for the confusion. My problem seems to be that the dhcp offer received on the tun-interface never reaches the client. I do not think the problem is with firewall rules, as I did not see any relevant blocked packets.

As it´s not possible to test this in the live network anymore, I will try to set up a test environment and will report back here. If you have a possible explanation for this behaviour, any ideas are welcome.

Thanks

Correct my if I am wrong, but that´s what the dhcp relay agent is for, isn´t it? It´s located in the LAN, receives the broadcast, and relays it to the DHCP server (which is located in a different network).

That´s exactly how it worked with the old linux based router (iptables + OpenVPN + dnsmasq as relay agent - NOT as dhcp server). The VPN tunnel was routed via a tun interface as well.

Thanks
Urban

Hi,

we have a problem with DHCP-Relay over a OpenVPN-Tunnel.

We have a number of branch offices, which are connected to their (Windows-)Servers by OpenVPN-Tunnels. The clients in the branch offices are a mixture of laptops and thin clients. Until recently, a linux based firewall / vpn gateway did the site2site-vpn, filtering, and dhcp-relay to the domain controller using dnsmasq without problems.

We tried to migrate one branch office to OPNsense, and now have problems getting dhcp-relay to work. The dhcp-relay receives the DHCP request from the client, and forwards it correctly over the VPN tunnel to the domain controller. The reply (DHCP offer) is sucessfully sent back over the VPN tunnel (I see it with tcpdump), but then seems to get dropped. I do not see any blocked packets.

After researching I think I understand that dhcp-relay does not work on tun-adapters (which we have to use, we can´t use tap bridging in this case). So I guess I am out of luck using OPNsense´s dhcp-relay agent.

I tried to manually start dhcp-relay, and add the ovpn-Interface, but this leads to an "unspported interface"-error.

Does anyone see a potential workaround? I thought about enabling dnsmasq instead of unbound; but the dhcp-relay functionality is not exposed in the GUI. I am not sure if manually editing dnsmasq.conf is a good idea or could even work.

If we can´t make this work, we either have to swap the OPNsense with our linux router again, or run a dedicated linux box only for dnsmasq for dhcp relay.

Thanks in advance
Urban