[Gl.iNet routers] Ervaringen en discussie

[sweetdude]

snah001 schreef op woensdag 28 mei 2025 @ 16:22:
Heb een probleem (met KPN glas) met port 53.
Die moet van KPN dicht staan en met een firewall rule deze ook dichtgezet.
Maar als je Adguard Home de client requests laat afhandelen dan wordt die weer open gezet en dat mag van KPN niet dus het volgende verhaal is van toepassing:

Wanneer port 53 wordt opengezet?
Dat gebeurt als je de op de router draaiende Adguard Home de client requests laat afhandelen.
Adguard home is afhankelijk van port 53 en als je die requests door de router zelf laat afhandelen dan wordt port 53 niet gebruikt maar dan werkt de adblock in Adguard ook niet meer.
Nu een oplossing vinden dat Adguard op de router een andere poort voor listening gaat gebruiken.
Dus wie een goede oplossing heeft, ik hoor hem graag.

Maar poort 53 is toch DNS verkeer. Ik snap dat ze vanuit veiligheidsoverwegingen poort 53 dicht zetten zodat je zelf geen DNS server kan draaien.
Maar je Adguard Home (of pihole die doet hetzelfde) kan toch gewoon via poort 53 zijn requests kunnen doen.

[duvekot]

snah001 schreef op woensdag 28 mei 2025 @ 16:22:
Heb een probleem (met KPN glas) met port 53.
Die moet van KPN dicht staan en met een firewall rule deze ook dichtgezet.
Maar als je Adguard Home de client requests laat afhandelen dan wordt die weer open gezet en dat mag van KPN niet dus het volgende verhaal is van toepassing:

Wanneer port 53 wordt opengezet?
Dat gebeurt als je de op de router draaiende Adguard Home de client requests laat afhandelen.
Adguard home is afhankelijk van port 53 en als je die requests door de router zelf laat afhandelen dan wordt port 53 niet gebruikt maar dan werkt de adblock in Adguard ook niet meer.
Nu een oplossing vinden dat Adguard op de router een andere poort voor listening gaat gebruiken.
Dus wie een goede oplossing heeft, ik hoor hem graag.

Maar die hoeft toch nooit extern open te staan? Toch alleen op het interne netwerk?

[snah001]

sweetdude schreef op woensdag 28 mei 2025 @ 17:03:
[...]

Maar poort 53 is toch DNS verkeer. Ik snap dat ze vanuit veiligheidsoverwegingen poort 53 dicht zetten zodat je zelf geen DNS server kan draaien.
Maar je Adguard Home (of pihole die doet hetzelfde) kan toch gewoon via poort 53 zijn requests kunnen doen.

Het zijn niet de request maar de poort wordt door Adguard gebruikt om inkomend verkeer (listening port) te monitoren.
Sla mij maar dood waarom dat persé port 53 moet zijn.
KPN wil gewoon dat die port van buitenaf dicht staat.

[stormfly]

@duvekot er is wat verwarring bij @snah001 ik haak even aan vanuit het KPN topic. Volgens mij heeft hij niet goed door dat het probleem zit in het WAN gedeelte en dat KPN abuse hem daar op aan heeft gesproken. Port 53 gebruiken met AdGuard op je router is prima, in je LAN maar niet op het WAN.

Ik vul het even goed bedoeld in:
@snah001 zijn vraag is: hoe hij met jullie als Gl.iNet experts een controle kan doen dat al zijn WAN porten dicht staan voor o.a. port 53?

Mijn vraag, waarom ik even mee kom neuzen ;-) Is het zo dat deze Gl.iNet router écht de porten aan de WAN zijde opent als je AdGuard start?

[Tom Paris]

stormfly schreef op woensdag 28 mei 2025 @ 17:28:
Mijn vraag, waarom ik even mee kom neuzen ;-) Is het zo dat deze Gl.iNet router écht de porten aan de WAN zijde opent als je AdGuard start?

GL.iNet = OpenWrt, en AdGuard is gewoon een OpenWrt package. Ook al zou AdGuard (of dnsmasq) ingesteld zijn om te reageren op DNS request op de WAN interface, zouden die request nooit aankomen tenzij er een firewall rule actief is die dit verkeer toelaat, of zones verkeerd aan elkaar geknoopt zijn. @snah001 is nu al 4x gevraagd de inhoud van /etc/config/network en /etc/config/firewall te posten om dat op te helderen, maar reageert daar niet op.

