"Recent posts
#91
Virtual private networks / Re: Multiple VLANs on site-to-...
Last post by viragomann - December 21, 2025, 06:36:56 PMWhat are you trying to achieve exactly?
What you are doing here would move remote access from VLAN900 to VLAN1000. You cannot have bidirectional access to both subnets.
If you only need access to the remote site, but not the remote to your site, it should be possible to nat the VLAN1000 to a single unused IP within the 192.168.246.0/24. But to achieve this, you have to use NAT type "NAT" and state the NAT IP with a /32 mask.
What you are doing here would move remote access from VLAN900 to VLAN1000. You cannot have bidirectional access to both subnets.
If you only need access to the remote site, but not the remote to your site, it should be possible to nat the VLAN1000 to a single unused IP within the 192.168.246.0/24. But to achieve this, you have to use NAT type "NAT" and state the NAT IP with a /32 mask.
#92
General Discussion / [SOLVED] Intermittent traffic ...
Last post by issuing_scone - December 21, 2025, 06:19:50 PMHello,
My network currently has the following requirements:
* All specified devices must always be connected to the internal network.
* All specified devices must always exit the network via the company-provided VPN service.
* All specified devices must kill-switch, so if the company-provided VPN drops, all devices must too.
In isolation, without all three being active at once, the current setup in OPNsense works.
I have followed the kill switch guide that is available here: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html, and set up the local tag NO_WAN_EGRESS for LAN and with a match for the Floating Rule.
However, when I create that blocking rule, the WireGuard always-on devices drop access to the external network and solely function internally.
I can see in Live View that, indeed, it is blocking traffic, but despite several configurations including a literal any / any, the traffic is still blocked by the default deny rule state violation rule. Further, it is intermittent, so that devices will occasionally connect to external websites, or a ping will execute 5 times correctly, before then dropping and dying and being blocked again.
I cannot for the life of me figure out what causes the intermittent drop where it will work 40% of the time and not the rest. I also cannot figure out why the NO_WAN_EGRESS rules interfere with the WireGuard clients.
I've attached all the images I had space to attach because 256KB is the limit. Do note that all firewall rules for WG have the NO_WAN_EGRESS tag. Further, the WAN interface has no rules.
WireGuard_Devices contains two test devices that have WireGuard installed and are connected to the firewall. Their IP addresses are 10.5.0.1 and 10.4.0.1.
My network currently has the following requirements:
* All specified devices must always be connected to the internal network.
* All specified devices must always exit the network via the company-provided VPN service.
* All specified devices must kill-switch, so if the company-provided VPN drops, all devices must too.
In isolation, without all three being active at once, the current setup in OPNsense works.
I have followed the kill switch guide that is available here: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html, and set up the local tag NO_WAN_EGRESS for LAN and with a match for the Floating Rule.
However, when I create that blocking rule, the WireGuard always-on devices drop access to the external network and solely function internally.
I can see in Live View that, indeed, it is blocking traffic, but despite several configurations including a literal any / any, the traffic is still blocked by the default deny rule state violation rule. Further, it is intermittent, so that devices will occasionally connect to external websites, or a ping will execute 5 times correctly, before then dropping and dying and being blocked again.
I cannot for the life of me figure out what causes the intermittent drop where it will work 40% of the time and not the rest. I also cannot figure out why the NO_WAN_EGRESS rules interfere with the WireGuard clients.
I've attached all the images I had space to attach because 256KB is the limit. Do note that all firewall rules for WG have the NO_WAN_EGRESS tag. Further, the WAN interface has no rules.
WireGuard_Devices contains two test devices that have WireGuard installed and are connected to the firewall. Their IP addresses are 10.5.0.1 and 10.4.0.1.
#93
German - Deutsch / Re: Probleme mit IPTV / WIFI T...
Last post by fastboot - December 21, 2025, 05:47:16 PMAus meiner Sicht ist der Beitrag von Zapad fachlich unhaltbar und konzeptionell gefährlich, weil er grundlegende Prinzipien von OPNsense und zustandsbehafteten Firewalls ignoriert und durch pauschale Empfehlungen ersetzt, die weder sauber hergeleitet noch technisch begründet sind.
Die Empfehlung, auf allen VLANs zunächst pauschal pass any any zu setzen, ist kein sinnvoller Startpunkt, sondern ein vollständiges Abschalten der Policy-Ebene und damit genau das Gegenteil von strukturierter Fehlersuche.
Wer so vorgeht, zerstört jede Aussagekraft der Logs, verwischt Asymmetrien im Routing, maskiert Multicast-Fehlkonzepte und kann am Ende nicht mehr beurteilen, warum etwas funktioniert oder eben nicht.
Das Argument "damit sollte Streaming und Telefonie laufen" ist sachlich falsch, weil WLAN-Qualität, Airtime, Multicast-Flooding, IGMP-Handling der Switches und Accesspoints sowie Client-Roaming dadurch in keiner Weise adressiert werden.
Besonders problematisch ist, dass gleichzeitig Multicast- und Broadcast-Relays relativiert werden, obwohl gerade diese in Kombination mit offenen Regeln massiv zu unnötigem Traffic und instabilem WLAN führen können!
Auch der Umgang mit "Default Deny Meldungen" und DF-Flags wirkt deplatziert und zeugt nicht von systematischem Verständnis, sondern von nachträglicher Rechtfertigung unsauberer Konfigurationen.
Das hier sollte kein Trial-and-Error-Spiel sein, bei dem man erst alles öffnet und dann "langsam zuschraubt"
@Zapad
Kurz gesagt: Dein Beitrag liefert keine belastbare technische Hilfe, sondern propagiert ein Vorgehen, das Sicherheitskonzept, Fehlersuche und sauberes Design gleichermaßen untergräbt.
Die Empfehlung, auf allen VLANs zunächst pauschal pass any any zu setzen, ist kein sinnvoller Startpunkt, sondern ein vollständiges Abschalten der Policy-Ebene und damit genau das Gegenteil von strukturierter Fehlersuche.
Wer so vorgeht, zerstört jede Aussagekraft der Logs, verwischt Asymmetrien im Routing, maskiert Multicast-Fehlkonzepte und kann am Ende nicht mehr beurteilen, warum etwas funktioniert oder eben nicht.
Das Argument "damit sollte Streaming und Telefonie laufen" ist sachlich falsch, weil WLAN-Qualität, Airtime, Multicast-Flooding, IGMP-Handling der Switches und Accesspoints sowie Client-Roaming dadurch in keiner Weise adressiert werden.
Besonders problematisch ist, dass gleichzeitig Multicast- und Broadcast-Relays relativiert werden, obwohl gerade diese in Kombination mit offenen Regeln massiv zu unnötigem Traffic und instabilem WLAN führen können!
Auch der Umgang mit "Default Deny Meldungen" und DF-Flags wirkt deplatziert und zeugt nicht von systematischem Verständnis, sondern von nachträglicher Rechtfertigung unsauberer Konfigurationen.
Das hier sollte kein Trial-and-Error-Spiel sein, bei dem man erst alles öffnet und dann "langsam zuschraubt"
@Zapad
Kurz gesagt: Dein Beitrag liefert keine belastbare technische Hilfe, sondern propagiert ein Vorgehen, das Sicherheitskonzept, Fehlersuche und sauberes Design gleichermaßen untergräbt.
#94
25.7, 25.10 Series / IGMP Fail after reboot
Last post by furfix - December 21, 2025, 05:23:59 PMHi Franco and Team!
OPNsense 25.7.10, baremetal. IGMP is not starting after reboot.
Is it possible during boot igmpproxy try to starts before the WAN/LAN interfaces are fully up?
2025-12-21T17:11:23 Error igmpproxy Sender VIF was down.; Errno(50): Network is down
2025-12-21T17:11:23 Warning igmpproxy select() failure; Errno(4): Interrupted system call
Never had this problem before. Now, when it happens, I need to login and start the service manually.
Thanks!
f/
OPNsense 25.7.10, baremetal. IGMP is not starting after reboot.
Is it possible during boot igmpproxy try to starts before the WAN/LAN interfaces are fully up?
2025-12-21T17:11:23 Error igmpproxy Sender VIF was down.; Errno(50): Network is down
2025-12-21T17:11:23 Warning igmpproxy select() failure; Errno(4): Interrupted system call
Never had this problem before. Now, when it happens, I need to login and start the service manually.
Thanks!
f/
#95
General Discussion / ECS and DNSSEC Setup
Last post by spetrillo - December 21, 2025, 05:21:41 PMHello all,
I am using Quad9's Secured w/ECS: Malware blocking, DNSSEC Validation, ECS enabled DNS service. How do I configure Unbound to handle this? Do I need to worry about dnsmasq DNS services also?
Thanks,
Steve
I am using Quad9's Secured w/ECS: Malware blocking, DNSSEC Validation, ECS enabled DNS service. How do I configure Unbound to handle this? Do I need to worry about dnsmasq DNS services also?
Thanks,
Steve
#96
General Discussion / Re: Web Interface Not Secure
Last post by t84a - December 21, 2025, 04:10:10 PMSorry. Google Chrome.
#97
German - Deutsch / Re: IPv6 am PON-Anschluss von ...
Last post by mbr89 - December 21, 2025, 03:46:31 PMGuten Tag Herr R.
in Rücksprache mit den Kollegen habe ich die Information erhalten,
dass Sie sich bitte direkt an Ihren Anbieter wenden müssen, wir können hier leider nicht helfen.
Herzliche Grüße
R. W.
Assistenz Front-/ Backoffice
vitroconnect GmbH
Hülsbrockstr. 23
33334 Gütersloh
Sooooo, Beschwerde bei der BNetzA ist raus. Auch wenn es sinnlos ist. Und ja ich lege es auf einen "Rausschmiss" an.
Den VDSL-Anschluss mit 35 MBit/s bzw. 5 MBit/s bei NetCom BW habe ich noch nicht gekündigt - hat zwar kein IPv6 aber immerhin eine feste öffentliche IPv4.
-> Deswegen wird das auch nichts mehr mit Zääääää Länd ... warten wir also entspannt die Prophezeiungen aus der Offenbarung ab:
"Und es werden Zeichen sein an Sonne und Mond und Sternen und auf der Erde Angst der Nationen in Ratlosigkeit bei brausendem und wogendem Meer,
während die Menschen verschmachten vor Furcht und Erwartung der Dinge, die über den Erdkreis kommen, denn die Kräfte der Himmel werden erschüttert werden."
Bisdahin, hat jemand einen Job im Ausland für mich ? Ungarn soll ganz schön sein ...
in Rücksprache mit den Kollegen habe ich die Information erhalten,
dass Sie sich bitte direkt an Ihren Anbieter wenden müssen, wir können hier leider nicht helfen.
Herzliche Grüße
R. W.
Assistenz Front-/ Backoffice
vitroconnect GmbH
Hülsbrockstr. 23
33334 Gütersloh
Sooooo, Beschwerde bei der BNetzA ist raus. Auch wenn es sinnlos ist. Und ja ich lege es auf einen "Rausschmiss" an.
Den VDSL-Anschluss mit 35 MBit/s bzw. 5 MBit/s bei NetCom BW habe ich noch nicht gekündigt - hat zwar kein IPv6 aber immerhin eine feste öffentliche IPv4.
-> Deswegen wird das auch nichts mehr mit Zääääää Länd ... warten wir also entspannt die Prophezeiungen aus der Offenbarung ab:
"Und es werden Zeichen sein an Sonne und Mond und Sternen und auf der Erde Angst der Nationen in Ratlosigkeit bei brausendem und wogendem Meer,
während die Menschen verschmachten vor Furcht und Erwartung der Dinge, die über den Erdkreis kommen, denn die Kräfte der Himmel werden erschüttert werden."
Bisdahin, hat jemand einen Job im Ausland für mich ? Ungarn soll ganz schön sein ...
#98
General Discussion / Re: Opnsense vs mainstream rou...
Last post by Bob.Dig - December 21, 2025, 03:31:07 PMQuote from: Hollywood on December 21, 2025, 06:20:05 AMto be a workable modem for my needsAnd learn what a Modem is. ;)
#99
24.7, 24.10 Legacy Series / Re: KEA not respecting reserva...
Last post by Dileep - December 21, 2025, 02:24:08 PMHi All,
This issue remains unresolved for me, even after setting match-client-id to false.
System Details:
OPNsense Version: 25.7-amd64
FreeBSD: 14.3-RELEASE-p1
OpenSSL: 3.0.17
Observed Behavior:
On 19th Dec 2025, I created a DHCP reservation for the following:
Subnet: 172.26.80.0/20
Reserved IP: 172.26.84.178
MAC: 7c:0a:3f:xx:xx:xx
On the same day, I removed the device from the network and reconnected it after approximately 3 hours (maximum lease time is 2 hours). The device correctly received the reserved IP address as expected.
However, I powered off the device and reconnected it again on 21st Dec 2025, and this time it was assigned a different IP address (172.26.85.54) instead of the reserved one.
Below are the logs comparing the DHCP logs from 19th Dec and 21st Dec for reference.
19th Dec:
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: trying to send packet DHCPACK (type 5) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_ALLOC [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: lease 172.26.84.178 has been allocated for 7200 seconds
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: trying to send packet DHCPOFFER (type 2) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_OFFER [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: lease 172.26.84.178 will be offered
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8
21st Dec:
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: trying to send packet DHCPOFFER (type 2) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_OFFER [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: lease 172.26.85.54 will be offered
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8
As suggested in earlier posts, we have already configured match-client-id = false, but the issue persists. Interestingly, this behavior is not consistent across all devices—only a random subset of devices is affected, and this occurs across different device brands.
If anyone has observed similar behavior or has insights into additional DHCP options or client-ID–related handling in OPNsense that might cause this, I would appreciate your input.
Thanks in advance.
This issue remains unresolved for me, even after setting match-client-id to false.
System Details:
OPNsense Version: 25.7-amd64
FreeBSD: 14.3-RELEASE-p1
OpenSSL: 3.0.17
Observed Behavior:
On 19th Dec 2025, I created a DHCP reservation for the following:
Subnet: 172.26.80.0/20
Reserved IP: 172.26.84.178
MAC: 7c:0a:3f:xx:xx:xx
On the same day, I removed the device from the network and reconnected it after approximately 3 hours (maximum lease time is 2 hours). The device correctly received the reserved IP address as expected.
However, I powered off the device and reconnected it again on 21st Dec 2025, and this time it was assigned a different IP address (172.26.85.54) instead of the reserved one.
Below are the logs comparing the DHCP logs from 19th Dec and 21st Dec for reference.
19th Dec:
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: trying to send packet DHCPACK (type 5) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_ALLOC [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: lease 172.26.84.178 has been allocated for 7200 seconds
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-19T16:27:59 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: trying to send packet DHCPOFFER (type 2) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_OFFER [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: lease 172.26.84.178 will be offered
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-19T16:27:58 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0xb51816e8
21st Dec:
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: DHCPREQUEST (type 3) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_SEND [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: trying to send packet DHCPOFFER (type 2) from 172.26.95.254:67 to 255.255.255.255:68 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.leases.0x19fdfb86b008] DHCP4_LEASE_OFFER [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: lease 172.26.85.54 will be offered
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.packets.0x19fdfb86b008] DHCP4_PACKET_RECEIVED [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface vlan0.420
2025-12-21T12:29:17 Informational kea-dhcp4 INFO [kea-dhcp4.dhcp4.0x19fdfb86b008] DHCP4_QUERY_LABEL received query: [hwtype=1 7c:0a:3f:x:x:x], cid=[01:7c:0a:3f:x:x:x], tid=0x80b52cd8
As suggested in earlier posts, we have already configured match-client-id = false, but the issue persists. Interestingly, this behavior is not consistent across all devices—only a random subset of devices is affected, and this occurs across different device brands.
If anyone has observed similar behavior or has insights into additional DHCP options or client-ID–related handling in OPNsense that might cause this, I would appreciate your input.
Thanks in advance.
#100
25.7, 25.10 Series / Re: [SOLVED]: IPv6 connectivit...
Last post by Patrick M. Hausen - December 21, 2025, 02:09:05 PM@ischilling please open a new thread about your problem which has nothing in common with the solved one the OP head. Apart from the fact that the word "IPv6" appears in both.
