Probleem met eigen PPPoE sessie in combinatie met UDP trafiek?

[33Fraise33]

Ik heb al sinds enige tijd een Mikrotik 4011 thuis staan die voor mij de PPPoE sessie afhandelt. De reden dat ik dit doe is omdat ik verschillende vlans heb voor docker containers, access netwerk en management netwerk.

Echter zit ik al enige tijd met een probleem die zich iedere keer in een andere vorm toont. Ik heb al een hele tijd problemen met NTP in combinatie met de PPPoE sessie. Mijn computers in het netwerk maar ook mijn mikrotik zelf kunnen geen time sync binnen halen via ntp. Na heel wat zoeken heb ik gevonden dat ik de PPPoE van de fritzbox ook aanzet en dan al mijn pc's ntp laat syncen met de fritzbox ipv het internet.

Dit probleem doet zich al enkele maanden voor. Daarna had ik echter een probleem dat ik in een bepaalde game met bepaalde game servers wel kon verbinden op bepaalde udp poorten en andere dan weer net niet. Wanneer ik dit test over 4G of rechtstreeks achter de fritzbox ipv via mijn eigen PPPoE sessie is er geen probleem.

Als laatste heb ik enkele dagen geleden een probleem gehad bij het aanvragen van een wildcard certificaat via de lego bot. Deze doet een DNS challenge en stelt een dns record in. Echter krijg ik de volgende timeout:

Code: Selecteer alles

acme: error presenting token: cloudflare: could not find the start of authority for _acme-challenge.domain.tld.: read udp 172.16.50.12:42312->173.245.58.205:53: i/o timeout

Na heel wat proberen heb ik de pppoe op mijn mikrotik even uitgezet en een dhcp client gezet op de interface richting de fritzbox met pppoe op de fritzbox en dit ging direct. Dus het moet wel ergens in mijn PPPoE sessie zitten lijkt het.

In bijlagen mijn PPPoE settings.
Ik heb al met de mtu gespeeld maar mijn MRU blijft altijd op 1492 staan wat ik ook instel. als ik alles default laat is mijn MTU 1480 en MRU 1492. Ik heb screenshots van collega's ontvangen die wel 1500MTU en MRU hebben. Echter krijg ik dit niet werkende, ook niet als ik mijn fysieke interface mtu van de interface naar de fritzbox verhoog.

Ik heb ook een ticket geopend bij EDPNet maar ik vrees dat dit een te vaag probleem is. Ik ga mogelijks nog kijken om eens een andere fritzbox te testen, mogelijks loopt er iets verkeerd bij de passthrough?

[Splitter]

zeker dat het niet eerder firewall rules zijn?

er is wel een kleine vage mogelijkheid dat de fritzbox inderdaad bepaalde packets dropt / fout forward (i have seen it happen...),
en dat kan je wel checken door wireshark e.d., maar ik zou beginnen met hetgene dat het meest waarschijnlijke is, en dat zijn dus settings en firewall rules.

[33Fraise33]

zeker dat het niet eerder firewall rules zijn?

Dit was mijn eerste goto, disablen van de firewall (buiten de srcnat) biedt geen oplossing

[33Fraise33]

zeker dat het niet eerder firewall rules zijn?

er is wel een kleine vage mogelijkheid dat de fritzbox inderdaad bepaalde packets dropt / fout forward (i have seen it happen...),
en dat kan je wel checken door wireshark e.d., maar ik zou beginnen met hetgene dat het meest waarschijnlijke is, en dat zijn dus settings en firewall rules.

Dit was ook mijn eerste insteek, ik heb dan ook de firewall van mikrotik al volledig disabled (buiten de srcnat rule) om de ntp en dns challenge te testen. Echter biedt dit geen oplossing. Verder werkt het dus wel met een dhcp client via de fritzbox maar wel met de zelfde firewall rules, de enige wijziging op dat moment is dat ipv PPPoE op de router er gebruik gemaakt wordt van double nat met PPPoE op de fritzbox.

[philippe_d]

er is wel een kleine vage mogelijkheid dat de fritzbox inderdaad bepaalde packets dropt / fout forward (i have seen it happen...),

Dat kan ik mij moeilijk voorstellen. Bij PPoE passtrough is de Fritzbox voor de achterliggende router een domme modem, en komt in principe niet tussen voor de verbinding?

[Garpenlov]

Ik had hetzelfde voor met NTP

Edpnet met eigen PPPoe sessie op een Edgerouter.

