Messages

... as said in my 3rd paragraph - they are neither AND they have by far less functionality in almost all areas

The decision is to be made dependent from what your requirements are and what to balance out against what.

"Trouble free" is a big illusion - as simple as that

br br

All,

I am getting meanwhile somewhat puzzled where this discussion shall lead to and what the expectation towards opnsense shall result in.

My view is:
Simply forget about that Opnsense can fix something which is more than obviously originated from the network side. There are myriads of reasons why reconnects are triggered from network side, and this even on several layers (DSL, PPPoE, ...(10(..)000x) ... (up to) even problems in your in-house cabling), and there are myriads of combinations thinkable that this happens when (one of) the sides are not in a well defined state where a golden rule can apply which fixes everything with a single finger tip. And even if we can find 10-ish issues where some workarounds on opnsense can circumnavigate some network issues, still myriads of reasons will stay.

Even for officially authorized router devices from Telekom, the fora are FULL of stories, reports, complaints, angryness around this Zwangstrennungs beast. Lets not try to chase a phantom on opnsense side which is not helping to get things improved.

The best proposal when experiencing such a thing has been meanwhile mentioned 100 times: Reconnect from client side once this situation occurs. Three layers to try:

1.) Reconnect on PPPoE - if fail
2.) Reconnect DSL including reconnecting PPPoE - if failing again
3.) Reboot opnsense and Modem (which includes again DSL and PPPoE reconnect, incl. ipv6)

If there was no physical line problem or a problem on a relevant device on network side out of service, I could reach with that a stable ipv6 connection again in 100% of the cases.

Just my 10 cents

Br br

Hi there

@sbellon I have exactly the same set up as you have and still the good old description of

https://forum.opnsense.org/index.php?topic=21839.0

fits also for 23.1 in so far. From my view close to the "definitive" way you seem to look for.

However, "Zwangstrennung" due to the many different reasons it is carried out from network side is a somewhat different animal which is hard to be addressed from client side in all its (often unknown and intransparent) cases. Zwangstrennung is done for maintenance, new customers on the same line bundle and after-optimization, incident resolution, construction work, and many more. Btw. also all my fritzboxes lost ipv6 after Zwangstrennung pretty often.

I can confirm that I saw also in several old versions of Opnsense that IPv6 did not come up properly after Zwangstrennung. I could then recover ipv6 by manually storing the WAN config again and ipv6 was back. Other than that, playing around with the settings on the client side did not bring any improvement for the Zwangstrennung case.

I also did not see that I got the same ipv6 prefix after a Zwangstrennung that I had before - was always different. 

Br br

Hallo zusammen,

seit letzter Woche beobachte ich auch auf meinem Telekom Anschluss (Magenta XL) dieses Verhalten mit IPv6. Bei mir hängt dies wohl damit zusammen, dass aktuell jede Nacht zwischen 3 und 4 Uhr (typisches Wartungsfenster der Telekom) eine netzseitige Zwangstrennnung erfolgt.

Wahrscheinlich gab es kürzlich ein Software Update oder ein Profilupdate für (das) DSL Leitungsbündel; danach wird häufig für einige Tage bis wenige Wochen regelmäßig getrennt, damit die Optimierungssoftware ASSIA das für das jeweilige Leitungsbündel optimale Profil finden und einrichten kann. So etwas kann zB auch dann vorkommen, wenn auf einem Leitungsbündel neue Anschlüsse geschaltet werden oder Baumaßnahmen durchgeführt wurden.

Unabhängig davon ist die Frage, wie die Opnsense damit klarkommt. Bei mir ist nicht nur das Thema IPv6, was so ca jedes 2. - 3. Mal nicht funktioniert, sondern der Dyndns update findet ebenfalls häufig nicht statt.

In den Logs sieht das dann zumeist so aus:

Code Select Expand


(...)
<13>1 2022-10-14T03:33:06+02:00 OPNsense.zuhause.xx opnsense 86316 - [meta sequenceId="130"] plugins_configure dhcp (,inet6)
<13>1 2022-10-14T03:33:06+02:00 OPNsense.zuhause.xx opnsense 86316 - [meta sequenceId="131"] plugins_configure dhcp (execute task : dhcpd_dhcp_configure(,inet6))
<13>1 2022-10-14T03:33:06+02:00 OPNsense.zuhause.xx dhcp6c 23613 - [meta sequenceId="132"] dhcp6c REQUEST on pppoe0 - running newipv6
<11>1 2022-10-14T03:33:07+02:00 OPNsense.zuhause.xx opnsense 30975 - [meta sequenceId="133"] /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
<11>1 2022-10-14T03:33:07+02:00 OPNsense.zuhause.xx opnsense 30975 - [meta sequenceId="134"] /usr/local/etc/rc.newwanipv6: On (IP address: 2003:f8:XX:XX:XX....) (interface: WAN[wan]) (real i
nterface: pppoe0).
(.... 100 te Male hintereinander)


