Messages

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

An meinem privaten VOIP Anschluss bekomme ich das ohne STUN in Verbindung mit static ports nicht ans laufen, muss also bei mir aktiviert sein;

Nach meinen Informationen braucht man STUN bei einem SIP Trunk Anschluss, zB Deutschland LAN in der Tat nicht, habe aber mangels Möglichkeit noch nicht selbst ausprobiert ...

br br

yep, funktioniert da immer noch!

Was genau geht denn nicht?

br br

Auf der Go Box:

stun benutzen ja, stun refreshzeit 240, NAT refreshzeit 20, DNS SRV lookup ja, wurde letztes Jahr umgestellt bei Telekom.

domain tel.t-online.de, gleiches für proxy Serveradresse und Registration server und outbound Serveradresse

Outbound proxy modus nie

Ich verwende d_magenta_de.bin als Profilversion

dann bei weitere VOIP Einstellungen: SIP Update ja, Zieladresse ableiten: aus SIP contact Header

die RTP Ports müssen sowohl eingehend als auch ausgehend denen entsprechen, die in den FW/NAT Regeln angegeben sind.

Br br