Ik had het echter opgelost met een firewall rule.

[Splitter]

er is wel een kleine vage mogelijkheid dat de fritzbox inderdaad bepaalde packets dropt / fout forward (i have seen it happen...),

Dat kan ik mij moeilijk voorstellen. Bij PPoE passtrough is de Fritzbox voor de achterliggende router een domme modem, en komt in principe niet tussen voor de verbinding?

moeilijk voor te stellen is 1 ding, het effectief meemaken een ander
we hebben het bij 1 klant gehad waar er problemen waren met udp packets voor het alarm, en ik durf niet meer exact te zeggen wat voor vervorming de fritzbox veroorzaakte, maar je kon het effectief zien dat er daar wat foutliep.
(ik geloof dat inkomende packets foutief doorgestuurd werden naar de router die de pppoe deed)

het is echter absoluut eentje onder het motto van have to see it to believe it.

[GuntherDW]

Ik doe hetzelfde hier. RB750Gr3 (hex) die pppoe doet e.d.
Ook ipv6 enabled et al. (Geen pppoe op de FB)

Merk eigenlijk geen problemen met udp of ntp of wat dan ook. Niet over IPv4 of v6. Ik denk dus inderdaad dat het eerder in je netwerk zelf ligt ergens. Of edpnet filtert ergen iets fout maar daarvoor vind je spijtig genoeg idd geen soelaas bij de helpdesk.

Inkomend zijn er wel enkele poorten gefiltered maar uitgaand normaal niet.

Je FB draait de laatste (goedgekeurde) versie? Over welke FB en firmware praten we?
Qua mtu draai ik idd op 1492 gezien er geen baby jumbo frame support is.

Gezien ik atm niet thuis ben even ter verificatie over vpn op mn telefoon.

[33Fraise33]

Ja ik doe niet echt speciale zaken qua firewalling of dergelijke, om zeker te zijn zet ik dit dan uit om te testen maar dit lijkt dus geen oplossing te bieden. Ik heb het gevoel dat het ergens aan de MTU ligt maar ik zie niet waarom precies.

De andere optie is dat de fritzbox iets raar doet. Ik zou graag een ander model eens testen maar er waren geen meer beschikbaar op het werk.

er is wel een kleine vage mogelijkheid dat de fritzbox inderdaad bepaalde packets dropt / fout forward (i have seen it happen...),

Dat kan ik mij moeilijk voorstellen. Bij PPoE passtrough is de Fritzbox voor de achterliggende router een domme modem, en komt in principe niet tussen voor de verbinding?

moeilijk voor te stellen is 1 ding, het effectief meemaken een ander
we hebben het bij 1 klant gehad waar er problemen waren met udp packets voor het alarm, en ik durf niet meer exact te zeggen wat voor vervorming de fritzbox veroorzaakte, maar je kon het effectief zien dat er daar wat foutliep.
(ik geloof dat inkomende packets foutief doorgestuurd werden naar de router die de pppoe deed)

het is echter absoluut eentje onder het motto van have to see it to believe it.

Dit is echter wel interessant, hoe zou ik dit best nagaan, alles afsluiten van netwerk, laptop aanhangen en ntp request doen en packet capture op mikrotik doen?

[Splitter]

wij hebben het destijds bij die klant vastgesteld door packet capture te doen rechtstreeks op de edgerouter op de pppoe interface.
gebruikmakende van tcpdump en conntrack en daar effectief gefilterd op udp en poort, en door al het verkeer heen zo kunnen vaststellen dat de packets effectief corrupt binnenkwamen.
het helpt natuurlijk wel als je niks anders aansluit, in ons geval ging dat niet maar wisten we gelukkig wel wat het exact te verwachten packet was in beide richtingen.
het hoe of waarom heb ik nog steeds geen antwoord op... en denk niet dat ik dat ooit ga vinden.
(en tegen de tijd dat we het gevonden hadden, was mijn zin om nog te willen weten hoe of waarom ook redelijk voorbij, eerlijk gezegd)

[33Fraise33]

Ik ben netwerkengineer overdag maar ik moet zeggen dat dit wel een probleem is waarbij mijn zin ook snel verdwijnt. Ik heb hier al avonden aan verprutst in de hoop iets dom te vinden maar dat lijkt het niet te zijn. Ik host heel wat zaken thuis en het publiek ip op mijn router is dan wel echt handig. Ofwel moet ik kijken om de mikrotik in DMZ te plaatsen en de Fritzbox de PPPoE te laten afwerken

[Joachim]

