Regelmatig geen interenet met PFSENSE

Hallo,

Na een tijdje relatieve rust, begon iets meer dan een half jaartje geleden mijn pfsense router te sputteren; zo af en toe was ie de verbinding kwijt. Ik kreeg een tip om de router 1x per week een reset te geven, want ondanks dat dat niet zou hoeven…

Dat ging een paar maanden goed, totdat ie vaker de verbinding verloor. De reset naar dagelijks gezet en dat werkte ook weer een tijdje. Nu heb ik er dagen bij dat ik de router ook nog 2x handmatig moet resetten (maar ook dagen dat het wel goed gaat). Ik heb zelfs een klikaanklikuit-schakelaar achter gezet, zodat ik van mijn kantoor op zolder de router kan resetten die beneden staat.

Heel soms kan ik nog inloggen op de router en dan is het enige wat ik zie, dat er geen WAN-connectie is. Meestal is de router helemaal vastgelopen en kan ik niet meer inloggen en is resetten de enige optie.

Iemand tips om dit te voorkomen, of logs die nog te bekijken zijn of settings om na te lopen?

Alvast dank iig :slight_smile:

Dit lijkt meer op problemen op de router zelf.
Als na reboot het weer even werkt en het steeds vaker steeds korter is dan lijkt dit op een volgelopen/vollopend filesysteem.

Ik zou proberen aan te logge met SSH en eens kijken of de log ruimte oid volgelopen is.
Mogelijk ook naar je log opties kijken of dat niet krapper moet. (DEBUG logging uit bv.). Minder oude logs bewaren, packet capture opties
uitzetten etc.

Als een filesysteem vol is dan dan kan de applicatie die de login moet doen ook niets meer loggen en zal na enige tijd ook wachten.
Vaak wordt er bij reboot een oude log verwijderd of krijg je ruimte omdat ook de disk administratie niet bij gehouden kon worden en de repair-disk wat ruimte vrijmaakt.
Op enig moment gaat het aanloggen ook niet meer lukken.

Handig is om de router te rebooten en zonder dat die nog ander werk kan doen (LAN afkoppelen), direct met een laptop aan de router aan te loggen.

Kijk ook naar de hoeveelheid applicaties die je erbij gezet hebt.

Hi Noci,

Het is niet dat ie steeds vaker en steeds korter vastloopt. Het is vrij willekeurig; Het kan vandaag 2x gebeuren dat ie vastloopt en dan maar zo een week niet.

De logging staat op standaard. Er is 5 M in gebruik en pfsense geeft aan dat in “Worst case disk usage” 58M gebruikt zal worden. De ruimte die nog over voor de logs is 204G

Het aanloggen met scherm en toetsenbord op de router zelf heb ik ook geprobeerd, maar als ik niet kan inloggen via de gui, kon ik de keren dat ik het probeerde ook niet meer bij de router zelf. Harde reset was het enige wat dan mogelijk was.

Ik heb 3 packages geïnstalleerd; OpenVPN client export, WireGuard VPN en Cron (voor de resets)
Nu moet ik zeggen dat ik al wel vaker aan WireGuard getwijfeld heb, maar een kennis van mij heeft ook WireGuard, maar die heeft deze problemen niet.
Ik raak met mijn iPhone bijv regelmatig mijn internetverbinding kwijt met WireGuard en dan moet ik de app uitzetten en weer aanzetten en dan doet ie het weer voor een aantal uur. Met mijn laptop heb ik dat probleem weer niet. Daar kan ik een hele dag met WireGuard werken zonder ook maar 1x de verbinding te verliezen.

Telefonie werkt heel vaak met CGNAT. Het is dan van belang de keep alive timer onder rond 120-180 seconden te houden.
Ander vervalt idd te tunnel. Die kan dan uitsltuitend vanaf de telefoon herstart worden. (Op Android heeft wireguard daar een optie voor).
(Het staat bij de VPN instellingen van Android, only access the internet using VPN tunnel.)
Ook de VPN instelling kan schelen. Ik gebruik wireguard continue. ALLE data vanaf mobiele apparatuur loopt via Wireguard tunnel via mijn thuis adres.
(Op die manier kan ik dus ook een HomeAssistant en andere apparaten in een internet loos LAN gebruiken).
De omschakeling van Wifi → LTE → Wifi → LTE… gaat wel eens mis, maar dat is een maal per paar weken.

