Messages

1

23.1 Production Series / Re: IPv6 on Deutsche Telekom very unstable, PPPoE reload dyfunctional since 23.1

« on: February 02, 2023, 03:34:23 pm »

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

2

German - Deutsch / Re: PPPoE reconnect "verliert" IPv6 Adressen

« on: October 17, 2022, 06:05:22 pm »

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]

(...)
<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]

<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

3

22.7 Legacy Series / Re: Health check: py37-markupsafe -> missing dependency python37

« on: September 13, 2022, 10:10:05 am »

look here

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

4

22.7 Legacy Series / Re: ipv6: Interface Identifier equal on LAN and WAN

« on: August 19, 2022, 04:19:39 pm »

Thanks a lot for this answer!

Will try the tuneables and see what happens

5

22.7 Legacy Series / ipv6: Interface Identifier equal on LAN and WAN

« on: August 19, 2022, 10:54:59 am »

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

6

German - Deutsch / Re: Wiederholt Ausfall meiner OPNSense

« on: June 29, 2022, 09:05:40 am »

Out of memory?

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

7

22.1 Legacy Series / [SOLVED]Re: 22.1.9 no access to logs from GUI for some services

« on: June 26, 2022, 08:50:01 pm »

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

8

22.1 Legacy Series / [SOLVED] 22.1.9 no access to logs from GUI for some services

« on: June 25, 2022, 04:52:05 pm »

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

9

German - Deutsch / Re: Telekom Glasfaser keine IPv6 auf LAN clients.

« on: March 25, 2022, 02:54:48 pm »

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

wie ist denn da der Aufbau Deiner opnsense?

10

German - Deutsch / Re: 2 VoIP Provider und keinen Plan vom Thema

« on: March 23, 2022, 12:33:35 pm »

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

11

German - Deutsch / Re: 2 VoIP Provider und keinen Plan vom Thema

« on: March 23, 2022, 10:23:17 am »

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

12

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 06:11:42 pm »

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

13

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 05:28:53 pm »

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

14

German - Deutsch / Re: 2 VoIP Provider und keinen Plan vom Thema

« on: March 22, 2022, 02:28:02 pm »

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

15

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 12:33:48 pm »

yep, funktioniert da immer noch!

Was genau geht denn nicht?

br br