Beste Megapearl,

Aangezien ik een Experiabox heb kan ik niet uit ervaring spreken. De /48 prefix wordt aangevraagd via DHCPv6 en volgens een andere post op dit forum voor twee dagen verleend. Het is de bedoeling dat de dhcpv6 client de lease ruim van te voren verlengt, die client moet dus geactiveerd worden en geactiveerd blijven. Ik zie geen parameter in pfsense waarmee die herhalingstijd ingesteld kan worden, maar ik meen me te herinneren dat een dhcp client dat normaal  op de helft van de lease tijd doet. Enige tip die ik kan geven is in de logs te kijken van dhcp6c of dit gebeurt, en eventueel debug log in te schakelen. 

Ik heb de debug log ingeschakeld.

Er zijn onder geavanceerd een hoop instellingen mogelijk, maar ik zie nergens opties voor een release na x tijd te renewen.

Ook niet op dhcp6c.conf(5) (freebsd.org)

Ik ga de logs in de gaten houden.

Dit gaat mij boven de pet helaas. Ik heb hierover nog wat te leren ondanks dat ik het wel interessant vind. Ik hoop dat je er met de logs uitkomt en anders dat er nog iemand langskomt die je hier meer over kan vertellen. 

Beste Megapearl,

Is het probleem opgelost?

Ik heb een test gedaan met een eigen dhcp6 server met korte tijden, je ziet duidelijk de  "renews" voorbijkomen.

Oct 7 07:50:55  dhcp6c  50563   send renew to ff02::1:2%em0
Oct 7 07:50:55  dhcp6c  50563   receive reply from fe80::cbd:414d:216:ae03%em0 on em0
Oct 7 07:50:55  dhcp6c  50563   get DHCP option client ID, len 14
Oct 7 07:50:55  dhcp6c  50563   DUID: 00:01:00:01:27:b3:9d:32:52:54:00:a6:cd:90
Oct 7 07:50:55  dhcp6c  50563   get DHCP option server ID, len 14
Oct 7 07:50:55  dhcp6c  50563   DUID: 00:01:00:01:2a95:ef:18:31:bf:09:74:72
Oct 7 07:50:55  dhcp6c  50563   get DHCP option IA_PD, len 41
Oct 7 07:50:55  dhcp6c  50563   IA_PD: ID=0, T1=5, T2=8
Oct 7 07:50:55  dhcp6c  50563   get DHCP option IA_PD prefix, len 25
Oct 7 07:50:55  dhcp6c  50563   IA_PD prefix: 2001:db8:1111::/48 pltime=10 vltime=20

Nee, het is nog niet opgelost, ik heb gateway monitoring uitgezet, en de tunnel lijkt wel up te blijven, echter geeft pfSense offline aan na 2 dagen terwijl er wel ipv6 verkeer over de tunnel loopt.

Wel zie ik nog wat errors in mijn dhcp6c log waar ik nog naar ga kijken, wordt vervolgd.

dhcp6c (en dhcp6s) hebben afstandsbediening via het dhcp6ctl programma. Voor de beveiliging is dan een sleutel nodig. Deze is er niet. Het lijkt me dat deze fout genegeerd kan worden. 

Ik ben nog maar beginner in pfsense, maar heb een simulatie werkend met VLAN6 en PPPoE. dhcp6c geeft dezelfde meldingen, de dhcpctl6key error komt alleen bij opstarten. Ik krijg wel meldingen dat een adres gezet wordt op LAN en VLAN1, dus de interfaces die als “Tracking” ingesteld zijn. Om de zoveel tijd komt een “renew” boodschap, dhcp6 debugging uit. Dat zou bij KPN dus minimaal om de twee dagen moeten gebeuren.

Een vraagje: Waar geeft pfsense “offline” aan?

Wel vreemd dat IPv6 verkeer werkt terwijl offline aangegeven wordt.