Für Dyndns Update startet es mit der Fehlermeldung:

Code Select Expand


<11>1 2022-10-14T03:30:19+02:00 OPNsense.zuhause.xx opnsense 19307 - [meta sequenceId="1"] /usr/local/etc/rc.dyndns: Curl error occurred: Resolving timed out after 15010 milliseconds
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 37711 - [meta sequenceId="2"] plugins_configure dns_reload (1)
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 37711 - [meta sequenceId="3"] plugins_configure dns_reload (execute task : system_resolvconf_generate(1))
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 58583 - [meta sequenceId="4"] plugins_configure dns_reload (1)
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 58583 - [meta sequenceId="5"] plugins_configure dns_reload (execute task : system_resolvconf_generate(1))
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 37711 - [meta sequenceId="6"] plugins_configure dns_reload (execute task : system_hosts_generate(1))
<13>1 2022-10-14T03:30:34+02:00 OPNsense.zuhause.xx opnsense 58583 - [meta sequenceId="7"] plugins_configure dns_reload (execute task : system_hosts_generate(1))
<11>1 2022-10-14T03:30:39+02:00 OPNsense.zuhause.xx opnsense 25399 - [meta sequenceId="8"] /usr/local/etc/rc.dyndns: Curl error occurred: Resolving timed out after 15004 milliseconds
<27>1 2022-10-14T03:30:44+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="9"] transmit failed: Can't assign requested address
<27>1 2022-10-14T03:31:23+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="10"] transmit failed: Can't assign requested address
<27>1 2022-10-14T03:31:29+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="11"] transmit failed: Can't assign requested address
<27>1 2022-10-14T03:32:40+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="1"] transmit failed: Can't assign requested address
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 86228 - [meta sequenceId="2"] /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'pppoe0'
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 86228 - [meta sequenceId="3"] /usr/local/etc/rc.newwanip: On (IP address: 87.178.19.22) (interface: WAN[wan]) (real interface: pppoe0).
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 720 - [meta sequenceId="4"] /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 720 - [meta sequenceId="5"] /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN[wan]
<13>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx dhcp6c 11057 - [meta sequenceId="6"] RTSOLD script - Sending SIGHUP to dhcp6c
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 86228 - [meta sequenceId="7"] /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
<13>1 2022-10-14T03:32:48+02:00 OPNsense.zuhause.xx dhcp6c 17933 - [meta sequenceId="8"] RTSOLD script - Sending SIGHUP to dhcp6c
(...)
<11>1 2022-10-14T03:32:50+02:00 OPNsense.zuhause.xx php 86228 - [meta sequenceId="40"] /usr/local/etc/rc.newwanip: Curl error occurred: Could not resolve host: update.dedyn.io
(...)


und dann werden baw auch keine Updateversuche mehr unternommen.

Mal ist 'nur' kein IPv6, mal geht beides nicht, mal ist nur kein Dyndns update.

Lösung ist jedenfalls ein Client seitiges Neuverbinden, dann geht alles wieder (wurde ja auch schon so beschrieben)

Hoffen wir mal, dass bald wieder Ruhe herrscht und die Optimierung zügig abgeschlossen wird .... Ist so jedenfalls lästig

Br br

look here

https://forum.opnsense.org/index.php?topic=26835.msg134525#msg134525

Thanks a lot for this answer!

Will try the tuneables and see what happens

Hi all,

A while ago I changed my config and use a Draytek Vigor 167 directly connected to my opnsense. My provider ist Deutsche Telekom and I have a SuperVectoring connection. I configured a pppoe interface on vlan7 on WAN. Moreover, I created another interface on WAN called Modem to access the Vigor if needed. I get a ipv6 prefix from my supplier and the sense builds the corresponding ipv6 interface identifier (IID) out of the MAC addresses for the full ipv6 address. I have my LAN assigned to igb0 (Mac address Xc:XX:XX:XX:21:ce) and my WAN assigned to igb1 (Mac address Xc:XX:XX:XX:21:cf). So far all is fine and running.

However when looking into the dashboard and the interface overview, it is since then obvious that my LAN and WAN interface have an identical IID. Both IIDs are derived from the LAN MAC address. As a consequence, LAN and WAN have:

• the same link local address: fe80:XeXX:efff:XXXX:21ce
• the same IID for the public ipv6 address: 2003:<prefix_WAN>:XeXX:efff:XXXX:21ce resp 2003:<prefix_LAN>:XeXX:efff:XXXX:21ce

This looks weird to me. Is there an intention for this ipv6 address building logic? If not is there a need to get this corrected and if so I am wondering whether something could be wrong in my config? Is opnsense supporting privacy extensions for ipv6 meanwhile?

Looking forward to your reply.

Br br

Out of memory?

Disk full? besonders /var/log oder das root file system?

Thanks anicoletti, that did the trick

Except dhcpd all is fine now. There seems to be an additional problem as suddenly there are no logs written since the last reboot. will look into that deeper separately why ....

Br br

Hi there,

after upgrading from 22.1.8_1 to 22.1.9 there is no access to the log files from GUI for some services. This affects in my case

dhcpd, unbound, system (backend), ACME,

The usual tricks (rebooting again manually, manual store config again , ...) did not change the situation. The GUI pages of the logs stay empty. NTP, system (general), system (webgui), firewall, routing can be viewed fine.

The log files as such are there an get updates as expected

Any idea how to analyse this further?

Looking forward to your reply

BR br

was ist denn die bridge0 für ein device für dein LAN?

wie ist denn da der Aufbau Deiner opnsense?

Wir haben jetzt 2 Möglichkeiten:

entweder wir diskutieren über abstrakte Ausschnitte aus Dokumentationen oder du probierst einfach mal aus, was andere gemacht haben, um VOIP zum laufen zu bringen. Ich jedenfalls HABE mich bereits erfolgreich durch den ganzen widersprüchlichen Mist zu VOIP im Netz durchgewühlt und habe am Ende ein funktionierendes Festnetztelefon.

Wenn du unbedingt weiterlesen willst, dann würde ich Dir das empfehlen:

https://forum.opnsense.org/index.php?topic=15993.0

Da findest Du auch den Hinweis, warum bei VOIP und Deiner Config outbound NAT wesentlich zu einem funktionierenden System beiträgt - also nix mit MultiWAN, dafür aber das Zauberwort static ports. Es mag natürlich auch noch andere Wege zum Erfolg geben, ich kann Dir jedenfalls bestätigen, dass meiner funktioniert hat.

Take it or leave it

Viel Erfolg

br br

Das Magenta Profil erhältst Du im Wizzard in der Providerliste, da kommt direkt nach Telekom dann Magenta; da gibts auch noch andere der Telekom, wie t-online etc., das Profil sollte zu Deinem Vertrag passen.

Ich habe mich auch ewig mit dem standard telekom Profil abgemüht, auch wenn die Parameter von beiden äußerlich sehr ähnlich aussehen, machen sie im Hintergrund anscheinend bestimmte Sachen anders. Jedenfalls gehts bei mir mit dem Magenta Profil, mit dem Telekom nicht.

Deine NAT Regel sieht aus meiner Sicht nicht korrekt aus.

Du brauchst eine outgoing NAT Regel mit statischen Ports und aktiviertem 'Hybride Erstellung ....' Dann brauchst du drei Portforwarding Regeln, eine für SIP, eine für RTP (meine Ports sind halt andere als bei Dir) und eine für STUN (anscheinend geht das auch ohne STUN (s.o.), habe ich aber jetzt noch nicht hingebogen); siehe Bilder

Und dann noch eine Firewall Regel, um am WAN den SIP Verkehr zu Deinem Gigaset durchzulassen ... Auch wenn da im Gigaset für SIP port 5060-5076 steht wird in der Praxis offenbar nur port 5060 bei Telekom benutzt.

EDIT: Ach ja: auch bei mir haben die SIP refresh's nach ein paar Stunden einfach aufgehört, wenn mehrere Provider auf der Gobox aktiv waren (zumindest Telekom UND Gigaset.net). Mit den og Korrekturen vielleicht wirklich mal mit nur einem Eintrag bei IP probieren ....
Br br

und die allow all regel in deinem LAN bzw. vlan (ausgehend) hat auch erweiterte Einstellungen gesetzt?

siehe https://www.heise.de/ct/artikel/MagentaTV-auf-pfSense-Co-4698826.html

wenn der nicht auf multicast umschaltet, dann kommen in der regel die igmp pakete nicht durch ....

br br

Und die beiden Firewallregeln für UDP und für IGMP auf dem WAN Interface sind ebenfalls vorhanden?

Wie sehen die denn aus? Haben beide Regeln den Haken bei 'Erlaube Einstellungen' gesetzt?

Br br