Beiträge von Jung-Fernmelder

Zitat von frank_m

Wenn du also täglich um 03:01 trennst, und bei deinem Provider läuft die Uhr ein wenig schneller, dann kommt er dir zuvor, und ggf. gibt es dann auch zwei Trennungen, wenn sich die beiden nicht überlappen.

Dieser Effekt ist mir bislang unbekannt. Bislang keine bekannten doppelten Trennungen in einer Nacht.

Zitat von HubeBube

Üblicherweise kann man bei den IADs einen NTP-Server als Zeitquelle angeben, dies sollte man auch tun. Damit haben sich die Abweichungen erledigt, es sei denn die verbaute Hardwareuhr ist grottig.

Sicherlich ist eine Synchronisierung konfiguriert. Doch ist die Ganggenauigkeit der Hardwareuhr so genau, dass die durch die zwischen zwei Synchronisierungen vergagene Zeit bedingte Abweichung im Bereich weniger Millisekunden liegt? Oder hat man da nicht viel eher schon mehrere Sekunden Abweichung "gesammelt"?

Zitat von frank_m

Wenn man z.B. in der Fritzbox einstellt, die Zwangstrennung solle zwischen 3 und 4 Uhr stattfinden, dann beginnt sie am ersten Tag um 03:59, am zweiten trennt sie um 03:58 Uhr usw. bis 03:01.

Bei pfSense kann man ohne Kunstgriffe lediglich einen Zeitpunkt (Minute, Stunde, gegebenenfalls Datum) festlegen, standardmäßig keine Option für einen sich ändernden Zeitpunkt.

Soeben habe ich mir die das PPP-Log einer pfSense angesehen (ISP: Deutsche GigaNetz GmbH, Tarif: MyNet 600): Es zeigt am gestrigen 25-Stunde-Tag einen offenbar ungeplanten Verlust der PPPoE-Verbindung um 02:01 Uhr MEZ und später um 03:01 Uhr MEZ einen erneuten Verlust der PPPoE-Verbindung, welchen ich der konfigurierten Zwangstrennung zuschreibe. Dies bestätigt die Angabe von frank_m im ersten Absatz seines Beitrages von heute, 08:24 Uhr MEZ.

Um die Frage nach der "Kulanzzeit" zu beantworten, könnte der Themenersteller bei Gelegenheit die Zwangstrennung in der pfSense deaktivieren und prüfen, wann die Verbindung seitens des ISP getrennt wird.

Zitat von ConiKost

Welcher große ISP hat heute noch klassische 24 Stunden Trennung?

Deutsche Giganetz GmbH

Und somit aller Wahrscheinlichkeit auch alle anderen ISPs, die ihre Telekommunikationsprodukte über die Infastruktur der Firma Purtel realisieren.

Zitat von HubeBube

Versuch macht klug. Zweimal im Jahr hast Du die Möglichkeit herauszufinden, wie während der Zeitumstellung IAD und Provider reagieren.

Den 26.10.2025 habe ich mir bereits im Kalender markiert. Die Nacht auf gestern habe ich weit weg offline mit der provorischen Reparatur eingeworfener Fensterscheiben verbracht.

Der 23-Stunden-Tag Ende März dürfte hier keine Relevanz haben, weil man hier dem Auslaufen des 24-Stunden-Zeitraums um eine Stunde zuvorkommt.

Zitat von HubeBube

Da es verschiedene Methoden zur Angleichung der Uhrzeit gibt, hängt dies stark von der Implementierung im IAD ab.

Mir geht es um den Fall, in dem die Systemzeit des IADs, warum auch immer, 1 - 30 Sekunden von der gesetzlichen Uhrzeit abweicht.

Hoch geschätztes Glasfaserfoum!