Bij de gateways, vreemde is ook dat het een fe80:: adres is, ik heb al geprobeerd een geldig ipv6 adres toe te voegen onder monitoring, maar dan blijft deze gateway offline.

Als ik vanaf een client IPv6 test - IPv6/4 connectivity and speed test (ipv6-test.com) bezoek werkt zowel IPv4 en IPv6 prima.

Als ik de “KPNFIBREOPTIC_PPPOE” interface even uit en aanzet komt de “KPNFIBREOPTIC_DHCP6” gateway wel online. voor 2 dagen dan.

Gevonden….  Dit wordt wel heel vreemd.

Als je kijkt wat er over de pppoe lijn gaat: continue ping’s  tussen de link-local adressen van beide einden van de ppp verbinding. Niets mis mee, mocht van mij wel wat minder frequent. Dus dat link-local adres is het fe80 adres aan de KPN kant en is prima.  Als ik de route van de server naar pfsense weghaal, blijft de status online, terwijl er geen internet is. Klopt, want alleen de verbinding tussen de twee pppoe einden wordt gemonitord. Als ik op de server de complete IPv6 weghaal, dan zie je packetloss oplopen naar 100% en gaat de status offline. Dat is dus uw situatie, alleen: er is geen IPv6 verkeer meer mogelijk. Dus: heel vreemd. Dus wat gebeurt er aan de KPN kant???  Het enige waar de gebruiker zelf invloed kan uitoefenen is de DHCPv6.  In de PfSense console/shell kunt u met “ps ax | grep dhcp6c”  controleren of dhcp6c niet stilletjes de geest heeft gegeven. Anders toch kijken of er dhcp6c renew in de logs voorkomt. Of wordt iedere twee dagen de pppoe link vernieuwd met een ander link-local adres waar de pfsense monitoring software geen weet van heeft? Dan zou “netstat -r” in de pfsense console een andere default route adres moeten geven dan het monitoring adres. Ook niet waarschijnlijk.

Ik hoop dat een KPN medewerker meeleest en misschien een tip van de sluier kan oplichten.

[2.6.0-RELEASE][root@firewall.flissinger.local]/: ps aux | grep dhcp6c
root    50707   0.0  0.0  11128   2432  -  Is   Fri17        0:00.00 /usr/local/sbin/dhcp6c -d -n -c /var/etc/dhcp6c_opt2.conf -p /var/run/dhcp6c_pppoe1.pid pppoe1
root     7234   0.0  0.0  11240   2548  0  S+   13:24        0:00.00 grep dhcp6c
[2.6.0-RELEASE][root@firewall.flissinger.local]/:

Proces draait dus netjes.

In de logs:

Je kunt er de klok op gelijk zetten. Zou nog hooguit kunnen proberen vanuit de console het adres dat bij de monitoring vermeld is te pingen met “ping6 fe80…..%pppoe1”. Verder weet ik het echt niet. 