Check anders even: http://fritz.box/support.lua hier kan je wireshark dumps genereren voor interfaces van je fritzbox. Of een draytek kopen?

[Splitter]

Check anders even: http://fritz.box/support.lua

kan je die ook gebruiken indien je in passthrough staat en er geen pppoe draait op de fritz?

Of een draytek kopen?

draytek is toch niet certified? dus dan zou je op een repairprofiel komen en dat is nu ook niet bepaald een toffe snelheid...
bij onze klant was het trouwens domweg opgelost door de fritzbox te swappen.

[Joachim]

Check anders even: http://fritz.box/support.lua

kan je die ook gebruiken indien je in passthrough staat en er geen pppoe draait op de fritz?

Of een draytek kopen?

draytek is toch niet certified? dus dan zou je op een repairprofiel komen en dat is nu ook niet bepaald een toffe snelheid...
bij onze klant was het trouwens domweg opgelost door de fritzbox te swappen.

Dat eerste heb ik nog niet geprobeerd, maar de moeite waard om het even te testen
We hebben reeds een jaar ofzo de draytek laten certificeren. Zie ook:
https://www.edpnet.be/nl/support/bestel ... uiken.html

[33Fraise33]

Ik heb alles kunnen oplossen "the ugly way" mijn ddns client draait nog altijd op mijn mikrotik maar pppoe doet de fritzbox nu. Deze geeft alles door aan mijn mikrotik via de "exposed host" functie op de fritzbox.

Niet optimaal dit maar alles werkt nu wel perfect, firewalling en port forwarding is nog steeds op de mikrotik en mijn vlans werken zo dus ook nog.

Ik kijk mogelijks nog eens naar een andere client die de PPPoE sessie kan termineren of ik daar de problemen ook mee zie. (RPI of dergelijke)

[Uloga]

Inderdaad zelfde probleem hier, ik kan geen NTP krijgen op m'n Mikrotik CCR1009-8G-1S die de PPPoE sessie opbouwt.

Wanneer ik NTP ophaal van de fritzbox, dan lukt dat wel.

[GuntherDW]

Kijk die "dst address" e.d. eens goed na.
Je mikrotik verwacht ook een antwoord terug op poort 123... welke een van de poorten is welke edpnet blokkeert op DynIP abbo's.

Je gaat dus inderdaad of wat dingen moeten aanpassen of een andere client gebruiken voor NTP.

Na het nalezen van de documentatie e.d. is het niet mogelijk om de port number op de MT zelf aan te passen, maar is er wel een workaround welke je kan gebruiken, namelijk een src-nat rule toevoegen in je NAT table welke die poort verandert naar een random andere poort.

Akkoord, het is nogal... vuil, maargoed, het werkt

Als je trouwens een "full fledged" NTP client wilt tegenover de SNTP client welke by default in je MT zit, moet je de extra packages van je router arch downloaden op MT hun download site.
https://mikrotik.com/download
In die extra zip zit dan ntp-{versie}-{arch}.npk welke je gewoon even moet uploaden naar je router en een reboot geven.

EDIT: Net deze geinstalleerd om te checken maar deze extra package zet ook z'n poort vast op 123 tenzij je dit met een src-nat rule omzeilt... goed bezig Mikrotik...

[Splitter]

Je mikrotik verwacht ook een antwoord terug op poort 123... welke een van de poorten is welke edpnet blokkeert op DynIP abbo's.

ik dacht dat edp geen poorten blokkeerde (behalve 25 uitgaand)?

net ook even op 1 van de routers bij een klant met een dyn edp abbo getest en daar werkt het ook gewoon.
poort denk ik dus niet dat geblokkeerd zal worden (setup is daar fritz in passthrough -> edgerouter)

[Joachim]

Op DYN IP's blokkeren we by default een boel poorten om misbruik (DDoS etc) tegen te gaan. Sommige poorten kan je vragen te openen via helpdesk. Bij FIX IP's wordt er niks geblokkeerd.

Een volledig overzicht:
Port / Description / Can it be ublocked
25 / SMTP / No
17 (UDP) / QOTD / Yes
19 (UDP) / Character Generator Protocol / No
53 / DNS / Yes
69 / TFTP / Yes
123 / NTP / Yes
161 / SNMP / Yes
1900 / UPnP / No

[33Fraise33]

Op DYN IP's blokkeren we by default een boel poorten om misbruik (DDoS etc) tegen te gaan. Sommige poorten kan je vragen te openen via helpdesk. Bij FIX IP's wordt er niks geblokkeerd.