snah001 schreef op woensdag 28 mei 2025 @ 17:22:
[...]

Het zijn niet de request maar de poort wordt door Adguard gebruikt om inkomend verkeer (listening port) te monitoren.
Sla mij maar dood waarom dat persé port 53 moet zijn.
KPN wil gewoon dat die port van buitenaf dicht staat.

DNS is per definitie poort 53. Je kunt de listening port best veranderen, maar dan zullen je clients de DNS server niet meer kunnen vinden, en heb je effectief geen internetverbinding meer vanaf je clients.

De oplossing zit hier niet in de poort van de DNS server, maar in de firewall.

[ Voor 28% gewijzigd door Tom Paris op 28-05-2025 17:45 ]

[stormfly]

Tom Paris schreef op woensdag 28 mei 2025 @ 17:41:
[...]


GL.iNet = OpenWrt, en AdGuard is gewoon een OpenWrt package. Ook al zou AdGuard (of dnsmasq) ingesteld zijn om te reageren op DNS request op de WAN interface, zouden die request nooit aankomen tenzij er een firewall rule actief is die dit verkeer toelaat, of zones verkeerd aan elkaar geknoopt zijn. @snah001 is nu al 4x gevraagd de inhoud van /etc/config/network en /etc/config/firewall te posten om dat op te helderen, maar reageert daar niet op.

Helder verhaal config files zouden inzicht moeten geven.

[duvekot]

Ik neem aan dat @snah001 gebruik maakt van de standaard applicatie op zijn GL.Inet apparaat .. en dat het een ondersteunend apparaat is:

https://docs.gl-inet.com/...erface_guide/adguardhome/

[snah001]

Ik ga geen network of firewall files sharen omdat de router volkomen onaangetast is door wat dan ook behalve dat er gebruik wordt gemaakt van een Wireguard server en client.
Daarnaast draait onaangetast Adguard als OpenWrt package en daar is ook helemaal niets aan veranderd behalve regelmatige updates.
Ook een terugkeer naar fabrieksinstellingen en na her-instellen van de Wireguard services blijft het probleem.
Alles werkt ook gewoon en het is KPN die ineens begint te jammeren dat port 53 niet dicht staat.
Providers Ziggo en Odido heb ik daar nog nooit over gehoord.
Echter Adguard gebruikt juist die 53 als listening port als Adguard actief is.
Als de Adguard setting "Adguard Home handle client requests" actief is dan is ineens port 53 open en dat is dus het probleem.
De vraag is hoe dat te veranderen want met die functie inactief blocked Adguard niks meer, wellicht moet ik daar iets binnen Adguard voor aanpassen.
Op het web zie ik daar meer vragen over omdat bijvoorbeeld een andere service al van port 53 gebruik maakt en ze aan Adguard een andere port willen toewijzen.
Tot nog toe geen oplossing gevonden.

[duvekot]

snah001 schreef op woensdag 28 mei 2025 @ 21:11:
Ik ga geen network of firewall files sharen omdat de router volkomen onaangetast is door wat dan ook behalve dat er gebruik wordt gemaakt van een Wireguard server en client.
Daarnaast draait onaangetast Adguard als OpenWrt package en daar is ook helemaal niets aan veranderd behalve regelmatige updates.
Ook een terugkeer naar fabrieksinstellingen en na her-instellen van de Wireguard services blijft het probleem.
Alles werkt ook gewoon en het is KPN die ineens begint te jammeren dat port 53 niet dicht staat.
Providers Ziggo en Odido heb ik daar nog nooit over gehoord.
Echter Adguard gebruikt juist die 53 als listening port als Adguard actief is.
Als de Adguard setting "Adguard Home handle client requests" actief is dan is ineens port 53 open en dat is dus het probleem.
De vraag is hoe dat te veranderen want met die functie inactief blocked Adguard niks meer, wellicht moet ik daar iets binnen Adguard voor aanpassen.
Op het web zie ik daar meer vragen over omdat bijvoorbeeld een andere service al van port 53 gebruik maakt en ze aan Adguard een andere port willen toewijzen.
Tot nog toe geen oplossing gevonden.

Dus eigenlijk zeg je . In een default configuratie van een standaard Gl.Inet apparaat met AdGuard actief staat port 53 open op de WAN aansluiting? (Als je die "AdGuard Home Handle Client Requests" optie aan zet)