Bei vielen ISPs gibt es eine Zwangstrennung pro 24 h. Außer bei abweichendem Nutzerwunsch konfiguriert der Fragesteller die entsprechenden Geräte so, dass diese um 03:01 Uhr erfolgt.
Nun gibt es in Mitteleuropa jedes Jahr Ende Oktober einen Sonntag, der 25 Stunden hat. Sind an diesem Sonntag zwei Zwangstrennungen erforderlich? Oder gewährt der ISP an diesem Tag, passend zur längeren Dauer des Tages, eine Frist von 25 h?
Räumt der ISP grundsätzlich eine Art "Kulanzzeit" bei der Zwangstrennung ein? Gegebenenfalls auch nur 30 s. Beispielsweise für den Fall, dass sich die Systemuhr eines IADs um einige Sekunden oder gar halbe Minute verstellt hat. Oder wird seitens des ISPs nach 86 400,000 s gnadenlos die Verbindung unterbrochen?
Im vorliegenden Fall ist der ISP die Deutsche GigaNetz GmbH, jedoch wäre eine Antwort, die für alle deutschen ISPs mit Zwangstrennung gilt, am besten … dies werden doch wohl alle deutschen ISPs mit Zwangstrennung gleich handhaben. Der Fragesteller freut sich auf die Rückmeldungen.

Mit freundlichen Grüßen

Jung-Fernmelder

Viel Diskussion um ein wenig Ästhetik.

Der Verfasser dieses Beitrages würde eben sicherstellen, dass das IAD, die "Dose" sowie die Verkabelung in einen hübschen Kasten kommen, der einerseits optisch 'was hermacht und andererseits eine adäquate Belüftung sowie schnellen und einfachen Zugang für Wartungsarbeiten sicherstellt.

Ob man eine Glasfaseranschlussdose mit Kupplung verbaut und die Telekommunikationsendeinrichtung über ein kurzes Patchkabel anschließt oder nicht, ist im Prinzip irrelevant - beides hat Vor- und Nachteile:

Glasfaseranschlussdoese mit Kupplung:

+ langes Patchkabel zum HüP wird geschont

+ wird der Anschluss mechanisch überbeansprucht, muss nur ein kurzes Patchkabel ausgetauscht werden

- verursacht Kosten

- jede Verbindung ist eine potentielle Fehlerquelle

o 0,4 dB Dämpfung

ohne:

+ keine weiteren Kosten

+ eine Verbindung und somit eine potentielle Fehlerquelle weniger

- wird der Anschluss mechanisch überbeansprucht, muss das lange Patchkabel zum HüP ausgetauscht werden

o Dämpfung bleibt dieselbe

Die Dämpfung hat der Verfasser dieses Beitrages bewusst hinter ein o gesetzt, denn diese ist so gering, dass sie keine Auswirkungen hätte.

Der Verfasser dieses Beitrages würde einen der folgenden Wege wählen:

1. Nichts tun und Freundschaft mit der Abwesenheit von Ästhetik schließen. In der Liebe macht man das auch des öfteren.

2. Eine "richtig ästhetische" Lösung erarbeiten. Beispielsweise könnte man aus Kiefer-Sperrholz, Stärke sechs Millimeter, einen Kasten bauen, der auf Wunsch durch das Aufstellen einer Vase oder einer Figur aufgewertet werden kann. Es ist lediglich ein nicht zu starker Holzwerkstoff zu wählen, eine Möglichkeit zum schnellen und einfachen Öffnen zwecks Wartung vorzusehen und für ausreichende Belüftung zu sorgen. Für letzteres könnten beispielsweise auf der Unter- und Oberseite des Kastens jeweils zwei Langlöcher mit der Oberfräse eingebracht werden.

Viel Erfolg bei dem Verschönerungsvorhaben!

Guten Tag,

vielen herzlichen Dank für die zahlreichen Antworten. Ich denke, dass diese weiterhelfen werden.

Zitat von mbo77

Was ich in der Materialschlacht nicht gefunden habe, sind Hinweise aus den Logfiles.

Hier einmal das PPP-Log nach circa einer halben Stunde Betrieb:

Aug 20 13:34:04 	ppp 	16625 	[wan] IFACE: Up event
Aug 20 13:34:04 	ppp 	16625 	[wan] IFACE: Rename interface ng0 to pppoe0
Aug 20 13:34:04 	ppp 	16625 	[wan] IFACE: Add description "Fiber_DGN"
Aug 20 13:34:01 	ppp 	16625 	[wan_link0] CHAP: rec'd SUCCESS #169 len: 4
Aug 20 13:34:01 	ppp 	16625 	[wan_link0] LCP: authorization successful
Aug 20 13:34:01 	ppp 	16625 	[wan_link0] Link: Matched action 'bundle "wan" ""'
Aug 20 13:34:01 	ppp 	16625 	[wan_link0] Link: Join bundle "wan"
Aug 20 13:34:01 	ppp 	16625 	[wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: Open event
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: state change Initial --> Starting
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: LayerStart
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: Open event
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: state change Initial --> Starting
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: LayerStart
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: Up event
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: state change Starting --> Req-Sent
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: SendConfigReq #1
Aug 20 13:34:01 	ppp 	16625 	[wan] IPADDR 0.0.0.0
Aug 20 13:34:01 	ppp 	16625 	[wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: Up event
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: state change Starting --> Req-Sent
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: SendConfigReq #1
Aug 20 13:34:01 	ppp 	16625 	[wan_link0] LCP: rec'd Protocol Reject #245 (Opened)
Aug 20 13:34:01 	ppp 	16625 	[wan_link0] LCP: protocol IPCP was rejected
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: protocol was rejected by peer
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: state change Req-Sent --> Stopped
Aug 20 13:34:01 	ppp 	16625 	[wan] IPCP: LayerFinish
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: rec'd Configure Request #148 (Req-Sent)
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: SendConfigAck #148
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: state change Req-Sent --> Ack-Sent
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: state change Ack-Sent --> Opened
Aug 20 13:34:01 	ppp 	16625 	[wan] IPV6CP: LayerUp
Aug 20 13:34:01 	ppp 	16625 	[wan] xxxx:xxxx:xxxx:xxxx -> xxxx:xxxx:xxxx:xxxx
Aug 20 13:34:00 	ppp 	16625 	PPPoE: rec'd ACNAME "mx.fra4"
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] PPPoE: connection successful
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] Link: UP event
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: Up event
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: state change Starting --> Req-Sent
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: SendConfigReq #1
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] PROTOCOMP
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MRU 1492
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MAGICNUM 0x55d1470b
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: rec'd Configure Request #244 (Req-Sent)
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MRU 1492
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] AUTHPROTO CHAP MD5
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MAGICNUM 0x763262fe
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: SendConfigAck #244
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MRU 1492
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] AUTHPROTO CHAP MD5
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MAGICNUM 0x763262fe
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: state change Req-Sent --> Ack-Sent
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: rec'd Configure Ack #1 (Ack-Sent)
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] PROTOCOMP
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MRU 1492
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] MAGICNUM 0x55d1470b
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: state change Ack-Sent --> Opened
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: auth: peer wants CHAP, I want nothing
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] LCP: LayerUp
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] CHAP: rec'd CHALLENGE #169 len: 31
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] Name: "JUNOS"
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] CHAP: Using authname "Pxxxxxxx@dgn.digital"
Aug 20 13:34:00 	ppp 	16625 	[wan_link0] CHAP: sending RESPONSE #169 len: 41
Aug 20 13:33:53 	ppp 	16625 	[wan_link0] Link: reconnection attempt 1
Aug 20 13:33:53 	ppp 	16625 	[wan_link0] PPPoE: Connecting to ''
Aug 20 13:33:50 	ppp 	16625 	[wan_link0] PPPoE connection timeout after 9 seconds
Aug 20 13:33:50 	ppp 	16625 	[wan_link0] Link: DOWN event
Aug 20 13:33:50 	ppp 	16625 	[wan_link0] LCP: Down event
Aug 20 13:33:50 	ppp 	16625 	[wan_link0] Link: reconnection attempt 1 in 3 seconds
Aug 20 13:33:41 	ppp 	16625 	Multi-link PPP daemon for FreeBSD
Aug 20 13:33:41 	ppp 	16625 	process 16625 started, version 5.9
Aug 20 13:33:41 	ppp 	16625 	web: web is not running
Aug 20 13:33:41 	ppp 	16625 	[wan] Bundle: Interface ng0 created
Aug 20 13:33:41 	ppp 	16625 	[wan_link0] Link: OPEN event
Aug 20 13:33:41 	ppp 	16625 	[wan_link0] LCP: Open event
Aug 20 13:33:41 	ppp 	16625 	[wan_link0] LCP: state change Initial --> Starting
Aug 20 13:33:41 	ppp 	16625 	[wan_link0] LCP: LayerStart
Aug 20 13:33:41 	ppp 	16625 	[wan_link0] PPPoE: Connecting to '' 

