Messages

Ich habe fälschlicherweise "suffix" anstelle von "prefix" geschrieben und damit Leute verwirrt.

Wir haben das Problem dass wir kein Prefix bekommen wenn es die PPPoe Zwangstrennung gibt bzw. wenn wir diese per Cron steuern. Wir erhalten dann keine IPv6 Adresse und auch kein IPv6 Prefix, in der Overview sind die entsprechenden Felder dann leer.

Wenn wir auf den Knopf "reload" drücken wird bei unseren Setups innerhalb von Sekunden ein neues v6 Prefix zugewiesen, die LAN Interfaces bekommen dies per Tracking idr. mit und SLAAC erledigt den Rest. Lediglich ein paar Android Geräte stellen sich ein wenig an das neue v6 LAN Prefix anzunehmen. WLAN trennen und neu verbinden hilft dabei. Habe allerdings hier noch nicht ausprobiert ob die sich das neue Prefix irgendwann später holen, es ging uns bisher erst einmal darum sicherzustellen dass wir überhaupt ein Prefix erhalten wenn der PPPoe Reconnect durchgeführt wird.

Bei Neustarts gibt es bisher auch keine Probleme, da wird scheinbar ein DHCPv6 Client Requests via PPPoe v4 abgesetzt und zugewiesen.

Wir haben hier dynamsiche IPs, da die meisten Kunden bei den hier vorhandenen Glasfasertarifen keinen Business Tarif benötigen. 600 Down, 200 Up für 40 Euro im Monat mit FTTH langt in er Regel.

Upstream DNS haben wir meistens auf 1.1.1.1 oder 8.8.8.8 und entsprechend deren v6 IPs gesetzt. Alle Setups haben allerdings sowieso noch andere lokale DNS Server (nicht OPNsense) konfiguriert, von daher sind die DNS Einstellungen bei uns nur bedingt wichtig.

Wir beziehen zusätzlich zu dem Prefix auch noch eine IPv6 für den Router, damit der direkte Zugriff auf diesen auch per v6 möglich ist (VPN usw.).

Die GWs werden von OPNsense automatisch über den PPPoe Connect konfiguriert.

Wir haben keine Unterschiede wenn wir andere LAN Prefixe vergeben, die LANs bekommen per Tracking ihr /64 wenn das Prefix beim PPPoe gesetzt wird.

VLAN tagging benötigen wir bei uns nicht, darum kümmern sich die ONTs bei unseren Setups.

Helfen diese Infos dir weiter?

Ich habe mit OPNsense 22.7.10_2 das selbe Problem und wir sind auch nicht allein: https://github.com/opnsense/core/issues/6223#issue-comment-box

Habe einen längeren Post in das Github Issue geschrieben. Nerviges Thema und ich verstehe nicht warum für Jahre keine vernünftige Lösung für PPPoe Zwangstrennungen implementiert wird. Nahezu alle anderen Router haben dafür Funktionen eingebaut.
"PPPoe ist alt, wir bauen dazu nichts mehr bei OPNsense aus" funktioniert halt nicht wenn viele ISPs aber noch darauf aufbauen und dies selbst hinter ONTs für Fiber Anschlüsse noch verwenden. Das Ergibt kaum Sinn weil die ONTs eh alle mit deren MAC Adresse registriert und für den jeweiligen Kunden freigeschaltet werden müssen.

Hoffen wir mal dass sich hier etwas tut. Anbei der Beitrag (in Englisch) vom Issue:

Code Select Expand

We also have this problem with multiple setups. ONT --> PPPoe v4 and v6 suffix (/56) via DHCPv6--> OPNsense . We are also forced to reconnect once every 24h and receive a new IPv4 and v6 suffix.

To control when the reconnect should be triggered we setup a cron job to reset the PPPoe and WAN interface at 3 AM. IPv4 is no problem, but the IPv6 suffix is not requested by OPNsense during the interface reset.

Pressing the button "Reload" for DHCPv6 on the Interface Overview for PPPoe immediately requests a new /56 and v6 is working again.

The LAN interface tracking to receive a /64 out of the /56 suffix usually works fine if the PPPoe requests a new /56. Sometimes it also fails and either the interface has to be edited and saved of the FW has to be rebooted.

This leaves us with multiple problems:

    - complicated setup for pppoe forced reconnect control
    - DHCPv6 for pppoe not working properly
    - LAN tracking interface not always working
    - if DHCPv6 for the pppoe interface can be somehow controlled via cron there is about a minute between the pppoe v4 reconnect and the request for a new v6 suffix (& IP for FW if configured). During that time IPv6 does not work and all devices loose connections to v6 targets for more than a minute (until SLAAC or the local DHCPv6 server kicks in once the new suffix is received)

Why are there no options in the PPPoe configuration page to control when a forced reconnect should occure? I've read multiple threads regarding this isssue and I don't understand why it's not addressed properly? PPPoe is still common, even with fiber providers (for whatever reason). People are litterally switching to other (commercial) products because OPNsense (and apparently pfsense as well) is not handling this problem properly for years. This is very sad.

The following optional options in the pppoe config page make sense in my opinion:

"when to trigger post pppoe reconnect" (both option can be active at the same time):

    - force pppoe reconnect at MM:HH every day or via cronstyle schedule and trigger "post ppoe reconnect" tasks
    - watch pppoe v4 IP and trigger "post pppoe reconnect" when changed

The following option make not only sense when the reconnect is triggered but should be also be triggered when pppoe receives a new v4 address.

"post pppoe reconnect / new pppoe ip":
(order should be fixed since they depend on each other)

    - request a new IPv6 suffix (& IP for FW if configured) after pppoe is up again --> DHCP (client) reload
    - force configured v6 tracking LAN interfaces to track the new v6 suffix (to make sure it knows about the new suffix)
    - trigger SLAAC/radv restart (to make sure it knows about the new suffix)
    - trigger local DHCPv6 server restart (to make sure it knows about the new suffix)

Most of these options should be possible to implement quiet easy since nearby all actions are already possible somehow within the GUI. If there is a GUI option there is a command to be triggered via other means. The only one where I couldn't find a button for is to force the LAN interface tracking.

I hope that this somehow makes sense and that we have a solution at hand within version 23.x.



Auch wenn der Post schon was älter ist, danke für den Hinweis dem Host zu sagen er soll die /56 zum WAN Interface der OPNsense routen. Wäre ich so schnell nicht drauf gekommen.
Dachte die ganze Zeit es lag an irgendeiner Firewall Regel, weil OPNsense selbst ohne Probleme ins Internet gekommen ist.

Sollte es nicht theoretisch dann auch so mit dem Standard /64 Sub von Hetzner tun?
Dem Host eine IP aus dem Netz mit /128 geben und die Route für den Rest des Netzwerkes setzen (/64) auf die IP des OPNsense WAN Ports?

Danke!

Ok, solved it now by adding an inbound NAT rule (port forward).

Forwarding incoming connections destined to the virtual IP to the primary IP with the same port.

In any case it would be nice to use WireGuard with virtual IPs without this port-forward.

This should be in the default settings once the wizard is there. Took me many hours to figure this out and yet the solution is so simple. Why is it so difficult for WG to work with VIPs while OpenVPN has no trouble (and no special NAT rules)?

Adding sync is easy, can you open a feature request in GitHub?

I could not find any issue regarding this. So I created a new one. Let's get this feature added soon.

https://github.com/opnsense/plugins/issues/2279