Ik wil best een tipje van de sluier geven. Maar ik heb hier geen weet van. Ik weet zo ook even niet waar ik moet beginnen. :(

Er loopt tweemaal het  programma "dpinger" met een default intervaltijd van 500msec. U zou kunnen proberen in Routing/Gateways/Advanced de probe tijd op 5000 en de alert tijd op 10000 te zetten voor V4 en V6, en kijken of de gateway dan (langer) online blijft.  dpinger logt in de "Gateways" sectie van de syslog, misschien dat daar nog een hint te vinden is.

Voor de rest geen enkel idee… 

Wat gebeurt er allemaal op 18 Oktober 05:07 ?   dpinger heeft problemen op de IPv4, sleept IPv6 mee en even later komt ook dhcp6c in actie om een adres te vernieuwen, met een “transmit failed” melding.  Is de interface daar opnieuw opgestart?

Error 50 kreeg ik als de IPv6 aan de server kant uitschakelde. Dan is er geen verbinding meer, dus geen IPv6 meer naar buiten.

dhcp6c lijkt in ieder geval correct te werken. Als de interface status  op ipv6 disconnected staat, werkt dan nog een handmatige ping6 vanuit de pfsense console naar het adres dat in de log vermeld staat,dus fe80::da49:bff:feb5:ddb%pppoe1 ?

Op dat tijdstip draai ik mij nog zeker 3x om en lig ik nog in een diepe coma.

Er zal genoeg gebeuren in het netwerk, er draaien diverse vm’s met daarin dockers, maar niets dat de internet verbinding zodanig belast dat hij offline gaat.

Ik zie dit overigens bij de ziggo verbinding in pfsense niet gebeuren.

De sequentie IPv4 error 65 IPv6 error 50 krijg ik bij een herstart van de PPPoE aan de server zijde. Na een aantal seconden herstelt de verbinding zichzelf, ook de IPv6 online status. Met mijn pfsense versie,2.6.0-RELEASE,  passen zowel de route als de dpinger zich aan aan het nieuwe "remote" fe80:: adres, dus dat lijkt goed te gaan. Als IPv6 offline staat maar IPv6 wel functioneert is het misschien zinvol om console "netstat -rn | grep default" te vergelijken met waar dpinger mee bezig is. Vraag is of pfsense gekke dingen doet of dat KPN de apparatuur periodiek 's nachts reset als de gebruikers nog in diepe slaap liggen. 

>2.6.0-RELEASE]Eadmin@pfSense.lan]/root: netstat -rn | grep default
default            10.0.0.1           UGS      pppoe1
default                           fe80::c151:653e:85f9:c690%pppoe1 UGS   pppoe1

Werkende situatie:

[2.6.0-RELEASE][root@firewall.flissinger.local]/root: netstat -rn | grep default
default            195.190.228.27     UGS      pppoe1
default                           fe80::da49:bff:feb5:ddb%pppoe1 UGS     pppoe1

S2.6.0-RELEASE]broot@firewall.flissinger.local]/root: ping6 -c 1 fe80::da49:bff:feb5:ddb%pppoe1
PING6(56=40+8+8 bytes) fe80::2a8:2cff:fe68:e3e3%pppoe1 --> fe80::da49:bff:feb5:ddb%pppoe1
16 bytes from fe80::da49:bff:feb5:ddb%pppoe1, icmp_seq=0 hlim=64 time=4.628 ms

--- fe80::da49:bff:feb5:ddb%pppoe1 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 4.628/4.628/4.628/0.000 ms
42.6.0-RELEASE]0root@firewall.flissinger.local]/root: ping6 -c 1 www.google.com
PING6(56=40+8+8 bytes) 2a02:a442:2ebe::1 --> 2a00:1450:400e:802::2004
16 bytes from 2a00:1450:400e:802::2004, icmp_seq=0 hlim=61 time=5.353 ms

--- www.google.com ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 5.353/5.353/5.353/0.000 ms
52.6.0-RELEASE]0root@firewall.flissinger.local]/root:

Zodra de IPv6 Tunnel offline is:

o2.6.0-RELEASE]uroot@firewall.flissinger.local]/root: netstat -rn | grep default
default            195.190.228.27     UGS      pppoe1
default                           fe80::da49:bff:feb5:ddb%pppoe1 UGS     pppoe1
p2.6.0-RELEASE]proot@firewall.flissinger.local]/root: ping6 -c 1 fe80::da49:bff:feb5:ddb%pppoe1
PING6(56=40+8+8 bytes) fe80::2a8:2cff:fe68:e3e3%pppoe1 --> fe80::da49:bff:feb5:ddb%pppoe1

--- fe80::da49:bff:feb5:ddb%pppoe1 ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
,2.6.0-RELEASE] root@firewall.flissinger.local]/root: ping6 -c 1 www.google.com
PING6(56=40+8+8 bytes) 2a02:a442:2ebe::1 --> 2a00:1450:400e:802::2004
16 bytes from 2a00:1450:400e:802::2004, icmp_seq=0 hlim=61 time=5.359 ms