Das DHCP-Log ist zu lang, um es hier komplett zu veröffentlichen. Eine Meldung tritt häufig auf:

Aug 20 13:55:03 	kea-dhcp6 	87926 	WARN [kea-dhcp6.dhcpsrv.0x2bd53fa12000] DHCPSRV_LEASE_SANITY_FAIL The lease 2a01:41e3:xxxx:xxx0::1000 with subnet-id 1 failed subnet-id checks (the lease IP address did not belong to a configured subnet). 

Zitat von mbo77

Ich würde adhoc erstmal das Monitoring der Gateways einstellen.

Heute habe ich mich in die WebGUI der pfSense eingeloggt, während der ONT noch abgeschaltet war, habe das Monitorung der Gateways deaktiviert und das zweite GIF mit dem AFTR, dessen IPv6-Adresse mit 2 endet, gelöscht. Danach habe ich die pfSense neu gestartet und den ONT eingeschaltet.

Zitat von kingpin42

Insbesondere nicht die Adressen des AFTR dauerhaft pingen

Könntest Du Dir das vielleicht nochmal genauer ansehen? Eigentlich habe ich das zwischenzeitlich deaktivierte Monitoring so konfiguriert, dass öffentliches DNS-Server eines Anbieters (dns.watch), die ich in der Vergangenheit genutzt habe und nicht die Adressen des AFTR angepingt werden.

Zitat von bananajoe

Eine Empfehlung ist den AFTR nicht als FQDN einzutragen, sondern als IPv6 Adresse.

Das habe ich von Anfang an so gehandhabt. pfSense unterstützt das Eintragen von FQDNs auch nicht. Das wird mit dieser Fehlermeldung quittiert:

Zitat von mbo77

Weshalb hast du den GIF-Tunnel doppelt eingerichtet?

Da pfSense keine FQDNs unterstützt, muss man die IPv6-Adresse, welche man über einen DNS Lookup herausfinden kann, eintragen. Der DNS Lookup sieht so aus:

Es gibt zwei AAAA-Einträge, die auf zwei IPv6-Adressen verweisen. Ich habe für beide IPv6-Adressen jeweils einen GIF eingerichtet, sodass ich in dem Fall, dass einer von beiden nicht oder nicht richtig funktioniert, leicht manuell oder auch automatisiert wechseln kann. Für die weiteren Tests habe ich mich auf einen von beiden (der, dessen IPv6-Adresse auf 3 endet) beschränkt.

Zitat von bananajoe

Einfache Lösung: einen Dual-Stack für 3,90€/Monat hinzubuchen.
Damit läuft es super.

Auch das ist eine Herangehensweise. Magst Du vielleicht folgende Fragen dazu beantworten; das würde bestimmt gut helfen, sich im Allgemeinen ein Bild darüber zu machen:

1. Welche "Sense" verwendest Du?

2. Bei welchem Anbieter bist Du und welchen Tarif hast Du gebucht?

3. Wie lange läuft dieses Setup bereits?

4. Welche Störungen sind seit Betriebsbeginn aufgetreten und wie lange dauerten diese an?

Bei dem heutigen Test mit den angepassten Einstellungen gab es dieses Ergebnis: IPv4 funktionierte überhaupt nicht. IPv6 funktionierte ungefähr eine halbe Stunde lang und stellte danach die Funktion ein.