En je had dat ook zelf geconstateerd door een externe portscan te laten doen op je externe IPv4 adres? (Dus echt van buitenaf, en niet door KPN dus)

Want dan vind ik dat een bug van de standaard GL.Inet oplossing.

[snah001]

By the way: de enige wijziging die ik handmatig heb aangebracht in de firewall rules is deze.
Dat wordt op het web op diverse plaatsen aangeraden om via de firewall rules die poort dicht te zetten en deze rule helemaal bovenaan te zetten zodat die als 1ste wordt uitgevoerd.

[snah001]

duvekot schreef op woensdag 28 mei 2025 @ 21:31:
[...]

Dus eigenlijk zeg je . In een default configuratie van een standaard Gl.Inet apparaat met AdGuard actief staat port 53 open op de WAN aansluiting? (Als je die "AdGuard Home Handle Client Requests" optie aan zet)

En je had dat ook zelf geconstateerd door een externe portscan te laten doen op je externe IPv4 adres? (Dus echt van buitenaf, en niet door KPN dus)

Want dan vind ik dat een bug van de standaard GL.Inet oplossing.

Precies dit.
Vanaf een ander device buiten het netwerk van bijvoorbeeld het mobiele Odido netwerk geeft ie aan zo gauw als die setting actief is dat de poort open staat.
Setting op inactief en dan staat de poort dicht.
Ik heb daar zoals gezegd geen problemen mee maar KPN stuurt dan emails en daarna blokkeren ze de ethernet verbinding omdat ZIJ dat niet willen.

[synoniem]

Ik ken je configuratie niet maar als ik het goed herinner kan je bij Adguard instellen welke interface(s) gekoppeld wordt/worden. Dus je lokale subnet en niet 0.0.0.0 waarmee je ook je WAN port koppelt.

[duvekot]

snah001 schreef op woensdag 28 mei 2025 @ 21:39:
[...]

Precies dit.
Vanaf een ander device buiten het netwerk van bijvoorbeeld het mobiele Odido netwerk geeft ie aan zo gauw als die setting actief is dat de poort open staat.
Setting op inactief en dan staat de poort dicht.
Ik heb daar zoals gezegd geen problemen mee maar KPN stuurt dan emails en daarna blokkeren ze de ethernet verbinding omdat ZIJ dat niet willen.

Je draait op de allerlaatste versie van de GL.inet firmware voor je router? .. ik lees op het forum wel oudere posts waarin dat gemeld wordt .. maar dat zou opgelost zijn.

Dus ja...dat is een bug .. en zou niet moeten voorkomen.

[snah001]

duvekot schreef op woensdag 28 mei 2025 @ 22:10:
[...]

Je draait op de allerlaatste versie van de GL.inet firmware voor je router? .. ik lees op het forum wel oudere posts waarin dat gemeld wordt .. maar dat zou opgelost zijn.

Dus ja...dat is een bug .. en zou niet moeten voorkomen.

Draai al vanwege dit sinds gisteren op de 4.8.0 beta versie maar maakt niks uit.
Ga het morgen ook bij GL.iNet melden.
Die zijn altijd heel behulpzaam en snel met antwoorden.

[duvekot]

snah001 schreef op woensdag 28 mei 2025 @ 22:25:
[...]

Draai al vanwege dit sinds gisteren op de 3.8.0 beta versie maar maakt niks uit.
Ga het morgen ook bij GL.iNet melden.
Die zijn altijd heel behulpzaam en snel met antwoorden.

Niet over naar een versie 4? Welk apparaat gebruik je?

[snah001]

duvekot schreef op woensdag 28 mei 2025 @ 22:40:
[...]

Niet over naar een versie 4? Welk apparaat gebruik je?

Is een typo, moet zijn 4.8.0.

[snah001]

Afgelopen woensdag het probleem met port 53 voorgelegd op het speciale forum bij GL.iNet hiervoor in het topic Firmware update MT6000 V4.8.0..
Vandaag antwoord op gekregen, ze hebben op de 23ste, na mijn verhaal de firmware al aangepast en het is met V4.8.0. date 23-05-2025 opgelost.
Deze vandaag geflashed en inderdaad het probleem met het ongewild openzetten van port 53 is verdwenen.
Ook het probleem als je "AdGuard Home Handle Client Requests" uit zet dat dan niks geblocked wordt is verholpen.
Perfecte service van GL.iNet!