Dank voor de tip m.b.t. wireguard! Gelijk ingesteld en kijken of het wat gaat schelen.

Net de router weer een reset moeten geven na 4 dagen up-time. Niks geks in de logging en weer onbereikbaar nadat het vastloopt. Ook niks op het interne netwerk is dan bereikbaar.
Het lijkt alsof de router vastloopt om de een of andere reden. Kan dit een extern proces zijn en is dat vast te stellen?

Het kan natuurlijk ook de hardware van de router zijn icm pfsense niet lekker loopt.
Wellicht een identieke nuc er bij kopen en daar opensense op zetten. Kijken of dat beter gaat.

Kun je een beeldscherm aansluiten op je router? Mogelijk dat daar nog wat verschijnt. Als de router een seriele poort heeft dan zou ook daar een melding kunnen komen.
Routers kunnen vrij slecht omgaan met meory gebrek, mogelijk dat regelmatig checken of memory free voldoende hoog blijft een hint kan geven.

Een beeldscherm heb ik al wel vaker geprobeerd, maar soms kun je inloggen, maar meestal niet.

Vandaag had ik ‘geluk’; De router liep 2x vast en de 2e keer (zojuist) kon ik na een paar pogingen inloggen. Het lokale netwerk was beschikbaar, behalve de WAN. die gaf “n/a” aan, met een rode pijl naar beneden.

Ik ben gelijk de logs doorgegaan in pfsense en de enige die ik tegenkwam was de volgende meldingen:

Jul 22 23:06:23 dpinger 27558 WAN_PPPOE 185.93.175.232: sendto error: 65

Een reboot gedaan, maar daarna nog steeds geen WAN. Na een minuut of wat (5+) ineens weer WAN.
Ik word er gestoord van.

Volgens:
https://people.freebsd.org/~glebius/trace_errors/errno.h

betekent 65: no route to host…

Dus waarschijnlijk iets mis met de interface of er is geen default gw ingesteld oid.
als het na 5 minuten weer werkt zit je ergens met timeouts die eerst moeten verlopen voor je verder kan.
Ik bedoelde niet een laptop gebruiken om aan te loggen… maar een fysiek beeldscherm op de console (video) poort, dat laat soms live zien wat er gebeurt en evt. mis gaat.

De interface instellingen zijn de eerste verdachte, misschien nog eens goed naar de WAN interface instellingen kijken.
(zet evt. 2e WAN poort uit).
Kan ook een defecte WAN poort zijn, of een switch (poort waarop de WAN aangesloten is) die niet lekker werkt.
Of de communicatie met upstream werkt niet lekker door verstoorde signalen op de kabel.

Het probleem zoals je dat omschrijft herken ik vanuit OpnSense.
En wordt ook op het OpnSense forum besproken:
[Crashes when reconnecting PPPoE repeatedly]
Het is tenslotte FreeBSD en PPPoE !

Er wordt een relatie gelegt naar de combinatie PPPoE en IPv6.

Ik heb op mijn OpnSense systeem IPv6 afgevinkt, en daarna 4 weken lang geen enkel probleem meer gehad.
Na die tijd vond ik het welletjes, ik wilde gewoon IPv6 gebruiken.

Ik ben dus nu een tevreden Mikrotik RB5009 gebruiker.

Als jij ook IPv6 gebruikt is het de moeite van het proberen waard om IPv6 even uit te schakelen en een paar weken af wachten…

Als je goed leest is het niet een relatie tussen PPPoE en IPv6 maar IPv6 en interface restart (op welke manier dan ook).
Het lijkt erop dat bij shutdown van een interface er en race condition is met een eventueel in transit zijnd IPv6 bericht.
Er zou een cron script zijn at PPPoE regelmatig herstart… die uitzetten kan ook helpen.