Gibt es bei der Deutschen Giganetz eigentlich eine Zwangstrennung?

Habt noch einen angenehmen Nachmittag!

Mit freundlichen Grüßen

Jung-Fernmelder

Darf man nachfragen, welchen Störfaktor das Monitoring darstellt? Ist doch vollkommen normal, dass Netzwerkverbingungen ein Monitoring haben ...

Zugriff auf das Gerät werde ich ohnehin morgen oder erst gegen Ende der Woche wieder haben.

Zitat von mbo77

Hinweise aus den Logfiles

Welche Logfiles bräuchtest Du denn?

Die PPPoE-Einwahl hat bislang keine Probleme verursacht, die ich aus den PPP-Logs hätte herauslesen können.

Zitat von mbo77

Hast du das Verhalten des Systems unter Last beobachtet?

Nein. Die Verbindung lies sich bislang nicht lange genug belasten, um ausführlich "beobachten" zu können.

Über speedtest.net habe ich ein paar Speedtests durchgeführt, wenn dies gerade möglich war. Die Speedtests entsprachen dem gebuchten Tarif. Die Verbindung blieb auch nach den Speedtests bestehen.

Als die Verbindung komplett abgebrochen war, habe ich ein Mitschnitt des WAN-Interfaces erstellt und mit Wireshark ausgewertet. Unter anderem war erkennbar, dass der Pinger-Daemon die Monitor-IP-Adressen angepingt hat, aber keinerlei Rückmeldung erhielt; im Allgemeinen war kaum ein Paket im Mitschnitt erhalten, zu dem Wireshark eine Rückmeldung gefunden hätte. Offenbar hat die Providerseite das Senden von Paketen an den Kunden eingestellt.

Alle hier nicht gezeigten Einstellungen habe ich entweder auf der Voreinstellung belassen oder halte sie für nicht relevant.

Das Netzwerk wird in vier LANs für vier Verwendungszwecke unterteilt. Die Konfigurationen von LAN1, LAN2 und LAN3 sind entsprechend zu der von LAN0 und werden daher nicht gezeigt.

Diese IP-Adressen werden einem Rechner zugewiesen, den man an die LAN0-Schnittstelle direkt oder über ein Switch anschließt:

Und hier die Ausgabe von ifconfig:

Shell Output - ifconfig

re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN1
options=82098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:censored
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::censored%re0 prefixlen 64 scopeid 0x1
inet6 fe80::1:1%re0 prefixlen 64 scopeid 0x1
inet6 2a01:41e3:xxxx:xxx1:213:3bff:fe0f:d93c prefixlen 64
media: Ethernet autoselect (none)
status: no carrier
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN2
options=82098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:censored
inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
inet6 fe80::censored%re1 prefixlen 64 scopeid 0x2
inet6 fe80::1:1%re1 prefixlen 64 scopeid 0x2
inet6 2a01:41e3:xxxx:xxx2:213:3bff:fe0f:d93d prefixlen 64
media: Ethernet autoselect (none)
status: no carrier
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
re2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN0
options=82098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 00:censored
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::censored%re2 prefixlen 64 scopeid 0x3
inet6 fe80::1:1%re2 prefixlen 64 scopeid 0x3
inet6 2a01:41e3:xxxx:xxx0:223:54ff:fe61:2278 prefixlen 64
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:censored
media: Ethernet autoselect
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
re3: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=82099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether 0c:censored
inet6 fe80::censored%re3 prefixlen 64 scopeid 0x5
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN3
options=2008<VLAN_MTU,WOL_MAGIC>
ether 00:censored
inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255
inet6 fe80::censored%rl0 prefixlen 64 scopeid 0x6
inet6 fe80::1:1%rl0 prefixlen 64 scopeid 0x6
inet6 2a01:41e3:xxxx:xxx3:250:baff:febb:9c2d prefixlen 64
media: Ethernet autoselect (none)
status: no carrier
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0x0
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=100<PROMISC> metric 0 mtu 33152
options=0
groups: pflog
pfsync0: flags=0 metric 0 mtu 1500
options=0
maxupd: 128 defer: off version: 1400
syncok: 1
groups: pfsync
re3.7: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 0c:censored
inet6 fe80::censored%re3.7 prefixlen 64 scopeid 0xb
groups: vlan
vlan: 7 vlanproto: 802.1q vlanpcp: 0 parent interface: re3
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: Fiber_DGN
options=0
inet6 fe80::censored%pppoe0 prefixlen 64 scopeid 0xc
inet6 2a01:41e3:4000::1:xxxx prefixlen 128 pltime 86400 vltime 86400
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
gif0: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1412
description: AFTR3_DGN
options=80000<LINKSTATE>
tunnel inet6 2a01:41e3:4000::1:xxxx --> 2a01:41e3:ffff:cafe:face::3
inet 192.0.0.2 --> 192.0.0.1 netmask 0xfffffff8
inet6 fe80::censored%gif0 prefixlen 64 scopeid 0xd
groups: gif
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
gif1: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1412
description: AFTR2_DGN
options=80000<LINKSTATE>
tunnel inet6 2a01:41e3:4000::1:xxxx --> 2a01:41e3:ffff:cafe:face::2
inet 192.0.0.2 --> 192.0.0.1 netmask 0xfffffff8
inet6 fe80::censored%gif1 prefixlen 64 scopeid 0xe
groups: gif
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Es wäre super, wenn mir jemand mitteilen könnte, welche Einstellung (-en) ich falsch vorgenommen habe und wie ich die zu korrigieren habe.

