"Recent posts
#1
26.7 Series / DS-LITE OPTION 64 - GIF TUNN...
Last post by ijobs - Today at 02:08:49 PMHi everyone,
I'll soon be getting my fiber-optic connection from Netcologne, which provides DS-Lite/CGNAT.
I can't find a clear answer in the forum as to whether the current version of DHCPv6 in OPNsense now detects the AFTR server and establishes a GIF tunnel for IPv4.
I look forward to hearing from users with this setup and learning how they created a working configuration.
Thanks in advance.
#2
Zenarmor (Sensei) / Re: Zenarmor Cloud Agent servi...
Last post by sy - Today at 02:02:58 PMHi,
Our team is currently investigating the issue and will provide an update shortly.
Our team is currently investigating the issue and will provide an update shortly.
#3
26.1, 26,4 Series / Re: Dynamic DNS ddclient confi...
Last post by Greelan - Today at 01:57:43 PMThe real issue is how the ddclient version that OPNsense bundles parses and filters per-provider options. That has been fixed in ddclient 4.0. Stripping the commas and backslashes "works" because ddclient then interprets the options as global and doesn't filter them, but if you had multiple providers configured this would potentially interfere with others.
The real solution is for 4.0 to be shipped with OPNsense (it is already in ports), with some changes in the plugin to accommodate it.
The real solution is for 4.0 to be shipped with OPNsense (it is already in ports), with some changes in the plugin to accommodate it.
#4
26.7 Series / OPNsense 26.7.4 - VLAN traffic...
Last post by merrins63 - Today at 01:38:52 PMHi all,
I'm troubleshooting a VLAN issue that appeared after upgrading to OPNsense 26.7.4 / FreeBSD 15.1.
My setup is roughly:
Cisco 2960X
|
Po3 LACP / 802.1Q
|
Intel X550 ix0 + ix1
|
lagg0
|
VLAN interfaces
|
OPNsense bridges
|
Kea DHCP
I also have an Intel i226 2.5 GbE trunk, with corresponding VLAN interfaces bridged to the X550/LAGG VLAN interfaces.
This affects all VLANs traversing the Cisco 2960X / Intel X550 LAGG path. VLAN 15 is simply the VLAN I am using for troubleshooting.
Clients on the Cisco side fail DHCP and remain on 169.254.x.x.
Cisco switch looks healthy: Po3 is UP, both LACP members are bundled, VLAN 15 is forwarding, and the test client MAC is correctly learned on its VLAN 15 access port.
The interesting part is simultaneous packet captures of the same DHCP transaction:
bridge1: DHCP REQUEST ✓ ACK ✓
vlan0.1.15: DHCP REQUEST ✓ ACK ✓
lagg0: DHCP not visible
ix0 / ix1: DHCP not visible
Kea therefore appears to receive the request and generate an ACK, but the client never receives/configures the lease.
I found FreeBSD bug 276936, describing packet-forwarding problems involving ixgbe, VLAN interfaces and bridges. The topology isn't identical, but it looks potentially relevant.
Has anyone experienced similar issues with OPNsense 26.7, Intel X550, LAGG/LACP, VLANs and bridges, or have suggestions for further diagnostics?
Any help or feedback would be greatly appreciated, as I am stuck until I can fix this, as my network relies on the VLAN Bridges to connect my home network
Thanks in advance
I'm troubleshooting a VLAN issue that appeared after upgrading to OPNsense 26.7.4 / FreeBSD 15.1.
My setup is roughly:
Cisco 2960X
|
Po3 LACP / 802.1Q
|
Intel X550 ix0 + ix1
|
lagg0
|
VLAN interfaces
|
OPNsense bridges
|
Kea DHCP
I also have an Intel i226 2.5 GbE trunk, with corresponding VLAN interfaces bridged to the X550/LAGG VLAN interfaces.
This affects all VLANs traversing the Cisco 2960X / Intel X550 LAGG path. VLAN 15 is simply the VLAN I am using for troubleshooting.
Clients on the Cisco side fail DHCP and remain on 169.254.x.x.
Cisco switch looks healthy: Po3 is UP, both LACP members are bundled, VLAN 15 is forwarding, and the test client MAC is correctly learned on its VLAN 15 access port.
The interesting part is simultaneous packet captures of the same DHCP transaction:
bridge1: DHCP REQUEST ✓ ACK ✓
vlan0.1.15: DHCP REQUEST ✓ ACK ✓
lagg0: DHCP not visible
ix0 / ix1: DHCP not visible
Kea therefore appears to receive the request and generate an ACK, but the client never receives/configures the lease.
I found FreeBSD bug 276936, describing packet-forwarding problems involving ixgbe, VLAN interfaces and bridges. The topology isn't identical, but it looks potentially relevant.
Has anyone experienced similar issues with OPNsense 26.7, Intel X550, LAGG/LACP, VLANs and bridges, or have suggestions for further diagnostics?
Any help or feedback would be greatly appreciated, as I am stuck until I can fix this, as my network relies on the VLAN Bridges to connect my home network
Thanks in advance
#5
German - Deutsch / DS-LITE OPTION 64 - GIF TUNNEL...
Last post by ijobs - Today at 01:29:18 PMHallo Leute,
ich bekomme bald meinen Glasfaser Anschluss von Netcologne.
Finde im Forum keine klare Antwort, ob die aktuelle Version von dhcpv6 mittlerweile den AFTR Server erkennt und einen GIF Tunnel für ipv4 aufbaut.
Freue mich auf Antwort von Usern mit diesem Setup und wie eine funktionierende Konfiguration angekegt wurde.
Danke schon mal.
ich bekomme bald meinen Glasfaser Anschluss von Netcologne.
Finde im Forum keine klare Antwort, ob die aktuelle Version von dhcpv6 mittlerweile den AFTR Server erkennt und einen GIF Tunnel für ipv4 aufbaut.
Freue mich auf Antwort von Usern mit diesem Setup und wie eine funktionierende Konfiguration angekegt wurde.
Danke schon mal.
#6
German - Deutsch / Re: PPPoE-Interface-Bug
Last post by Monviech (Cedrik) - Today at 11:25:32 AMAm einfachsten ist es auch hier die Point to Point session vor der OPNsense zu terminieren, wenn HA benötigt wird.
Vor allem rauchen dann auch keine Sessions ab wenn es schwenkt, da pfsync states auf echten interfaces liegen.
Das läuft bei mir seit Jahren stabil.
Point to point is halt grundsätzlich eher point to point und nicht point to multipoint... das bedeuted HA ist immer etwas feindlich in so Szenarios.
Vor allem rauchen dann auch keine Sessions ab wenn es schwenkt, da pfsync states auf echten interfaces liegen.
Das läuft bei mir seit Jahren stabil.
Point to point is halt grundsätzlich eher point to point und nicht point to multipoint... das bedeuted HA ist immer etwas feindlich in so Szenarios.
#7
German - Deutsch / Re: Kernelbug beim Einsatz von...
Last post by Monviech (Cedrik) - Today at 11:05:03 AMJa das ist schon sehr viele Jahre bekannt.
Was ich Kunden mit so einem Setup empfehle ist mehrere Router die alle die PPPoE session terminieren, und die OPNsense dahinter. Durch eindeutiges Routing hat dann die OPNsense unique default routen pro Leitung.
Doppel NAT kann man verhindern indem man statisches routing verwendet und bei der Haupt OPNsense das Source NAT/Destination NAT ausmacht.
Beispiel Transitnetze
(macht NAT) (Nur Router/Firewall)
PPPoE Router 1 --- 10.0.1.1/30 --- 10.0.1.2 OPNsense
PPPoE Router 2 --- 10.0.2.1/30 --- 10.0.2.2 OPNsense
Was ich Kunden mit so einem Setup empfehle ist mehrere Router die alle die PPPoE session terminieren, und die OPNsense dahinter. Durch eindeutiges Routing hat dann die OPNsense unique default routen pro Leitung.
Doppel NAT kann man verhindern indem man statisches routing verwendet und bei der Haupt OPNsense das Source NAT/Destination NAT ausmacht.
Beispiel Transitnetze
(macht NAT) (Nur Router/Firewall)
PPPoE Router 1 --- 10.0.1.1/30 --- 10.0.1.2 OPNsense
PPPoE Router 2 --- 10.0.2.1/30 --- 10.0.2.2 OPNsense
#8
German - Deutsch / Kernelbug beim Einsatz von zwe...
Last post by aeble - Today at 10:53:40 AMErfahrungsbericht beim Einsatz von zwei Point-to-Point-Sessions.
Auch hier: Ideen willkommen, aber hauptsächlich ein Erfahrungsbericht und Warnung für andere.
Setup:
OPNsense 26.7.4_1-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8
zwei Glas-Uplinks Telekom mit PPPoE, die auf demselben BNG terminieren.
Problem:
Wenn beide PPPoE-Sessions auf demselben BNG terminieren, haben sie dieselbe Uplink-IP. Der Kernel fügt dann die zweite Route *nicht* in die Routingtabelle ein ("ach guck, die Route hab ich ja schon!"), sondern verwirft die Pakete stumm.
Traffic, der auf der Firewall originiert, funktioniert.
Ein genauerer Aufschrieb ist unter Bug 298932 aufgeführt.
Das führt jedenfalls dazu, dass der Schwenk beim Ausfall der aktiven Leitung funktioniert (die andere Leitung übernimmt), aber der Schwenk zurück schlägt dann fehl, weil die Route in der Routingtabelle dann auf die Backup-Leitung zeigt.
Mögliche Lösungen:
Alles bißchen unschön, aber ich gebe zu, das beide Leitungen denselben Endpunkt haben ist auch nicht hübsch ;-)
Auch hier: Ideen willkommen, aber hauptsächlich ein Erfahrungsbericht und Warnung für andere.
Setup:
OPNsense 26.7.4_1-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8
zwei Glas-Uplinks Telekom mit PPPoE, die auf demselben BNG terminieren.
Problem:
Wenn beide PPPoE-Sessions auf demselben BNG terminieren, haben sie dieselbe Uplink-IP. Der Kernel fügt dann die zweite Route *nicht* in die Routingtabelle ein ("ach guck, die Route hab ich ja schon!"), sondern verwirft die Pakete stumm.
Traffic, der auf der Firewall originiert, funktioniert.
Ein genauerer Aufschrieb ist unter Bug 298932 aufgeführt.
Das führt jedenfalls dazu, dass der Schwenk beim Ausfall der aktiven Leitung funktioniert (die andere Leitung übernimmt), aber der Schwenk zurück schlägt dann fehl, weil die Route in der Routingtabelle dann auf die Backup-Leitung zeigt.
Mögliche Lösungen:
- eine Leitung auf ein anderes BNG ziehen lassen (schwierig bei den Supportkanälen)
- eine Leitung zu einem anderen Provider ziehen
- zwei FIBs (nicht supported unter OPNsense)
- zweite Leitung an ein anderes Gerät ziehen, das die Session hält.
Alles bißchen unschön, aber ich gebe zu, das beide Leitungen denselben Endpunkt haben ist auch nicht hübsch ;-)
#9
26.1, 26,4 Series / Clarification of functionality...
Last post by ClintonWestwood - Today at 10:48:58 AMHello, within Services: ACME Client: Certificates: ACME CA Settings there is an option "Renewal Interval". Is this how often the task runs, or is it how long after a certificat has been issued that it will be renewed.
For example, Is it that Setting: Cron will run the update procedure every day at midnight for example, but the rule in Renewal interval is what determines whether or not a certificate should be renewed? Therefore if my Renewal Interval is set to 60 days and my Let's Encrypt certificate is for 90 days, then my certificate will be renewed after 60 days since creation. In other words, if my certificate is 61 days old at the point of the job running, it will be renewed, but if it's 59 days old, no renewal will take place?
I am aware I've probably repeated myself a few times.
Thanks.
For example, Is it that Setting: Cron will run the update procedure every day at midnight for example, but the rule in Renewal interval is what determines whether or not a certificate should be renewed? Therefore if my Renewal Interval is set to 60 days and my Let's Encrypt certificate is for 90 days, then my certificate will be renewed after 60 days since creation. In other words, if my certificate is 61 days old at the point of the job running, it will be renewed, but if it's 59 days old, no renewal will take place?
I am aware I've probably repeated myself a few times.
Thanks.
#10
German - Deutsch / PPPoE-Interface-Bug
Last post by aeble - Today at 10:43:43 AMErfahrungsbericht Einsatz HA-OPNsense und Fehler beim Failover mit PPPoE-Sessions
Das ist kein Cry for Help, aber vielleicht hilft es ja jemandem, der sich in einer ähnlichen Situation befindet... Lösungsideen sind aber natürlich jederzeit willkommen.
Setup: zwei OPNsense in HA-Mode, zwei WAN-Interfaces mit Glasfaser-Uplinks (virtualisiert auf Proxmox, aber das spielt keine Rolle). Beide nic0 gehen über einen kleinen Switch zum ONT, beide nic1 über einen zweiten Switch zum zweiten ONT.
OPNsense 26.7.4_1-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8
nic0 trägt ein vlan0.7.1, auf dem wiederum das pppoe0 liegt und nic1 trägt ein vlan0.7.2, das pppoe1 trägt.
Problem: beide pppoe0 auf opnsense1 und opnsense2 haben ihre PPPoE-Interfaces always up. Der Status ist nicht an CARP gebunden, weil sie ja keine CARP-VIP haben. Das führt dazu, dass der Node, dessen PADI als erste an der Gegenstelle auftauchen, die Session erhält - das kann eben auch gut der Backup-Node sein, der dann zwar nicht aktiv ist, aber die PPPoE-Session hält. Der Master-Node ist dann "leitungslos".
Mögliche Lösung: auf den vlan0.7.x-Interfaces eine VARP-VIP konfigurieren, damit das Interface nur hoch kommt, wenn der Knoten schwenkt. Das führt zu einem Folgeproblem: es gibt Berichte, dass manche OLTs (insbesondere Telekom) nur zwei MAC-Adressen am ONT akzeptieren. Mit der CARP-VIP wären das dann aber schon drei. Mit den eingesetzten Switches (Mikrotik CSS106) kann ich die leider nicht filtern.
Es gibt einen Pull Request dafür, der ist aber noch ungelöst und ich bin mir nicht sicher, dass er hier konkret hilft.
Das ist kein Cry for Help, aber vielleicht hilft es ja jemandem, der sich in einer ähnlichen Situation befindet... Lösungsideen sind aber natürlich jederzeit willkommen.
Setup: zwei OPNsense in HA-Mode, zwei WAN-Interfaces mit Glasfaser-Uplinks (virtualisiert auf Proxmox, aber das spielt keine Rolle). Beide nic0 gehen über einen kleinen Switch zum ONT, beide nic1 über einen zweiten Switch zum zweiten ONT.
OPNsense 26.7.4_1-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8
nic0 trägt ein vlan0.7.1, auf dem wiederum das pppoe0 liegt und nic1 trägt ein vlan0.7.2, das pppoe1 trägt.
Problem: beide pppoe0 auf opnsense1 und opnsense2 haben ihre PPPoE-Interfaces always up. Der Status ist nicht an CARP gebunden, weil sie ja keine CARP-VIP haben. Das führt dazu, dass der Node, dessen PADI als erste an der Gegenstelle auftauchen, die Session erhält - das kann eben auch gut der Backup-Node sein, der dann zwar nicht aktiv ist, aber die PPPoE-Session hält. Der Master-Node ist dann "leitungslos".
Mögliche Lösung: auf den vlan0.7.x-Interfaces eine VARP-VIP konfigurieren, damit das Interface nur hoch kommt, wenn der Knoten schwenkt. Das führt zu einem Folgeproblem: es gibt Berichte, dass manche OLTs (insbesondere Telekom) nur zwei MAC-Adressen am ONT akzeptieren. Mit der CARP-VIP wären das dann aber schon drei. Mit den eingesetzten Switches (Mikrotik CSS106) kann ich die leider nicht filtern.
Es gibt einen Pull Request dafür, der ist aber noch ungelöst und ich bin mir nicht sicher, dass er hier konkret hilft.