Een volledig overzicht:
Port / Description / Can it be ublocked
25 / SMTP / No
17 (UDP) / QOTD / Yes
19 (UDP) / Character Generator Protocol / No
53 / DNS / Yes
69 / TFTP / Yes
123 / NTP / Yes
161 / SNMP / Yes
1900 / UPnP / No

Wat is de snelste manier om dit te testen, dien ik een ticket in of bel ik hier best voor?

[Joachim]

Wat is de snelste manier om dit te testen, dien ik een ticket in of bel ik hier best voor?

Er valt niks te testen, het is gewoon zo, als je een poort wil laten openen dan moet je idd een ticket openen.

[33Fraise33]

Je mikrotik verwacht ook een antwoord terug op poort 123... welke een van de poorten is welke edpnet blokkeert op DynIP abbo's.

ik dacht dat edp geen poorten blokkeerde (behalve 25 uitgaand)?

net ook even op 1 van de routers bij een klant met een dyn edp abbo getest en daar werkt het ook gewoon.
poort denk ik dus niet dat geblokkeerd zal worden (setup is daar fritz in passthrough -> edgerouter)

In passthrough lijkt het ook gewoon te werken, dus ik weet niet goed wat een eigen PPPoE sessie anders doet dan deze op de fritzbox

[GuntherDW]

poort denk ik dus niet dat geblokkeerd zal worden (setup is daar fritz in passthrough -> edgerouter)

De MT client stuurt niet enkel een NTP packet uitgaand op poort 123, maar verwacht ook z'n antwoord terug inkomend op poort 123.
daar zit het probleem. Als je dus een src-nat rule toevoegt op je MT kan je dat bypassen indien nodig.
Als je client een random port neemt zoals de meeste protocollen/clients wel doen zal je geen probleem zien.

Alsnog, Joachim, toen ik met m'n DNS issues zat/zit was het antwoord min of meer "pech" voor mij, en nu zeg je dat het potentieel unblocked kan worden...?
Dat zou me wel wat miserie bespaard hebben

[Joachim]

Alsnog, Joachim, toen ik met m'n DNS issues zat/zit was het antwoord min of meer "pech" voor mij, en nu zeg je dat het potentieel unblocked kan worden...?
Dat zou me wel wat miserie bespaard hebben

Da's een recente ontwikkeling, en jullie kunnen steeds naar mijn post verwijzen

[Garpenlov]

Zonet poort 123 laten unblocken, klokjes werken weer!
Lijkt me misschien wel iets om op jullie website te vermelden.

[Joachim]

Zonet poort 123 laten unblocken, klokjes werken weer!
Lijkt me misschien wel iets om op jullie website te vermelden.

Akkoord!

[Tomsworld]

Er zijn nog massa's ntp implementaties die symmetrisch udp:123 gebruiken. Die blocken is misschien niet de beste optie van Edpnet, rate limit lijkt me handiger.

[GuntherDW]

Zonet poort 123 laten unblocken, klokjes werken weer!

Mooi dat het zo snel ging, zal morgen ook eens een ticketje aanmaken denk ik dan .

EDIT: Trouwens je lijstje klopt niet 100% Joachim. DNS (53) wordt wel geblokkeerd, maar enkel over UDP.
TCP 53 (welke ook gebruik kan worden voor DNS indien de packet te groot wordt voor in 1 packet te passen) wordt niet blocked. Echter blijkt het uit je lijstje dat enkel TCP (of beiden) blocked zou zijn.

Ticket is ook de deur uit (2168496)

[GuntherDW]

Bij mij duurt het wat langer dan gedacht spijtig genoeg.

Er is vandaag (een 3u terug) reactie opgekomen dat de poorten open zouden moeten staan... maar dat is niet echt het geval.

123/UDP staat open zoals gevraagd, maar 53/UDP (dus DNS) lijkt nog intern ergens geblokkeerd te worden.
Dat wordt nog leuk uitzoeken geloof ik .

Heb wel 2 keer een PPPoE disconnect gezien. Dacht bij de 2de keer eens te kijken of het nu wel opgelost is, maar tevergeefs.
De eerste keer zat ik wel in de static range volgens de RDNS though... toeval?

EDIT: een dag later, deze ochtend nog eens gechecked en sure enough, m'n DNS queries komen zonder PPPoE reconnect nu wel door.
Hopen dat het nu wel blijft deze keer ipv na een tijdje "opeens" te stoppen .