Tatsächlich habe ich mir überlegt, ob ich diesen Beitrag im Netgate-Forum veröffentliche oder hier und habe mich dazu entschieden, ihn hier zu veröffentlichen, da es hier eher darum geht, die korrekten Einstellungen für einen konkreten Glasfaser-Anbieter zu finden als um pfSense. Ich hoffe, dass ich hier richtig bin und mir wer helfen kann. Gegebenenfalls werde ich den Beitrag aber zusätzlich im Netgate-Forum veröffentlichen müssen. Habt eine gute Zeit! Ich freue mich darauf, gemeinsam mit Ihnen die korrekte Konfiguration zu erarbeiten.

Mit freundlichen Grüßen

Jung-Fernmelder

Weitere Konfiguration:

Hoch geschätztes Glasfaser-Forum!

Die Deutsche Giganetz hat dem X eine FTTH-Glasfaser gelegt und auf diese den Tarif MyNet 600 geschaltet. Aufgrund diverser Limitierungen der im Tarif enthaltenen AVM FRITZ!Box hat der X entschieden, als IAD eine pfSense zu nutzen, zumal er an diese aus mehreren anderen Umfeldern bereits gewöhnt ist. Die Aufgabe des Themenerstellers ist die Konfiguration der pfSense.

Der Themenersteller hat die Konfiguration der pfSense vorgenommen und es tritt noch ein Fehler auf. Die Verbindung ist ausgesprochen unzuverlässig. Nach dem Hochfahren der pfSense wird eine Verbindung aufgebaut, jedoch lassen sich nicht alle Internetseiten nutzen. Zeitweise sind überhaupt keine Verbindungen ins Internet möglich; zeitweise fällt nur IPv6, zeitweise fallen nur der AFTR und somit IPv4-Verbindungen aus. Aus Sicht des Themenerstellers ist dieses Verhalten unvorhersehbar. Die Ursache sucht er in der Konfiguration der pfSense, da dieses Verhalten bei Nutzung der bereitgestellten AVM FRITZ!Box nicht aufgetreten ist.

Die Konfiguration der pfSense ist wie folgt gestaltet:

Anmerkung zum ersten Screenshot: Manchmal haben alle drei Gateways eine Verbindung ins Internet; manchmal ist eines der beiden AFTRs oder auch beide offline. Manchmal ist eben, wie gezeigt, keines der Gateways online.

Bearbeitungsvermerk 19.08.2024 21:54 Uhr MESZ: Falsche Screenshots gegen die richtigen ersetzt.