Hier heeft iemand een script die bij interface stop/start eerst IPv6 afsluit. (uit artikel), is is er bij interface shutdown geen live packet.

Die 5 minuten was na de reboot. Als ik niks doe, komt de verbinding ook niet terug. Na een reboot is de verbinding er meestal ook direct, maar dit keer dus niet.
Als de verbinding er is, dan kan het een paar uur later weer mis zijn, maar het kan ook een aantal dagen duren. Ik heb de instellingen voor Freedom nagelopen en die zijn zoals de voorbeelden hier op het forum; dat zou dus moeten werken.

Ik heb geen 2e WAN-poort dus dat is makkelijk :slight_smile: Ik kan mij niet voorstellen dat de WAN-poort, maar het zou theoretisch kunnen. Ik kan er niet veel aan wijzigen, want het is een op het moederbord ingebouwde ethernetpoort.
Er zit geen switch oid tussen de router en de aansluiting; De router staat naast de glas-connector.

Wellicht is het het beste om de hele klerezooi maar weer een keer opnieuw in te richten of pfsense weg te gooien voor iets anders/beters wat wel net zo flexibel is…

Mijn IPv6 staat uit, omdat ik dat in het begin niet aan de praat kreeg en tot nu toe geen zin had om het in te richten. Zolang het nu nog niet foutloos werkt, begin ik er ook nog maar niet aan :slight_smile:

Vandaag weer eens een vastloper en nu ben ik niet thuis, wat voor een andere dynamiek zorgt.
de router staat aan, maar geef geen sjoege. Thuis is het niet te benaderen en van buiten geeft een ping een time-out.
Lees ook op andere fora dat PPoE icm pfsense/FreeBSD nog wel eens voor problemen zorgt; zeker bij snelheden vanafde 1Gb

Ben er wel een beetje klaar mee. Denk dat ik maar eens ga kijken of ik pfsense achter een ‘standaard’ router ga hangen. Dan kan ik pfsense in de DMZ zetten of desnoods gewoon er achter koppelen en dan loopt het verkeer via DHCP ipv PPPoE. Dan ligt het beheer van de verbinding bij de provider en van het thuisnetwerk bij mij :slight_smile:

Had je OPNsense al wel geprobeerd? Ik gebruik opnsense zelf zonder problemen met ipv4 en ipv6

Nee nog niet geprobeerd. Dat kan ik nog wel even proberen binnenkort.
Zijn het dezelfde instellingen voor de WAN verbinding als pfSense?

Ik heb het destijds ingesteld met de uitleg op het forum van freedominternet wat gebaseerd was op pfsense. Het kwam grotendeels overeen. Later kwam ik deze uitleg tegen en heb ik het geoptimaliseerd voor mtu 1500.:

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

(ik heb nu via test https://www.speedguide.net/analyzer.php een mtu van 1500 MTU is fully optimized for broadband zichtbaar)

Dank!

Ik zie net op tweakers dat voor de kpn (waar freedom op draait, hele andere waarden voor mtu;
kpn-mtu

Zit hier een logica in?

misschien heeft het te maken met als je en TV en internet hebt? Ik gebruik zelf alleen internet van freedom. tv doe ik via NLziet.

Dit is het bij mij:

wederom dank!

Ik weet waar ik de komende dagen mee bezig zal gaan :slight_smile:

1 like

PPPoE de inhoud van pakketten zoals je die wil hebbn op je ethernet. (zonder evt. opdelen van pakketten te veroorzaken). (=1500)
PPP protocol heeft 8 bytes nodig als extra header. dus Ethernet interface zou 1500+8 = 1508 worden.

De 1512 is vermoedelijk een gedachte fout omdat dit op zich niet specificeerbaar is. een VLAN tag kost 4 bytes extra… maar dat is in de ethernet adapter al geregeld.
de MTU op de ethernet interface waar het VLAN over binnenkomt moet gewoon de basis lengte hebben (hier 1508, bij native ethernet 1500). omdat dat alleen over de untagged packets gaat.
Op adapter configuratie niveay zijn TAGS transparant.