"Recent posts
#81
German - Deutsch / Re: IPv6 am PON-Anschluss von ...
Last post by meyergru - January 21, 2026, 05:33:29 PMAus Deinen Angaben wird immer noch nicht klar, was Du eigentlich erhältst:
IA_NA?
IA_PD? Wenn ja, mit welcher Präfix-Länge? /56, /64 oder gar nicht?
Beachte auch, dass manche Provider nur Präfixe aushändigen, wenn man "Request prefix only" anhakt, siehe: https://forum.opnsense.org/index.php?topic=45822.0
Am Rande bemerkt, müsste der Provider und nicht die RegTP die Anschlussdaten bereitstellen. Offenbar ist der ISP aber so rigoros, dass er auch nicht sagt, wie man beispielsweise mit einer Fiber-Fritzbox oder sonstigem eigenen ONT arbeiten kann - und dass muss er, weil Endgerätefreiheit != Routerfreiheit. Wenn Du also aus dem Vertrag raus willst...
IA_NA?
IA_PD? Wenn ja, mit welcher Präfix-Länge? /56, /64 oder gar nicht?
Beachte auch, dass manche Provider nur Präfixe aushändigen, wenn man "Request prefix only" anhakt, siehe: https://forum.opnsense.org/index.php?topic=45822.0
Am Rande bemerkt, müsste der Provider und nicht die RegTP die Anschlussdaten bereitstellen. Offenbar ist der ISP aber so rigoros, dass er auch nicht sagt, wie man beispielsweise mit einer Fiber-Fritzbox oder sonstigem eigenen ONT arbeiten kann - und dass muss er, weil Endgerätefreiheit != Routerfreiheit. Wenn Du also aus dem Vertrag raus willst...
#82
Hardware and Performance / Re: (Solved) Internet speeds r...
Last post by manki_09 - January 21, 2026, 05:32:34 PMI don't think it's an issue per say with shaping, but the fact that the switch didn't actually apply flow control when the interface was enabled.
Then changing some settings in shaping (enabling and disabling) seemed to have forced flow control to enable even though it should have been already.
Then changing some settings in shaping (enabling and disabling) seemed to have forced flow control to enable even though it should have been already.
#83
25.7, 25.10 Series / Re: Intel Thermal Sensor Virtu...
Last post by WhatAMess - January 21, 2026, 05:31:30 PMYep I am using the one in the list Intel Core CPU on die, looks like my only choice. It works on my other build but not this one. Of course this is a different board, so the driver may be useless.--Thanks
#84
25.7, 25.10 Series / Re: NAT breaks Windows update
Last post by TheAutomationGuy - January 21, 2026, 05:27:59 PMNot sure if you are still experiencing a problem, but you'll have to do better at explaining your situation.
EVERY device using an IPv4 address behind a firewall/router is NATTED. The major function of a router is to handle NAT. If you are having problems with devices behind your firewall/router communicating with "the internet", it is due to a configuration issue. Hopefully we can help solve it, but you'll need to give us a lot more information before anyone can start to guess what the problem might be.
EVERY device using an IPv4 address behind a firewall/router is NATTED. The major function of a router is to handle NAT. If you are having problems with devices behind your firewall/router communicating with "the internet", it is due to a configuration issue. Hopefully we can help solve it, but you'll need to give us a lot more information before anyone can start to guess what the problem might be.
#85
Virtual private networks / OpenVPN instance setup and Lin...
Last post by Maduck - January 21, 2026, 05:23:26 PMHello,
I've been chatting with GPT, crawled through sites and tried to get Linux OpenVPN connection to work on Fedora 43, Linux Mint, Ubuntu but no luck. I just switched from W -> Linux and brought my .ovpn files. Issue is that every .ovpn profile imported from OpnSense OpenVPN instance style setup does not connect, but legacy client server style profiles connect nice and fast. Sorry if this question is too obvious, but what should I do: roll back updated OpnSense firewalls to legacy OpenVPN client/server setting or is there something I don't get?
Thank you in advance!
Br Maduck
I've been chatting with GPT, crawled through sites and tried to get Linux OpenVPN connection to work on Fedora 43, Linux Mint, Ubuntu but no luck. I just switched from W -> Linux and brought my .ovpn files. Issue is that every .ovpn profile imported from OpnSense OpenVPN instance style setup does not connect, but legacy client server style profiles connect nice and fast. Sorry if this question is too obvious, but what should I do: roll back updated OpnSense firewalls to legacy OpenVPN client/server setting or is there something I don't get?
Thank you in advance!
Br Maduck
#86
25.7, 25.10 Series / Re: IPv6 link-local route does...
Last post by Maurice - January 21, 2026, 05:00:30 PMNothing wrong with your configuration, it's most likely a bug. I've seen this behaviour before under hard to reproduce circumstances - some static IPv6 routes sometimes don't get added to the routing table after a reboot. Haven't been able to pinpoint it and mostly worked around it with Monit.
If it's reproducible in your setup, creating an issue on GitHub with as many details as possible (logs) might be the best way forward.
Cheers
Maurice
If it's reproducible in your setup, creating an issue on GitHub with as many details as possible (logs) might be the best way forward.
Cheers
Maurice
#87
German - Deutsch / Re: Bridge mit VXLAN verschluc...
Last post by Patrick M. Hausen - January 21, 2026, 04:44:35 PMHast du die Tunables für die Bridge gesetzt, die die Filterfunktion vom Member-Interface auf das Bridge-Interface verschieben?
#88
25.7, 25.10 Series / IPv6 link-local route does not...
Last post by matt335672 - January 21, 2026, 04:42:40 PMHi,
I've got a couple of OpnSense routers running 25.7.11_2 linked together.
My primary router receives a static /48 from my ISP, and then delegates a /60 to the secondary router. This is all done with static routing rather than PD, as Kea can't currently add the route for a delegated prefix automatically - see https://forum.opnsense.org/index.php?topic=48680
The interface vtnet3 on the main router has an address of FE80::1/64 and the interface em0 on the secondary router has an address of FE80::2/64.
On the main router, I've got a gateway and a static route configured to reach the secondary router as follows (links to postimg.cc):
The secondary router just has FE80::1 on the main router set as a default gateway.
There's also an IPv4 config set up in similar way.
This all works fine until I reboot the main router. When it comes up, the route for <prefix48>fff0::/60 to FE80::2%vtnet3 is missing from the routing table until I click the 'Apply' button on the routing config screen on the main router.
IPv4 works perfectly, although this is not using link-local addresses.
Any idea what I'm doing wrong here?
I've got a couple of OpnSense routers running 25.7.11_2 linked together.
My primary router receives a static /48 from my ISP, and then delegates a /60 to the secondary router. This is all done with static routing rather than PD, as Kea can't currently add the route for a delegated prefix automatically - see https://forum.opnsense.org/index.php?topic=48680
The interface vtnet3 on the main router has an address of FE80::1/64 and the interface em0 on the secondary router has an address of FE80::2/64.
On the main router, I've got a gateway and a static route configured to reach the secondary router as follows (links to postimg.cc):
The secondary router just has FE80::1 on the main router set as a default gateway.
There's also an IPv4 config set up in similar way.
This all works fine until I reboot the main router. When it comes up, the route for <prefix48>fff0::/60 to FE80::2%vtnet3 is missing from the routing table until I click the 'Apply' button on the routing config screen on the main router.
IPv4 works perfectly, although this is not using link-local addresses.
Any idea what I'm doing wrong here?
#89
German - Deutsch / Bridge mit VXLAN verschluckt A...
Last post by EFS - January 21, 2026, 04:40:53 PMHallo zusammen,
ich bin auf ein Problem gestoßen, bei dem ich mir nicht sicher bin, ob es sich um ein Konfigurationsproblem oder einen Bug in der Software handelt. Ziel ist es, mehrere Proxmox-Knoten über VXLANs an eine OPNsense anzubinden. Die Proxmox-Knoten bilden ein HA-Cluster.
Auf Basis verschiedener Anleitungen, unter anderem aus diesem Forum, konnte ich das Setup aufbauen. In der OPNsense habe ich eine Bridge erstellt, der ich die VXLAN-Interfaces zugeordnet habe. Jedes VXLAN-Interface bildet ein VXLAN-Device ab und kommuniziert jeweils mit einem Proxmox-Knoten. Die Kommunikation läuft: Ich kann von allen Knoten über die OPNsense ins Internet und ins VPN.
Jetzt zu meinem Problem:
Im Betrieb ist mir aufgefallen, dass manche VMs immer wieder sporadisch nicht erreichbar sind. Nach längerer Analyse konnte ich feststellen, dass die ARP-Tabelle in der OPNsense die entsprechenden IP-Adressen regelmäßig wieder verliert. Dadurch ist ein Zugriff nicht möglich. Weiterhin konnte ich feststellen, dass sobald ich von einer der betroffenen VMs eine Verbindung zur OPNsense aufbaue, z. B. durch einen Ping, die ARP-Tabelle die IP-Adresse der VM auflistet. Das erklärt, warum es manchmal funktioniert und manchmal nicht.
Bei weiterer Analyse mittels Packet Capture auf der Bridge und den VXLAN-Interfaces sehe ich, dass eine ARP-Anfrage als Broadcast gesendet wird, jedoch nur in der Bridge und einem der VXLAN-Interfaces. Das bedeutet, dass nur einer der Proxmox-Knoten die ARP-Anfrage erhält, was erklärt, warum die ARP-Tabelle die IP-Adressen der anderen Knoten nicht kennt.
Ich habe außerdem festgestellt, dass wenn ich z. B. ein VLAN-Interface der Bridge hinzufüge, den ARP-Broadcast erhält. Es scheint also am VXLAN-Interface zu liegen. Auffällig ist, dass immer das erste VXLAN-Interface in der Bridge den Broadcast erhält, das zweite, dritte usw. jedoch nicht. Tausche ich die Reihenfolge, indem ich die Interfaces beim VXLAN-Device vertauscht anlege, wandert der Fehler nicht mit.
Unterm Strich würde ich also sagen, dass die Bridge ein Problem damit hat, mit mehr als einem VXLAN-Interface umzugehen.
Ich hoffe, man konnte mir folgen. Hat jemand dieses Problem schon einmal gehabt und kann es bestätigen? Oder hat jemand eine Idee, wie ich das Problem lösen kann?
Vielen Dank im Voraus für jede Antwort.
Viele Grüße
Niklas
Version: 25.10.1_2
Lizenz: Business
ich bin auf ein Problem gestoßen, bei dem ich mir nicht sicher bin, ob es sich um ein Konfigurationsproblem oder einen Bug in der Software handelt. Ziel ist es, mehrere Proxmox-Knoten über VXLANs an eine OPNsense anzubinden. Die Proxmox-Knoten bilden ein HA-Cluster.
Auf Basis verschiedener Anleitungen, unter anderem aus diesem Forum, konnte ich das Setup aufbauen. In der OPNsense habe ich eine Bridge erstellt, der ich die VXLAN-Interfaces zugeordnet habe. Jedes VXLAN-Interface bildet ein VXLAN-Device ab und kommuniziert jeweils mit einem Proxmox-Knoten. Die Kommunikation läuft: Ich kann von allen Knoten über die OPNsense ins Internet und ins VPN.
Jetzt zu meinem Problem:
Im Betrieb ist mir aufgefallen, dass manche VMs immer wieder sporadisch nicht erreichbar sind. Nach längerer Analyse konnte ich feststellen, dass die ARP-Tabelle in der OPNsense die entsprechenden IP-Adressen regelmäßig wieder verliert. Dadurch ist ein Zugriff nicht möglich. Weiterhin konnte ich feststellen, dass sobald ich von einer der betroffenen VMs eine Verbindung zur OPNsense aufbaue, z. B. durch einen Ping, die ARP-Tabelle die IP-Adresse der VM auflistet. Das erklärt, warum es manchmal funktioniert und manchmal nicht.
Bei weiterer Analyse mittels Packet Capture auf der Bridge und den VXLAN-Interfaces sehe ich, dass eine ARP-Anfrage als Broadcast gesendet wird, jedoch nur in der Bridge und einem der VXLAN-Interfaces. Das bedeutet, dass nur einer der Proxmox-Knoten die ARP-Anfrage erhält, was erklärt, warum die ARP-Tabelle die IP-Adressen der anderen Knoten nicht kennt.
Ich habe außerdem festgestellt, dass wenn ich z. B. ein VLAN-Interface der Bridge hinzufüge, den ARP-Broadcast erhält. Es scheint also am VXLAN-Interface zu liegen. Auffällig ist, dass immer das erste VXLAN-Interface in der Bridge den Broadcast erhält, das zweite, dritte usw. jedoch nicht. Tausche ich die Reihenfolge, indem ich die Interfaces beim VXLAN-Device vertauscht anlege, wandert der Fehler nicht mit.
Unterm Strich würde ich also sagen, dass die Bridge ein Problem damit hat, mit mehr als einem VXLAN-Interface umzugehen.
Ich hoffe, man konnte mir folgen. Hat jemand dieses Problem schon einmal gehabt und kann es bestätigen? Oder hat jemand eine Idee, wie ich das Problem lösen kann?
Vielen Dank im Voraus für jede Antwort.
Viele Grüße
Niklas
Version: 25.10.1_2
Lizenz: Business
#90
25.7, 25.10 Series / Re: vtnet offloading since 25....
Last post by franco - January 21, 2026, 04:31:26 PMYes there might be 1-2 missing that I picked up while creating stable/26.1... that was about 150 extra commits from stable/14 that we haven't picked up for 25.7.x for stability reasons.
Cheers,
Franco
Cheers,
Franco