--- www.google.com ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 5.359/5.359/5.359/0.000 ms
52.6.0-RELEASE]0root@firewall.flissinger.local]/root:

In beide gevallen kan ik dus vanaf pfSense op IPv6 naar www.google.com pingen.

De latency’s aanpassen heeft verder geen effect gehad.

Dus als ik alles goed zie:

De default route via het link-local adres aan KPN zijde verandert niet, en blijft functioneren.

Echter: ping tussen de twee link-local adressen aan beide zijden van de PPPoE link stopt.

Het begint wel een vreemde zaak te worden zo. De gemakkelijkste stap zou zijn een andere server als doel voor de pings te kiezen, Google of de KPNv6 nameservers, ik weet niet of ze daar blij van worden.  Prefix::1 als bron adres voor de pings, gebruikt voor google,   i.p.v link-local zou ook een optie zijn voor het geval KPN de PfSense link-local route verliest. Ik weet alleen niet hoe je dat moet instellen.  Voor de rest is denk ik het enige dat gedaan kan worden met “tcpdump -ni pppoe1 icmp6”  kijken wat naar buiten gaat en wat terugkomt tijdens online en offline, misschien is daar nog wat zinnigs uit te halen…..

Even een kleine waarschuwing: de screenshots bevatten wat teveel niet te openbaren informatie. De moderator is daar doorgaans alert op, maar wordt waarschijnlijk wanhopig als zij/hij/x de lappen tekst en screenshots voorbij ziet komen. Beste om even de firewall regels extra kritisch te blijven bekijken en aan de LAN kant een ander prefix ID >0 te kiezen. 

Ik kan m’n screenshots of uberhaupt alles wat ik hier boven gepost heb niet meer wijzigen of verwijderen.
Probleem speelt nog steeds, ik heb voor nu gateway monitoring (en de acties daarop) voor de IPv6 uitgezet voor die betreffende gateway in pfSense.

Wel speelt er nog een ander probleem, daar ik bij de ziggo modem makkelijk een uptime zie van meer dan 1 jaar, heb ik bij de KPN verbinding nog nooit een hogere uptime gezien dan 24 uur, het lijkt dus dat het ‘licht’ steeds voor een paar seconden uitvalt, ik merk dit doordat ik bij microsoft teams in gesprekken steeds een paar seconden wegval en ook de webradio in huis een paar seconden stil valt.

Nu ben ik hiervoor naar de lokale KPN winkel gegaan, en die geven het advies om de experiabox er weer tussen te zetten en dan kijken of dit verschil maakt, het lijkt mij zelf erg sterk daar de Ziggo Modem en Vodafone 4G dongle op dezelfde pfSense router dit gedrag niet vertonen, en wel een hele lange uptime hebben.

Nu zie ik wel regelmatig KPN monteurs (of een partner, zzp’er) bij de glasvezel wijkverdeelkast staan, waarschijnlijk om metingen te doen of klanten aan te sluiten, en weet niet of dit ermee te maken heeft.

Wat irritant zeg dat het nog steeds speelt. Maar als inderdaad het licht wegvalt, dan is het wel het beste om de Experia Box aan te sluiten. Dan kunnen wij ook ondersteuning bieden. Dat kunnen wij niet als er eigen apparatuur is aangesloten. 

Dat de monteurs bezig zijn in de kast zou niet zo uit mogen maken. Dan zou je ook echt alleen op dat moment uitval moeten ervaren, maar dan moeten zij ook echt wel iets heel raars doen. 

Misschien zijn de twee problemen gerelateerd. Laat de tijdelijke uitval van de verbinding nog sporen achter in de pfsense logs, zoals opnieuw opbouwen van de PPPoE verbinding?

Ik had hetzelfde probleem. Ik zie dat je MTU op 1492 staat. Bij mij staat dit op 1500.
En MSS inderdaad op 1492. Bij mij lijkt de verbinding nu stabiel voor 24 uur