Zelfbouw project: Firewall / Router / AP

[barrymossel]

Jerie schreef op zondag 2 maart 2025 @ 11:33:
[...]


Of je koopt een gl.inet router (Chinees spul) waar OpenWrt op draait. Bijvoorbeeld de Mudi. Dan nog een Raspberry Pi met Home Assistent en je bent klaar.

Dat was het eerste idee, maar de routers met 4G zijn alweer een stukje meer aan de prijs. En ik heb ook geen geschikte RPi meet liggen. Een NUC wel. En als dit werkend is te krijgen, dan zou ik maar 1 device nodig hebben... En hoef ik alleen een Zigbee dongle en USB modem aan te schaffen.

[barrymossel]

duvekot schreef op zondag 2 maart 2025 @ 11:34:
[...]

Stroom gebruik ... Een continue draaiende PC in de camper kost redelijk wat stroom. Is dat stroom gebruik het waard voor het gemak? Heb je echt Proxmox nodig? Kan je niet met een simpele RPi beginnen? Hoe ga je om met "shutdowns" als de stroom op is? Kan je rechtstreeks vanaf 12V eea van stroom voorzien ? Of moet je omvormer dan altijd aanstaan (met omzetting verlies) etc etc.
Dus kijk vooral naar hoe je eea het zuinigst kan maken. Een eigen "camper lan" kan natuurlijk wel heel handig zijn .. en zeker als je daardoor flexibel bent met je internet ontsluiting etc. Maar let dus goed op verbruik ...heb je bijvoorbeeld zonnepanelen om de accu opgeladen te houden? Ook bij gestegen verbruik? Gaat eea uit als je weg loopt van de camper? Of in deep sleep modus ..

(Voldoende sanity check vragen zo? )

Het gaat om een vouwwagen met een vaste elektra aansluiting...

[Jerie]

tuxie6 schreef op zondag 2 maart 2025 @ 11:34:
Makkelijk aan en uit te zetten?
Wat gebeurt er bij stroomstoring, disk corrupt, tools mee om te repareren.
ik zou eerder denken aan een laptopje, alles in 1 om te kunnen prutsen.

Dit is een goed punt.

Om dat te voorkomen heb je diverse opties.

1) Read-only filesystem.

2) Industrial grade microSD kaartjes

3) Een batterij, zoals https://hackaday.io/project/173847-ups-lite

[barrymossel]

tuxie6 schreef op zondag 2 maart 2025 @ 11:34:
Makkelijk aan en uit te zetten?
Wat gebeurt er bij stroomstoring, disk corrupt, tools mee om te repareren.
ik zou eerder denken aan een laptopje, alles in 1 om te kunnen prutsen.

Stroomstoring is een goeie. Kan me goed voorstellen dat dat een issue kan zijn op een camping. Daar ga ik nog even over nadenken. Want een spare laptop heb ik ook niet liggen...

[Jerie]

barrymossel schreef op zondag 2 maart 2025 @ 11:40:
[...]

Stroomstoring is een goeie. Kan me goed voorstellen dat dat een issue kan zijn op een camping. Daar ga ik nog even over nadenken. Want een spare laptop heb ik ook niet liggen...

Tweedehands kosten ze nagenoeg niets. Je hebt ook meteen een scherm en batterij erbij.

[Tom Paris]

barrymossel schreef op zondag 2 maart 2025 @ 11:25:
Wifi via ingebouwde wifi, of eventueel switch met AP?

*sense gebruiken voor WiFi is een slecht idee, de hardware support in FreeBSD is zeer beperkt. Je kunt beter een OpenWrt VM gebruiken. Maar ook dan, de meeste NUCs hebben een Intel WiFi adapter, en die kunnen niet in AP mode. Praktisch gezien zit je dus altijd vast aan een los AP als je het bij de NUC houdt.

Ik zou een OpenWrt device kopen met USB 5G modem, dat is een stuk goedkoper dan een device met ingebouwd modem. En dan een Pi-achtige machine voor HA. Of je installeert HA als Docker container op OpenWrt.

[barrymossel]

Tom Paris schreef op zondag 2 maart 2025 @ 14:39:
[...]


*sense gebruiken voor WiFi is een slecht idee, de hardware support in FreeBSD is zeer beperkt. Je kunt beter een OpenWrt VM gebruiken. Maar ook dan, de meeste NUCs hebben een Intel WiFi adapter, en die kunnen niet in AP mode. Praktisch gezien zit je dus altijd vast aan een los AP als je het bij de NUC houdt.

Het was mooi geweest als het met 1 device in het geheel had gekund.

Ik zou een OpenWrt device kopen met USB 5G modem, dat is een stuk goedkoper dan een device met ingebouwd modem. En dan een Pi-achtige machine voor HA. Of je installeert HA als Docker container op OpenWrt.

Dan kan ik misschien zelfs nog beter gaan voor een OpenWrt met 4G/5G ingebouwd. Overigens zijn die 5G modems wel érg duur...

Even back to the drawing board...

[Jerie]

barrymossel schreef op zondag 2 maart 2025 @ 14:51:
[...]

Het was mooi geweest als het met 1 device in het geheel had gekund.

[...]

Dan kan ik misschien zelfs nog beter gaan voor een OpenWrt met 4G/5G ingebouwd. Overigens zijn die 5G modems wel érg duur...

Even back to the drawing board...

Ik zou niet per definitie voor USB gaan maar voor iets met deze modem https://www.quectel.com/product-selector/ bijvoorbeeld Quectel EC25. Die wordt goed ondersteunt en is FOSS. Zit ook in de Mudi.

Bij de Mudi heb je dus 150 mbit down, 50 mbit up, WLAN, OpenWrt (bijvoorbeeld Wireguard VPN), batterij (helaas niet user serviceable), microSD, status schermpje, killswitch, lader, en zelfs een USB naar ethernet splitter voor je andere device. Waarbij een Raspberry Pico misschien ook wel genoeg is voor Home Assistant. Misschien draait het zelfs op de Mudi (en misschien zijn er ook wel andere alternatieven dan de Mudi).

Wat je ook nog zou kunnen doen is je smartphone met wifi tethering aanzetten. Dan kan je Raspberry daarmee verbinden. Al zou ik persoonlijk zoveel mogelijk wired gaan. Veiliger, minder issues.

[ Voor 4% gewijzigd door Jerie op 02-03-2025 15:03 ]

[duvekot]

barrymossel schreef op zondag 2 maart 2025 @ 14:51:
[...]

Het was mooi geweest als het met 1 device in het geheel had gekund.

[...]

Dan kan ik misschien zelfs nog beter gaan voor een OpenWrt met 4G/5G ingebouwd. Overigens zijn die 5G modems wel érg duur...

Even back to the drawing board...

Als je toch iets wil rondom internet .. en als je ook nog rond trekt door Europa . Dan is er helaas niets op dit moment wat kan concurreren met Starlink. Kost je 72 Euro per maand (en te pauzeren per maand) plus eenmalig aanschaf van een antenne ( de mini is 279 ... inclusief ingebouwde wifi en dc voeding)

Ondanks dat Elon nu niet echt een prettig persoon is op dit moment .. is er gewoon niets wat er nu mee kan concurreren .. dat duurt nog wel een tijdje .. en dan is het Besos die als eerste waarschijnlijk wat heeft wat kan concurreren ... Of Chinees ..

Bij 5G zit je altijd vast aan de dekking en afstand vanaf de mast etc .. bij Starlink moet je alleen maar te zorgen voor een vrij zicht rondom naar boven.

[Yoshimi]

@RobertMe @Raven Aangezien jullie ook een Debian-gebaseerde router hebben, maken jullie misschien ook gebruik van een seriele kabel op de console poort van de router.
Wanneer ik met Terminal op Debian of Putty op Windows via de console kabel verbind, dan is het kader van de tekst die getoond wordt, eigenlijk maar super klein (1/4 van het scherm, als ik het vergroot). Ik heb al ge-Googled naar mogelijke oplossingen, maar nog geen passend antwoord gevonden. Misschien hebben jullie ervaring hoe dit aan te passen?

Waarom console toegang, als je SSH hebt, vraag je dan?
Ik heb afgelopen weekend na wat klooien besloten een nieuwe installatie te doen .
Omdat de tekst steeds afgekapt wordt, soms met >>> of gewoon een harde return, is dat niet prettig lees/werkbaar.

Vraag me af of dit nou een host-based (dus de router) of client-based (de laptop) instelling is...

[Raven]

@Yoshimi Ik gebruik SSH, Webmin en heb indien nodig een monitor met meerdere inputs en een USB-switch (zeg maar KVM-switch maar dan zonder het videodeel) om het systeem direct te kunnen bedienen. Plus ik kan er een JetKVM aan hangen dus seriële poort is niet nodig

Maar uhm, in Putty is het standaard 80 columns en 24 rows, dat kan je onder "Window" aanpassen, dit aan de client-zijde. Aan de router-pc zijde zou ik niet zo gauw weten wat te doen, heb wel eens zitten Googlen naar serial console en buiten

Bash:

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8"

kan ik niet herinneren ooit iets gelezen te hebben over aantal colums/rows.

[RobertMe]

Yoshimi schreef op donderdag 6 maart 2025 @ 18:25:
@RobertMe @Raven Aangezien jullie ook een Debian-gebaseerde router hebben, maken jullie misschien ook gebruik van een seriele kabel op de console poort van de router.
Wanneer ik met Terminal op Debian of Putty op Windows via de console kabel verbind, dan is het kader van de tekst die getoond wordt, eigenlijk maar super klein (1/4 van het scherm, als ik het vergroot). Ik heb al ge-Googled naar mogelijke oplossingen, maar nog geen passend antwoord gevonden. Misschien hebben jullie ervaring hoe dit aan te passen?

Waarom console toegang, als je SSH hebt, vraag je dan?
Ik heb afgelopen weekend na wat klooien besloten een nieuwe installatie te doen .
Omdat de tekst steeds afgekapt wordt, soms met >>> of gewoon een harde return, is dat niet prettig lees/werkbaar.

Vraag me af of dit nou een host-based (dus de router) of client-based (de laptop) instelling is...

Ik gebruik inderdaad heel zeldzaam de serial console.

Wat jii beschrijft lijkt mij puur neer te komen op dat de TTY die op de serial port draait "te klein is". En je dus de resolutie van die TTY wilt aanpassen. Hoe? Geen idee. Als je onder een GUI gewoon lokaal een (virtuele) terminal opent (bv Konsole onder KDE) dan doet die de onderliggende TTY wel netjes resizen. Maar over de serial console zal die vast die informatie niet ontvangen.

Oh, en ja, volgens mij is die ook bij mij maar 120 tekens breed of zo.

Edit:
Letterlijk het eerste DuckDuckGo resultaat geeft stty rows ... cols ... uitvoeren als antwoord. Dat resized die de console / terminal naar dat aantal rijen en kolommen.

[ Voor 5% gewijzigd door RobertMe op 06-03-2025 18:40 ]

[Yoshimi]

Thanks allebei, duidelijk verhaal!

[GoBieN-Be]

In Putty kan je wel instellen dat de tekst mee schaalt in grootte met je venster.
Maar het aantal karakters op 1 lijn ligt vast via seriële console.

[barrymossel]

Jerie schreef op zondag 2 maart 2025 @ 15:02:
[...]


Ik zou niet per definitie voor USB gaan maar voor iets met deze modem https://www.quectel.com/product-selector/ bijvoorbeeld Quectel EC25. Die wordt goed ondersteunt en is FOSS. Zit ook in de Mudi.

Bij de Mudi heb je dus 150 mbit down, 50 mbit up, WLAN, OpenWrt (bijvoorbeeld Wireguard VPN), batterij (helaas niet user serviceable), microSD, status schermpje, killswitch, lader, en zelfs een USB naar ethernet splitter voor je andere device. Waarbij een Raspberry Pico misschien ook wel genoeg is voor Home Assistant. Misschien draait het zelfs op de Mudi (en misschien zijn er ook wel andere alternatieven dan de Mudi).

Wat je ook nog zou kunnen doen is je smartphone met wifi tethering aanzetten. Dan kan je Raspberry daarmee verbinden. Al zou ik persoonlijk zoveel mogelijk wired gaan. Veiliger, minder issues.

Toch nog even terugkomen hierop. Je zou zelf voor een Quectel EC25 gaan. Cat4 zo te zien. Gisteren eens getest met een Fritzbox 6820 LTE en daarmee haalde ik binnenshuis 5-10Mbps. Telefoon op 5G 250Mbps en 30-50Mbps op 4G(+). Zou ik dan dus baat hebben bij een hogere categorie 4G modem? 5G dekking op een camping verwacht ik niet eerlijk gezegd, maar dat zou ook nog een (dure) optie zijn.

Blijf het al met al een lastige keuze vinden. Extern 4G/5G modem aan een dedicated OpenWRT router lijkt mij hetzelfde als een dergelijk modem aan de NUC met OpenWRT en een los AP. Ik zit dan nog wel met evt. stroomonderbreking. Maar daar valt nog wel wat op te vinden. Andere alternatief is dus een router met ingebouwd modem, maar die Fritzbox is in ieder geval niet afdoende en dat wijt ik o.a. aan de cat4 (al dan niet onterecht).

[ThinkPad]

Ik gebruikte al langere tijd DNS-over-TLS. Maar met de recente ontwikkelingen in de wereld vond ik het een goed idee om van Cloudflare & Google af te stappen en naar Europese alternatieven te schakelen. In OPNsense de boel maar even omgebouwd:



9.9.9.10 853 dns10.quad9.net
185.95.218.42 853 dns.digitale-gesellschaft.ch Digitale Gesellschaft (CH)
146.255.56.98 853 dot1.applied-privacy.net Foundation for Applied Privacy (AT)
194.242.2.2 853 dns.mullvad.net Mullvad (SE)
89.233.43.71 853 unicast.censurfridns.dk CensurfriDNS (DK)

Via https://browserleaks.com/dns kun je testen.
Zie ook: https://european-alternatives.eu/category/public-dns

Het zijn allen ongefilterde DNS servers, het filteren doe ik liever zelf (AdguardHome met OISD lijst).

[ Voor 3% gewijzigd door ThinkPad op 21-03-2025 22:14 ]

[duvekot]

ThinkPad schreef op vrijdag 21 maart 2025 @ 22:12:
Ik gebruikte al langere tijd DNS-over-TLS. Maar met de recente ontwikkelingen in de wereld vond ik het een goed idee om van Cloudflare & Google af te stappen en naar Europese alternatieven te schakelen. In OPNsense de boel maar even omgebouwd:

Je had geen zin om een eigen recursieve DNS resolver te gaan draaien?

[RobertMe]

duvekot schreef op vrijdag 21 maart 2025 @ 22:37:
[...]

Je had geen zin om een eigen recursieve DNS resolver te gaan draaien?

Wellicht doet @ThinkPad het om zijn DNS verkeer op te laten gaan in de meute? Met een eigen recursive resolver kan de ISP meekijken, want unencrypted. En met DoT naar (meerdere) upstream servers kan alleen de upstream server (gedeeltelijk) meekijken. En de authoritive DNS server ziet het (unieke) verkeer dus ook niet, want veel meer DNS verkeer vanaf de (upstream) server. Met grote DNS boeren zoals Cloudflare, Azure DNS, ... wellicht dus ook nog wel een interessant dingetje v.w.b. privacy. Want niet al die sites zullen ook gehost zijn bij..., maar wel de DNS ervan gebruiken.

Note: * RobertMe draait zelf wel een recursive resolver. Maar in combinatie met DoT dat @ThinkPad aangeeft te gebruiken lijkt me dat een prima verklaring.

[ThinkPad]

Ik lees overal dat zelf een recursive resolver draaien erg traag is, mijn cache kan niet op tegen die van publieke resolvers.

[RobertMe]

ThinkPad schreef op zaterdag 22 maart 2025 @ 06:37:
Ik lees overal dat zelf een recursive resolver draaien erg traag is, mijn cache kan niet op tegen die van publieke resolvers.

"Erg traag" zal vast meevallen? Ja, het kan wat trager zijn. Maar of het merkbaar is?
Daarnaast heeft Unbound trucjes om bv een bijna aflopende TTL/domein alvast opnieuw op te vragen. Als je hem de volgende keer dan daadwerkelijk opvraagt kan die weer gewoon uit het cache komen.

En daarnaast kan die ook verouderde data serveren. Dus als een record bv een minuut over de TTL is dat record wel nog gebruiken als antwoord en tegelijkertijd een query uitvoeren om het cache te updaten.

En je kunt een minimale TTL forceren. Want zijn TTLs van x seconden, of Y minuten, nu echt nodig? Een minimale TTL van bv 5 minuten zal dan ook alweer iets helpen om de boel snel te houden.

En van die upstream servers weet je natuurlijk ook niet wat ze exact doen. Ja, gedeeltelijk zal het cache altijd redelijk up-to-date / gevuld zijn want veel meer gebruikers, maar ook zij zouden natuurlijk kunnen prefetchen, of verlopen records serveren. En bij de onbekendere servers die je nu gebruikt (alle behalve Quad9?) is het natuurlijk ook maar de vraag of je niet semi de enige bent die bepaalde domeinnamen resolved. Ook gezien het buitenlandse partijen zijn, met waarschijnlijk relatief weinig gebruikers, en ze onbekend zijn in NL. Hoeveel NL sites zouden ze dan redelijk constant in het cache hebben?

[ThinkPad]

Ik heb Unbound nu als recursive resolver ingesteld "Serve expired" had ik al aanstaan.
Merk nog niet echt traagheid, we gaan het eens aankijken hoe dit bevalt. Dank voor de tip.

Ook DNSSEC aangezet zodat de DNS-verzoeken niet gemanipuleerd kunnen worden. Volgens mij heb ik nu het best haalbare qua privacy?

[ Voor 50% gewijzigd door ThinkPad op 22-03-2025 09:37 ]

[Tom Paris]

ThinkPad schreef op zaterdag 22 maart 2025 @ 09:18:
Volgens mij heb ik nu het best haalbare qua privacy?

Ligt er aan hoe je privacy definieert... DNS queries zijn per definitie inzichtelijk voor iedereen tussen jouw device en de DNS server, DNS kent geen confidentiality. Daarom heb je DoT, DoH, DNSCrypt, etc. Die verpakken standaard DNS queries in een versleutelde tunnel, zodat de queries niet zichtbaar zijn 'op de lijn'.

Met DoT/DoH/DNSCrypt etc heb je dan 'privacy' tov de ISP, maar uiteindelijk weet de DNS server alsnog welke queries jij maakt. Nu je zelf een recursive DNS server draait, is er niet één Cloudflare-achtige partij die jouw DNS queries ziet, maar je ISP kan ze wel weer inzien...

Daarnaast, ook al zou niemand je DNS queries in kunnen zien, zodra je een TLS verbinding opzet naar een website, is het domein zichtbaar in de TLS-handshake. Dus dan ben je je privacy alsnog kwijt. (TLS1.3 met ECH brengt daar weer verandering in).

[GoBieN-Be]

ThinkPad schreef op zaterdag 22 maart 2025 @ 09:18:
Ook DNSSEC aangezet zodat de DNS-verzoeken niet gemanipuleerd kunnen worden. Volgens mij heb ik nu het best haalbare qua privacy?

DNSSEC is niet bedoeld om privacy te bevorderen, maar wel voor betere beveiliging.
DNSSEC voegt een soort handtekening toe aan de DNS records om ze als echt te verifiëren. Zo kan een rogue DNS server geen valse DNS records serveren.

[ Voor 3% gewijzigd door GoBieN-Be op 23-03-2025 20:19 ]

[ThinkPad]

Paar dagen verder, helaas nog niet echt helemaal overtuigd van het zelf recursive resolven.
Heb al een aantal keren gehad dat een webpagina niet wilde laden. Daarna nog een keer verversen en hij deed het wel. Ik vermoed een DNS-entry die nog niet gecached was en toch een paar seconden nodig had om te resolven.

Kijk het nog even aan, maar ben bang dat ik toch terug ga naar een externe resolver. Wijziging teruggedraaid, ik forward weer naar de Europese DNS die ik eerder noemde (over DoT). Te vaak gehad dat een pagina pas na een extra keer refreshen werkte. @duvekot

[ Voor 17% gewijzigd door ThinkPad op 27-03-2025 07:37 ]

[duvekot]

ThinkPad schreef op dinsdag 25 maart 2025 @ 21:19:
Wijziging teruggedraaid, ik forward weer naar de Europese DNS die ik eerder noemde (over DoT). Te vaak gehad dat een pagina pas na een extra keer refreshen werkte. @duvekot

Je hebt het iig geprobeerd 👍
Ik blijf het wel bijzonder vinden dat de resolving zo lang duurt dat een pagina load er door niet lukt. Je zou bijna verwachten dat er dan ergens iets niet helemaal lekker loopt. Ik weet niet of unbound ergens statistieken bij houdt over hoe snel er antwoord gegeven wordt op dns requests. Want dan zou je daar dus erg langzame tijden moeten zien.

[stormfly]

duvekot schreef op donderdag 27 maart 2025 @ 08:20:
[...]

Je hebt het iig geprobeerd 👍
Ik blijf het wel bijzonder vinden dat de resolving zo lang duurt dat een pagina load er door niet lukt. Je zou bijna verwachten dat er dan ergens iets niet helemaal lekker loopt. Ik weet niet of unbound ergens statistieken bij houdt over hoe snel er antwoord gegeven wordt op dns requests. Want dan zou je daar dus erg langzame tijden moeten zien.

@ThinkPad @duvekot

Als je het hebt ingeschakeld in je setting conf file:

unbound-control stats_noreset

Die output kan je in Claude.ai of chatGPT plakken en vragen om een samenvatting. Hij meet per thread je kan er best wat uit halen.

Ik heb een cache, ik serve expired, en ik prefetch, haal de root.hints op. Moet zeggen dat ik altijd sceptisch was over Unbound maar met deze tunning is het behoorlijk rap.

[Charlie_Root]

ThinkPad schreef op dinsdag 25 maart 2025 @ 21:19:
Paar dagen verder, helaas nog niet echt helemaal overtuigd van het zelf recursive resolven.
Heb al een aantal keren gehad dat een webpagina niet wilde laden. Daarna nog een keer verversen en hij deed het wel. Ik vermoed een DNS-entry die nog niet gecached was en toch een paar seconden nodig had om te resolven.

Kijk het nog even aan, maar ben bang dat ik toch terug ga naar een externe resolver. Wijziging teruggedraaid, ik forward weer naar de Europese DNS die ik eerder noemde (over DoT). Te vaak gehad dat een pagina pas na een extra keer refreshen werkte. @duvekot

Dat kan te maken hebben gehad met problemen bij een van de root-server's (c-root gehost bij Cogent):
https://lists.dns-oarc.ne...ions/2024-May/022558.html

Wij zagen ook diverse timeouts hierdoor, wat vertraging met zich meebracht in het resolven.

[ThinkPad]

Charlie_Root schreef op maandag 31 maart 2025 @ 10:29:
[...]


Dat kan te maken hebben gehad met problemen bij een van de root-server's (c-root gehost bij Cogent):
https://lists.dns-oarc.ne...ions/2024-May/022558.html

Wij zagen ook diverse timeouts hierdoor, wat vertraging met zich meebracht in het resolven.

Bedankt voor het delen, maar dat lijkt een bericht van een jaar geleden

Ik heb sinds het terugzetten naar Europese DoT servers de issues niet meer waargenomen.

[Charlie_Root]

ThinkPad schreef op maandag 31 maart 2025 @ 10:31:
[...]

Bedankt voor het delen, maar dat lijkt een bericht van een jaar geleden

Ik heb sinds het terugzetten naar Europese DoT servers de issues niet meer waargenomen.

Het waren de zelfde problemen, kon alleen geen recentere link er van vinden.

[Bierkameel]

Net een Shuttle DL30N gekocht, dual Intel 2.5GB nic, passief gekoelde Intel N100 en 16GB DDR5
Leuk doosje voor een routertje.

PFsense wil ik niks van weten, heb even getest met https://nethsecurity.org/ en dat ziet er leuk uit maar teveel betaalde opties.
Dus ik draai nu OPNsense zonder Unbound, maar eens even wat distros proberen, ik vond Sophos ook altijd wel leuk werken maar jammer dat er een limiet van 6GB op de licentie zit.

[Tom Paris]

pfSense CE 2.8 beta is uit, zie de blogpost van Netgate.

Groot nieuws voor de KPN glasvezel gebruikers onder ons:

This version of pfSense CE software includes a new kernel-based PPPoE backend, ``if_pppoe``. This will replace the current MPD-based implementation.
- This new backend is more efficient and enables much faster speeds over PPPoE interfaces.
- This new PPPoE backend is not active by default in this version, but can be enabled with the global option under System > Advanced on the Networking tab <if_pppoe_option>`.
- This backend will be enabled by default on future versions of pfSense software.
- The ``if_pppoe`` backend does not support all advanced features of the MPD implementation. For example, it does not support MLPPP.

Dit is multi-threaded PPPoE! Niet langer de limitatie dat PPPoE maar op één core kan draaien

[nike]

net op upgrade gedrukt. emmm niks voorbereid, niet eerst de packages verwijderd zoals in de handleiding.
Zweet zweet, zelfs geen backup gemaakt.

pffff ging goed, na een paar minuten draait de beta, en zo te zien gaat alles goed.
Hier ook een KPN 1G lijntje. en verder de gebruikelijke packages: haproxy,acme,nut,openvpn,pfblocker.

Intel(R) Core(TM) i3-N305 .

[stormfly]

nike schreef op woensdag 2 april 2025 @ 19:33:
net op upgrade gedrukt. emmm niks voorbereid, niet eerst de packages verwijderd zoals in de handleiding.
Zweet zweet, zelfs geen backup gemaakt.

pffff ging goed, na een paar minuten draait de beta, en zo te zien gaat alles goed.
Hier ook een KPN 1G lijntje. en verder de gebruikelijke packages: haproxy,acme,nut,openvpn,pfblocker.

Intel(R) Core(TM) i3-N305 .

Hoe is de core verdeling voor PPPoE als je de aanpassing doorvoert en een file van een paar gigabyte binnenhaalt?
This new PPPoE backend is not active by default in this version, but can be enabled with the global option under System > Advanced on the Networking tab <if_pppoe_option>`.

[ Voor 3% gewijzigd door stormfly op 02-04-2025 19:43 ]

[nike]

Ik heb het aangezet!

Het gaat te snel, voor ik een iso van debian download 3 gig is hij al binnen. dit was tijdens het downloaden met http.

[ Voor 3% gewijzigd door nike op 02-04-2025 19:56 ]

[Tom Paris]

stormfly schreef op woensdag 2 april 2025 @ 19:42:
[...]


Hoe is de core verdeling voor PPPoE als je de aanpassing doorvoert en een file van een paar gigabyte binnenhaalt?
This new PPPoE backend is not active by default in this version, but can be enabled with the global option under System > Advanced on the Networking tab <if_pppoe_option>`.

Even geduld voor echte resultaten

It will actually get faster in 2.8-RELEASE because there was a rework that occurred too late to make the beta cut-off.

[Tom Paris]

Netgate heeft nu een blogpost waarin ze dieper ingaan op PPPoE in pfSense, hoe dit normaal in *BSD werkt en wat hun nieuwe if_pppoe module doet. Paar passages:

Key Features of if_pppoe

• Multi-Core Optimization: Unlike Netgraph, if_pppoe is designed to leverage multiple CPU cores effectively. It uses Receive Side Scaling (RSS) to distribute packets across cores based on protocol, source/destination addresses, and port numbers. This ensures that a single TCP flow stays on one core—minimizing out-of-order packets—while other cores handle concurrent flows.
• Simplified Architecture: By focusing solely on PPPoE, if_pppoe avoids the complexity of supporting arbitrary network functions. This leads to a leaner, faster implementation.
• Concurrent Packet Processing: The driver allows simultaneous packet handling in both receive and transmit directions across multiple CPUs. Exclusive operations (e.g., blocking other CPUs) are limited to rare reconfiguration events.

Performance Gains

On a Netgate 6100, we’ve observed throughput improvements ranging from 25% to 100% in scenarios with multiple simultaneous traffic flows—common in real-world deployments.

Sinds gisteren is er ook een nieuwe versie van de beta om te testen.

[mohblack]

Is er al iemand die ervaring heeft met RAM en SSD voor een Topton met N150?
Besteld via ali en de verkoper gevraagd maar nog geen reactie ontvangen.

[ThinkPad]

Irritatiepuntje waar ik al langer tegenaan loop: hostnames uit DHCP worden niet geregisteerd in Unbound. Hoe krijg ik dat voor elkaar?

Ben vaak aan het prutsen met ESP moduletjes en moet altijd een static DHCP reservation met hostname aanmaken én vervolgens Unbound herstarten om ze via hostname te kunnen benaderen Heb net eentje geflashed met ESPHome firmware en als ik hem open via browser, dan zie ik (in AGH logs) dat Unbound een "NXDOMAIN" teruggeeft:



De optie "Register ISC DHCP4 Leases" onder Unbound > General staat al aan.

[ Voor 3% gewijzigd door ThinkPad op 01-05-2025 11:47 ]

[Villager]

mohblack schreef op maandag 28 april 2025 @ 22:03:
Is er al iemand die ervaring heeft met RAM en SSD voor een Topton met N150?
Besteld via ali en de verkoper gevraagd maar nog geen reactie ontvangen.

Nee, wel met een Topton N100. Ben na wat minder goeie keuzes uitgekomen op een 16GB Samsung geheugenmodule, zoals de verkoper aangaf, en een WD_Black SN770 nvme drive. Ik draai nu Opnsense bare metal nadat het me niet lukte om Opnsense stabiel te krijgen op Proxmox. Heb ook een N305 en daarop draaide het onder Proxmox als een zonnetje.

[ Voor 17% gewijzigd door Villager op 01-05-2025 16:52 ]

[Raven]

@ThinkPad Misschien een idee dit (ook) in het PiHole-topic te vragen? Unbound komt daar volgens mij vaker voorbij dan hier.

edit: AGH.... kwartje viel net

[ Voor 12% gewijzigd door Raven op 01-05-2025 19:37 ]

[thof]

Villager schreef op donderdag 1 mei 2025 @ 12:18:
[...]

Nee, wel met een Topton N100. Ben na wat minder goeie keuzes uitgekomen op een Samsung geheugenmodule, zoals de verkoper aangaf, en een WD_Black SN770 nvme drive.

Hier alleen met een CWWK N100, enkele 48GB module van Crucial:
Crucial RAM 48GB DDR5 5600MHz (of 5200MHz of 4800MHz) Laptop Geheugen CT48G56C46S5
Deze 'werkt' maar moest wel een ventilator er op richten om memory errors te voorkomen. Nog steeds niet heel blij mee, maar kon destijds niet meer retour. Draait nu wel meer dan een jaar stabiel.

[ Voor 3% gewijzigd door thof op 01-05-2025 16:40 ]

[EverLast2002]

ThinkPad schreef op donderdag 1 mei 2025 @ 11:13:
Irritatiepuntje waar ik al langer tegenaan loop: hostnames uit DHCP worden niet geregisteerd in Unbound. Hoe krijg ik dat voor elkaar?

Ben vaak aan het prutsen met ESP moduletjes en moet altijd een static DHCP reservation met hostname aanmaken én vervolgens Unbound herstarten om ze via hostname te kunnen benaderen Heb net eentje geflashed met ESPHome firmware en als ik hem open via browser, dan zie ik (in AGH logs) dat Unbound een "NXDOMAIN" teruggeeft:

[Afbeelding]

De optie "Register ISC DHCP4 Leases" onder Unbound > General staat al aan.

[Afbeelding]

ik zit hier thuis ook altijd mee te klooien....
heb je in adguard home de optie aangevinkt van "use private reverse DNS servers" en je Unbound ip adres hier bijstaan (AGH > Settings > DNS settings) ?
er staat letterlijk in de beschrijving dat wanneer je dit niet aanzet, AGH altijd antwoordt met een NXDOMAIN

[ Voor 4% gewijzigd door EverLast2002 op 01-05-2025 17:38 ]

[ThinkPad]

Dat staat al aan. Maar het is geen AGH probleem, want niet al m'n devices gaan langs AGH (praten rechtstreeks met Unbound op de OPNsense) en daar heb ik het issue ook. Het is gewoon een eigenaardigheid van OPNsense/Unbound volgens mij.

[EverLast2002]

ThinkPad schreef op donderdag 1 mei 2025 @ 20:20:
Dat staat al aan. Maar het is geen AGH probleem, want niet al m'n devices gaan langs AGH (praten rechtstreeks met Unbound op de OPNsense) en daar heb ik het issue ook. Het is gewoon een eigenaardigheid van OPNsense/Unbound volgens mij.

kan het iets te maken hebben met .home.arpa waar Unbound zich in verslikt?
zonder home.arpa resolved ie waarschijnlijk wel, en met geeft ie NXDOMAIN.
(ik gebruik zelf ook home.arpa als domein voor het interne netwerk)

[ThinkPad]

Ik zit nu nog even een aantal dynamische leases te pingen/nslookup-en en lijkt nu wel te werken zoals het zou moeten. Vreemd, zal het op een later moment nog eens goed testen met wat IOT-meuk.

[mohblack]

Dank voor de reacties,
Na wat verder lezen, zoeken en reply van de Ali store ( generieke antwoord wat al eerder is gepost)
Heb ik gekozen voor een crucial CT module en Kingston SSD.

Ik ga het eerst proberen met proxmox.
Wil de mogelijkheid hebben ook nog wat andere kleine machines erop draaien.
Mocht dat niet goed werken dan gewoon direct op het doosje.
Als het goed is komt de Topton volgende week.
Als het eenmaal draait (of niet) laat ik het weten.

[TheCeet]

Maakt het uit of je een NVMe of Sata SSD gebruikt als main schijf in een mini PC waar enkel Opnsense op draait?

[mohblack]

Vandaag topton ontvangen en proxmox + OPNsense op geïnstalleerd.

Draait nu een uurtje of 6 stabiel icm met:
uitvoering: Kingston NV3 (retail) 1TB
uitvoering: Crucial CT16G56C46S5

[stijnos1991]

Als je OPNsense op Proxmox installeert, is het dan beter om de virtuele netwerkadapters van Proxmox te gebruiken, of doe je passthrough?

[Rolfie]

stijnos1991 schreef op woensdag 7 mei 2025 @ 11:57:
Als je OPNsense op Proxmox installeert, is het dan beter om de virtuele netwerkadapters van Proxmox te gebruiken, of doe je passthrough?

Beide oplossingen hebben zo hun eigen afhankelijkheden.

Virtueel WAN kan icm PPPOE wat voordeel opleveren.
Virtueel LAN kan makkelijk en sneller zijn icm veel hosts op je Proxmox server.
Passthrough, kan mogelijk een betere performance geven omdat er minder overhead in zit.

Ik gebruik nu Virtueel WAN, passthrough Nic voor mijn IPTV, heb IGMP nog niet goed werkend gekregen met virtuele interfaces.
Virtueel voor mijn LAN.

Ben er tevrede over, afgezien mijn IPTV WAN Interface na een boot niet altijd een IP adres krijgt en mutlicast dan niet werkt. Ik heb nu in monit een scriptje geschreven dat indien dit voorkomt er een DHCP request gedaan wordt.

[GoBieN-Be]

De discussie is al een paar keer gevoerd met voor- en nadelen.
In kader van makkelijke restore en hardware onafhankelijkheid kies ik voor allemaal virtuele interfaces.

[barrymossel]

Zucht, weer iets wat ik echt niet begrijp...

Kleine schets van het netwerk:

• Ziggo modem in bridge naar Proxmox server waarop OPNSense draait (WAN)
• LAN naar switch (op die switch is alles op één poort na VLAN1)
• Van die switch (100% VLAN1) naar tweede switch (op 100% VLAN1 poort)

De tweede switch zat ook altijd in VLAN1. Nu zie ik hem ineens in VLAN9. Alles maar eens herstart en de switch is bereikbaar via z'n IP in VLAN9, maar is helemaal niet zichtbaar in de DHCP leases in OPNSense.

Iemand enig idee wat er hier mis gaat? Laat maar weten als je nog meer informatie wilt weten...

[ Voor 11% gewijzigd door barrymossel op 17-05-2025 17:15 ]

[tomdh76]

barrymossel schreef op zaterdag 17 mei 2025 @ 17:09:
Zucht, weer iets wat ik echt niet begrijp...

Kleine schets van het netwerk:

• Ziggo modem in bridge naar Proxmox server waarop OPNSense draait (WAN)
• LAN naar switch (op die switch is alles op één poort na VLAN1)
• Van die switch (100% VLAN1) naar tweede switch (op 100% VLAN1 poort)

De tweede switch zat ook altijd in VLAN1. Nu zie ik hem ineens in VLAN9. Alles maar eens herstart en de switch is bereikbaar via z'n IP in VLAN9, maar is helemaal niet zichtbaar in de DHCP leases in OPNSense.

Iemand enig idee wat er hier mis gaat? Laat maar weten als je nog meer informatie wilt weten...

Is het niet makkelijker de switches vaste ip adressen geven buiten de dhcp range van opnsense

[barrymossel]

tomdh76 schreef op zaterdag 17 mei 2025 @ 17:14:
[...]


Is het niet makkelijker de switches vaste ip adressen geven buiten de dhcp range van opnsense

De switches hadden IN OPNSense een vast IP adres, maar daar kreeg ik die ene switch dus niet te pakken. En toen zag ik dat ie ineens in een andere VLAN zat.

Nu heb ik gisteren het kastje waar de switch in zit even helemaal opnieuw ingericht, maar ik heb geen kabels omgeprikt in de switch. Snap er niks van.

[Charlie_Root]

barrymossel schreef op zaterdag 17 mei 2025 @ 17:09:
Zucht, weer iets wat ik echt niet begrijp...

Kleine schets van het netwerk:

• Ziggo modem in bridge naar Proxmox server waarop OPNSense draait (WAN)
• LAN naar switch (op die switch is alles op één poort na VLAN1)
• Van die switch (100% VLAN1) naar tweede switch (op 100% VLAN1 poort)

De tweede switch zat ook altijd in VLAN1. Nu zie ik hem ineens in VLAN9. Alles maar eens herstart en de switch is bereikbaar via z'n IP in VLAN9, maar is helemaal niet zichtbaar in de DHCP leases in OPNSense.

Iemand enig idee wat er hier mis gaat? Laat maar weten als je nog meer informatie wilt weten...

[Afbeelding]

Dit is wel heel vaag beschreven, daarnaast vraag ik me af wat je met vlans doet als je alles in vlan 1 mikt. Dat hoort echt niet zo. Dhcp voor management adressen lijkt me ook niet zo handig.

Edit ;
Met die tekening ben ik helemaal verdwaald. Je AP ook in vlan 1 maar IOT in vlan 9? Misschien even de tekening goed updaten met trunk ports en waar je wel en niet welke vlans tagged.

[ Voor 7% gewijzigd door Charlie_Root op 17-05-2025 17:20 ]

[barrymossel]

Charlie_Root schreef op zaterdag 17 mei 2025 @ 17:18:
[...]


Dit is wel heel vaag beschreven, daarnaast vraag ik me af wat je met vlans doet als je alles in vlan 1 mikt. Dat hoort echt niet zo.

Niet alles zit in VLAN1. Meeste in het netwerk is hier via wifi. Dus daar wordt alles in de juiste VLAN gestopt. Uiteindelijk zitten alleen mijn telefoon, laptop, telefoon vrouw (al twijfel ik daar over ), de APs + switches in VLAN1. De bedrade zaken krijgen gewoon een VLAN toegewezen in de switches.

Dhcp voor management adressen lijkt me ook niet zo handig.

Als je dat zou kunnen uitleggen graag. Maar feit blijft dat het voorheen gewoon goed ging en nu ineens de switch in een ander VLAN zit. Zou toch alleen moeten kunnen als er iets verkeerd is omgeprikt?

[barrymossel]

Charlie_Root schreef op zaterdag 17 mei 2025 @ 17:18:
[...]
Edit ;
Met die tekening ben ik helemaal verdwaald. Je AP ook in vlan 1 maar IOT in vlan 9? Misschien even de tekening goed updaten met trunk ports en waar je wel en niet welke vlans tagged.

Switch 1




Switch 2




U vraagt wij draaien. VLAN9 is ook waar ineens de tweede switch op zit. Alle andere VLANS zijn gasten en IoT en gaan via wifi.

[jadjong]

Mijn ervaring met deze switch is dat de management interface regelmatig in een random vlan opduikt.

[barrymossel]

jadjong schreef op zaterdag 17 mei 2025 @ 17:45:
Mijn ervaring met deze switch is dat de management interface regelmatig in een random vlan opduikt.

Zou een static IP instellen in de switch zelf dan een oplossing kunnen zijn? Of gewoon eens kijken naar twee nieuwe switches?

---edit---
Schijnbaar werkt dat. Maar ik ga toch eens kijken naar nieuwe switches denk ik.

[ Voor 12% gewijzigd door barrymossel op 18-05-2025 10:51 ]

[Charlie_Root]

barrymossel schreef op zaterdag 17 mei 2025 @ 17:46:
[...]

Zou een static IP instellen in de switch zelf dan een oplossing kunnen zijn? Of gewwon eens kijken naar twee nieuwe switches?

---edit---
Schijnbaar werkt dat. Maar ik ga toch eens kijken naar nieuwe switches denk ik.

Dat is hoe het hoort, een static management IP in het juiste vlan. Als er iets in het netwerk stuk is en DHCP dus niet werkt ben je de switch ook kwijt. Knap lastig zoeken.

Je vlan overzicht maakt het iets duidelijker, zou goed moeten zijn.

[ThinkPad]

Ik zag dat de beveiligingsrichtlijnen van NCSC omtrent TLS vernieuwd zijn: link

Ik zat te kijken naar OPNsense om de webinterface te versleutelen conform de NCSC best practices, maar ik krijg de webinterface niet op een sterkere cipher:

In System > Settings > Administration heb ik de volgende ciphers geselecteerd:


Maar die bovenste wil ik eigenlijk eruit hebben, omdat die volgens NCSC als 'voldoende' i.p.v. goed wordt gezien:


Ik gebruik liever alleen de 'goed' settings Als ik hem weglaat krijg ik deze melding in OPNsense:


Ok, nouja blijkbaar móet die aanwezig zijn. Maar na opnieuw openen Firefox zie ik dus dat hij blijft hangen op de AES_128 en niet upgrade naar een nieuwere/betere cipher.

[ Voor 61% gewijzigd door ThinkPad op 03-06-2025 10:04 ]

[silentkiller]

barrymossel schreef op zaterdag 17 mei 2025 @ 17:46:
[...]

Zou een static IP instellen in de switch zelf dan een oplossing kunnen zijn? Of gewoon eens kijken naar twee nieuwe switches?

---edit---
Schijnbaar werkt dat. Maar ik ga toch eens kijken naar nieuwe switches denk ik.

Aan je screenshots te zien, zijn het tplink switches?

Ik heb zelf een 16 port tplink (geen POE), een 8 port (geen POE) en een 8 port (POE) switch van tplink

Ik heb ook al gemerkt dat deze switches verkeer aannemen vanuit eender welk device eraan hangt in eender welke VLAN. Je kan de mgmt interface ook enkel maar een IP toewijzen in de switch, je moet nergens zeggen welke VLAN.

Dat is imo een enorme design fout in de switches maar ze zijn dan ook wel echt veel goedkoper dan andere managed switches.
Voor de rest geen klagen van dus ik kan er mee leven voor mijn thuisnetwerkje..

[barrymossel]

silentkiller schreef op dinsdag 3 juni 2025 @ 10:01:
[...]

Aan je screenshots te zien, zijn het tplink switches?

Ik heb zelf een 16 port tplink (geen POE), een 8 port (geen POE) en een 8 port (POE) switch van tplink

Ik heb ook al gemerkt dat deze switches verkeer aannemen vanuit eender welk device eraan hangt in eender welke VLAN. Je kan de mgmt interface ook enkel maar een IP toewijzen in de switch, je moet nergens zeggen welke VLAN.

Dat is imo een enorme design fout in de switches maar ze zijn dan ook wel echt veel goedkoper dan andere managed switches.
Voor de rest geen klagen van dus ik kan er mee leven voor mijn thuisnetwerkje..

Maar lijkt me wel een design fout die "eenvoudig" met een firmware update kan worden opgelost. Vreemd genoeg doen ze dat niet.

[silentkiller]

Tuurlijk, maar dat is het nadeel van goedkoop denk ik dan
Ik had van de week flink lopen rommelen met de VLAN/PVID instellingen en de poort bleef in de foute VLAN zitten.
backup terug gezet, switch gereboot via het menu -> allemaal geen nut.

Stroom eraf, stroom er terug op en 't werkte terug.

Voor de rest doen de switches het prima (hoewel ik volgende keer ook voor een duurder model ga )

[Murrays]

Voor onze nieuwbouw woning ben ik ook op zoek naar een zelfbouw fw oplossing. In het verleden als eens met OPNsense oplossing getest toen liep ik tegen de PPPoE single thread issues aan waardoor het niet lukte om 1Gb te halen. Nu zie ik dat deze inmiddels opgelost zijn. Voor onze nieuwbouw woning wil ik dus kijken naar een 4Gb (KPN) of 8Gb (Odido) lijn (ik weet het, dat is overkill)… nu zag ik op Ali dit systeem met 2x 10GB Nics: https://nl.aliexpress.com...65-468e-866f-c3119a54d68f

Heeft iemand hier ervaring mee om hiermee een 1Gb+ glaslijn goed aan de praat te krijgen? Dit systeem maakt gebruik van: 2x Marvell AQC113 10G LAN. Helaas kan ik daar maar weinig info over vinden. Hopelijk kan iemand me hier helpen en heeft hier ervaring mee

[Tom Paris]

Murrays schreef op zondag 3 augustus 2025 @ 11:28:
In het verleden als eens met OPNsense oplossing getest toen liep ik tegen de PPPoE single thread issues aan waardoor het niet lukte om 1Gb te halen. Nu zie ik dat deze inmiddels opgelost zijn.

'Opgelost' is het alleen in pfSense, die heeft nu multi-threaded PPPoE. OPNsense blijft single thread, en heb je dus nog steeds hoge single core performance nodig. Ik weet niet wat dat betekent voor 4Gbps, maar Odido heeft sowieso geen PPPoE.

Murrays schreef op zondag 3 augustus 2025 @ 11:28:
Dit systeem maakt gebruik van: 2x Marvell AQC113 10G LAN. Helaas kan ik daar maar weinig info over vinden. Hopelijk kan iemand me hier helpen en heeft hier ervaring mee

In de specificaties staat:

Unix-based OS like pfSense, OPNsense and so on do not have drivers for this Marvell LAN.

[ Voor 27% gewijzigd door Tom Paris op 03-08-2025 13:34 ]

[Murrays]

Tom Paris schreef op zondag 3 augustus 2025 @ 13:31:
[...]


'Opgelost' is het alleen in pfSense, die heeft nu multi-threaded PPPoE. OPNsense blijft single thread, en heb je dus nog steeds hoge single core performance nodig. Ik weet niet wat dat betekent voor 4Gbps, maar Odido heeft sowieso geen PPPoE.


[...]


In de specificaties staat:


[...]

Hmmm ik las een workaround in de update thread dat het ook mogelijk was multi thread te realiseren met OPNsense nu. Ik weet dat Ododi geen PPPoE heeft maar ik zoek gewoon het juiste systeem om dit goed te kunnen draaien. Deze valt al af.. heb het helaas zelf niet gelezen bij de Ali advertentie…

[TumTum]

Murrays schreef op zondag 3 augustus 2025 @ 15:15:
[...]


Hmmm ik las een workaround in de update thread dat het ook mogelijk was multi thread te realiseren met OPNsense nu. Ik weet dat Ododi geen PPPoE heeft maar ik zoek gewoon het juiste systeem om dit goed te kunnen draaien. Deze valt al af.. heb het helaas zelf niet gelezen bij de Ali advertentie…

Weet je zeker dat je die snelheden gaat halen met nieuwbouw? Ik heb hier namelijk maximaal 1Gbps.
Met 1Gbps is PPPoE sowieso geen probleem.

[Murrays]

TumTum schreef op zondag 3 augustus 2025 @ 16:45:
[...]


Weet je zeker dat je die snelheden gaat halen met nieuwbouw? Ik heb hier namelijk maximaal 1Gbps.
Met 1Gbps is PPPoE sowieso geen probleem.

Ja Odido biedt sowieso 8Gbps aan maar ook een 2Gbps.. maar dan zou ik nog kunnen kiezen voor een 4x 2.5gb kastje. Voor KPN moet ik inderdaad nog even kijken of het wel aangeboden wordt

[Tom Paris]

TumTum schreef op zondag 3 augustus 2025 @ 16:45:
[...]


Weet je zeker dat je die snelheden gaat halen met nieuwbouw? Ik heb hier namelijk maximaal 1Gbps.
Met 1Gbps is PPPoE sowieso geen probleem.

KPN legt alleen nog XGS-PON aan, geen AON.

[mrdemc]

Tom Paris schreef op zondag 3 augustus 2025 @ 18:11:
[...]


KPN legt alleen nog XGS-PON aan, geen AON.

Niet persé. Als er in de buurt plek is op AON dan gebeurd dat ook nog zover ik weet.

Zie dit bericht met uitleg:
Economics in "[KPN XGS-PON] Eigen router/ONT gebruiken"

[stormfly]

Het gaat hier vaak over de ChangWang bordjes van CCKW of TopTon etc. Ik heb er vandaag een gerepareerd van een defecte BIOS. Het komt nogal nauw qua apparatuur niet elke flasher werkt. Ter naslag om je bios te flashen een howto.

Je hebt deze programmer nodig met een 3,3 volt schakelaar. Mijn collega heef het eerst zelf tientallen malen geprobeerd om te flashen met het andere model CH 347 zonder schakelaar. Maar dat werkt niet, die heeft default 5 volt. Het vreemde is dat een reserve chip die we hadden gekocht ivm lossolderen, W25Q128JVSQ met de 5v programmer wel kan programmeren. Er gaat iets mis met de 5v programmer als je de BIOS chip op het moederboard wilt schrijven, met de getoonde 3,3v programmer gaat dat goed.





Deze verende pinnen zijn veel fijner dan de standaard zwarte klem. Nu moet ik toegeven dat wij in de zoektocht de klem ook wel "versleten" hadden het plastic brokkelt af. Met deze verende pinnen is het een fluitje van een cent, het is een hol kapje wat exact over het IC heen pas.

SOIC8 208mil 5.8mm is de juiste voor W25Q128JVSQ



Deze bin file moet je dan in het IC programmeren. Je kunt NeoProgrammer gebruiken of flashprom onder MacOS


En wellicht overbodig: alle componenten moeten van het moederboard af, RAM, NVMe, CMOS 3volt batterij, en de power adapter.

[The Zep Man]

stormfly schreef op donderdag 14 augustus 2025 @ 15:29:
Je hebt deze programmer nodig met een 3,3 volt schakelaar.

Bij gebrek daaraan: je kan ook een Raspberry Pi met een 40-pin connector gebruiken in combinatie met flashrom. Die heeft het juiste voltage (3,3V) op diens GPIO-pinnen, waarmee die onderteuning heeft voor het betreffende protocol (SPI). De pinout vind je hier (pin 19, 21, 23, 24 voor dataoverdracht, pin 1 en 39 voor voeding van de chip).

[ Voor 13% gewijzigd door The Zep Man op 14-08-2025 15:50 ]

[RobertMe]

@The Zep Man als ik het goed begrijp schrijf jij dat je de flash chip rechtstreeks op een RPi kunt aansluiten? Dus puur vanaf de klem / ..., direct naar de GPIO pins van de RPi? Da's wel nice.

* RobertMe had vorig jaar Bricked bios Yoga Slim 7 Pro opnieuw flashen via EEPROM . Toen ook zo'n programmer besteld, alleen dan zonder 3.3V / 5V switch maar met een extra bordje dat de omzetting doet. Het stukje van @stormfly met een klem die "niet pakt" herken ik ook. Heb toen veel geëxperimenteerd (verschillende Frankenstein biossen in elkaar geprutst) en op het eind mislukte lezen toch wel vaak. Door wat vaagheden (POST die een minuut duurde , i.p.v. letterlijk 1 of 2 seconden) een paar weken terug opnieuw geflasht, en velrvele pogingen nodig gehad voordat de chip betrouwbaar gelezen was (lees: 2x een lees actie dezelfde file opleverde). En uiteindelijk iets van 20 minuten lang "heel stil gezeten" en de klem er op blijven drukken zonder "een millimeter" te bewegen (en dan lezen, diff met voorgaande keer lezen, zelfde resultaat, en op hoop van zegen schrijven wat ook weer lezen + schrijven + verifyen is en dus vele minuten duurt). Die andere gelinkte klem ziet er mogelijk wel beter uit? Maar ook duurder denk ik dan het hele setje bij elkaar kostte

[Tom Paris]

RobertMe schreef op donderdag 14 augustus 2025 @ 16:04:
@The Zep Man als ik het goed begrijp schrijf jij dat je de flash chip rechtstreeks op een RPi kunt aansluiten? Dus puur vanaf de klem / ..., direct naar de GPIO pins van de RPi? Da's wel nice.

Dat kan ja. Zo flash je bijv. ook OpenWrt op de KPN Experia Wifi en KPN SuperWifi 1.

[The Zep Man]

RobertMe schreef op donderdag 14 augustus 2025 @ 16:04:
@The Zep Man als ik het goed begrijp schrijf jij dat je de flash chip rechtstreeks op een RPi kunt aansluiten? Dus puur vanaf de klem / ..., direct naar de GPIO pins van de RPi? Da's wel nice.

Klopt. Wat je nodig hebt is een apparaat dat als SPI host kan werken. Een Pi kan dit. Er is geen andere hardware nodig. Wat jumper cables en een testklem zijn voldoende. Opensource software doet de rest.

Werkt ook goed om slechte flashes mee te herstellen. Dat kan via een testklem en op sommige desktopmoederborden ook via een undocumented header.

[ Voor 12% gewijzigd door The Zep Man op 14-08-2025 17:48 ]

[RobertMe]

The Zep Man schreef op donderdag 14 augustus 2025 @ 17:46:
[...]


Klopt. Wat je nodig hebt is een apparaat dat als SPI host kan werken. Een Pi kan dit. Er is geen andere hardware nodig. Wat jumper cables en een testklem zijn voldoende. Opensource software doet de rest.

Werkt ook goed om slechte flashes mee te herstellen. Dat kan via een testklem en op sommige desktopmoederborden ook via een undocumented header.

De slechte flash heb ik intussen dus ervaring mee Lenovo gooide het gewoon op "buiten garantie" en wilde me uit coulance nog de "extended warranty" verkopen met een korting zodat ik hem dus "gratis" kon laten maken Terwijl gewoon de "exe" van op hun website de boel had gesloopt en er op internet vele verhalen te vinden zijn van bricked biosen na een update.

Nu heb ik dan die losse chip / USB "stick", werkt an zich prima, alleen dan dat de klem (intussen) nogal iffy is (maar die blijft met flashen vanaf RPi natuurlijk ook nodig). En RPis als alternatief heb ik ook nog wel. Zelfs een "originele" ("Model B"), meteen besteld nadat het ding uit kwam vanuit de UK. Vervolgens niks mee gedaan behalve OpenELEC er op

@stormfly , je geeft trouwens aan een nieuwe flash chip besteld te hebben. Maar kun je die solderen? Ben zelf een relatieve leek (laatst mijn defecte subwoofer gefixt, eens een keer een knop op een muis vervangen en wat met ESPjes geprutst). Through hole spul is natuurlijk (heel) eenvoudig. Maar dit surface mounted spul is natuurlijk andere koek. Met mijn gewone bout vast niks aan te beginnen. Heb een TS100.

[stormfly]

RobertMe schreef op donderdag 14 augustus 2025 @ 18:18:
[...]

@stormfly , je geeft trouwens aan een nieuwe flash chip besteld te hebben. Maar kun je die solderen? Ben zelf een relatieve leek (laatst mijn defecte subwoofer gefixt, eens een keer een knop op een muis vervangen en wat met ESPjes geprutst). Through hole spul is natuurlijk (heel) eenvoudig. Maar dit surface mounted spul is natuurlijk andere koek. Met mijn gewone bout vast niks aan te beginnen. Heb een TS100.

Ja dat had ik wel gedurfd met een regelbare Weller, ik heb een handvol verschillende puntjes. Heb wat YT bekeken en dan beide zijde alle 4 de pootjes vertinnen, opwarmen links-rechts-links-rechts en dan gaat hij zweven. Daarna met een stift met een dunnere punt even op 2 pootjes vastzetten en dan de overige pootjes door laten vloeien. Dat was mijn plan ;-) maar gelukkig is het niet nodig want het blijft wel gepriegel.

[nike]

Zijn er ook al mensen die nadenken om hun PFsense of Opensense doosje te vervangen voor een unify cloud fiber.
Zeker ook gezien de specs https://store.ui.com/us/e...-fiber/products/ucg-fiber
Wat ik dan nog zou missen is haproxy dus daar zou ik een aparte lxc container voor moeten bouwen.
Maar ja ik draai al zolang zelf pfsense met zoveel rules en vlans etc... dat het nog een hele klus word om het over te zetten.

Maar iets nieuws is ook leuk, en ik heb al switchen en AP's van unify.

[jadjong]

Nee.

[RobertMe]

jadjong schreef op zaterdag 16 augustus 2025 @ 13:39:
Nee.

Goede onderbouwing

@nike, ik heb juist ~2,5 jaar terug de overstap gemaakt van een USG naar volledig zelfbouw (TopTon doosje met Debian). De nieuwe UniFi software was gewoon crap, en een zone based firewall bv, waardoor het ook IPv6 capable was, was onmogelijk (kan intussen wel). Maar nu heb ik ook gewoon veel meer vrijheden. En op mijn router draai ik nu ook gewoon een deel van mijn Docker containers (binnen halen Linux ISOs bv). En wellicht dat ik op een later moment ik mijn servertje en router helemaal samenvoeg. Met hoe het nu draait (Docker containers op de router, gekoppeld aan VLANs etc etc) heb ik dat in principe al en is er geen enkele echte reden waarom iets op het servertje zou moeten en niet op de router zou kunnen. Sowieso al omdat beide dezelfde CPU bevatten (N5105), en het servertje 8GB gesoldeerd RAM heeft dat vol zit , terwijl de router 2x SODIMM heeft waar intussen de officiële max van 16GB in zit (maar o.a. de ervaringen in dit topic aangeven dan 32GB vaak ook werkt).
En in de nabije toekomst (1, 1,5 jaar) komt er wellicht wel weer een "normaler" systeem voor in de plaatst. Met een Intel Core processor, mATX mobo met, mogelijkheid tot 128GB RAM of whatever, .... Software technisch zie ik momenteel geen enkele reden om dat niet te doen. En hardware technisch heeft het ook wat voordelen (geen limiet door netwerk in kopiëren bestaande van router naar server bv . Maar ook dat het waarschijnlijk weer zuiniger is dan de 8W + 4W die beiden nu gebruiken. En "ongelimiteerde" RAM grote. Mogelijkheid tot een shitload aan opslag (nu gelimiteerd tot 1x NVME en 1x SATA, mATX heb je vaak toch al 2x NVME en 4x SATA. Etc etc). Enige nadeel is dan de grotere form factor en de investering.

[Tom Paris]

RobertMe schreef op zaterdag 16 augustus 2025 @ 14:10:
geen enkele echte reden waarom iets op het servertje zou moeten en niet op de router zou kunnen

Veiligheid. Een configuratiefout of kwetsbaarheid kan je duur komen te staan als je alles samenvoegt op één machine en één OS. Zelf zou ik een *sense VM in ESXi/Proxmox als 'bare minimum' beschouwen vmb veiligheid en beschikbaarheid, heb je mogelijkheden genoeg om daarnaast Linux VMs en containers te draaien geïsoleerd van je router.

[RobertMe]

Tom Paris schreef op zaterdag 16 augustus 2025 @ 14:46:
[...]


Veiligheid. Een configuratiefout of kwetsbaarheid kan je duur komen te staan als je alles samenvoegt op één machine en één OS.

Dat kan net zo goed gebeuren als je ze wel apart hebt. Ook dan kun je bv in de firewall een configuratiefout maken waardoor alles open staat.
En alles is al dusdanig ingericht dat ik bij het starten van een nieuwe Docker container ook weer de firewall moet nalopen/aanpassen (tot het punt dat containers die "offline" zouden moeten werken vervolgens niet starten omdat ze initieel wel een bestand moeten downloaden maar dat niet werkt). Dus sure, met een configuratiefout kan het mis gaan, maar dat kan ook bij een gescheiden systeem. En door alles by default zo restrictief mogelijk te doen en daarna "op maat" dingen aan te passen / toe te staan neemt dat ook al veel weg.

Zelf zou ik een *sense VM in ESXi/Proxmox als 'bare minimum' beschouwen vmb veiligheid en beschikbaarheid, heb je mogelijkheden genoeg om daarnaast Linux VMs en containers te draaien geïsoleerd van je router.

Proxmox ben ik bekend mee en juist van af aan het stappen. Voegt IMO niks toe. Ik wil gewoon een OS hebben waarop ik software kan draaien, geen hypervisor waar ik vervolgens een LXC of VM op moet zetten om daarin weer exact dezelfde software te draaien die ook op een gewone server zonder VM had gekund.
En of het met Proxmox nu zoveel veiliger wordt? Juist zaken als de netwerk configuratie in Proxmox op zetten lijken mij nogal fout gevoelig waardoor je weer tegen het initiële punt aan loopt "een configuratiefout en de boel is lek".

Edit / aanvulling:
Docker draait in mijn geval ook met de setting op met zijn vingers van de firewall af te blijven. En "port forwards" in Docker geef ik uiteraard ook niet op (die wel kinda zouden werken doordat Docker gewoon doodleuk een transparante TCP / UDP proxy start. Dus een proxy proces op de host dat luistert op de opgegeven poort en doorstuurt naar de opgegeven poort van de container. Alleen zou zelfs in dat geval dus weer de firewall niet zijn aangepast en dus het binnenkomende verkeer nog steeds gedropt worden).

[ Voor 13% gewijzigd door RobertMe op 16-08-2025 15:32 ]

[nike]

Persoonlijk ga ik nooit meer mijn *sense router virtualiseren.
Elke keer als ik de host wil updaten, ligt het internet er uit.
Het het kan best wel eens handig zijn als er iets met je host is, dat je altijd nog internet heb.

Maar ja bij mij is het nu even zwaar overkill, mijn pfsense draait op een chinees doosje een n305 met alleen de firewall. wel super stabiel en snel Ik had eerst een atom ding, maar ik kwam met speed testen nooit boven de 1G. dat had te maken dat ik altijd speedtesten deed via vlans en dat trok hij niet. nu wel.
Maar alles in het unify eco systeem trek mij ook wel.

[TheCeet]

Wie kan me helpen met hetvolgende:

Setup:
PC1: OpnSense met Unbound DNS.
PC2: Proxmox: LXC AdGuard Home en andere containers.
Er zijn firewall rules ingesteld in Opnsense zodat alle DNS forced naar Opnsense gaat mocht er een toestel zijn die hardcoded DNS heeft.

AdGuardHome is ingesteld met Quad9 upstream server.
Maar ik zou ook graag hebben dat dit via Unbound gaat en niet meer via Quad9.

Wat heb ik gedaan:
Firewall rules tijdelijk uitgeschakeld.
Nieuwe LXC container waar Unbound in draait opgezet via gekende Proxmox Helper scripts.
In AGH upstream ingesteld van die Unbound > werkt perfect.

Waar loopt het mis:
Zodra ik de firewall rules inschakel zie ik in de querylog in AGH alle requests "refused".
Alias aangemaakt met DNS servers van Opnsense router + IP van AGH.
In de firewall rule dan Destination deze geselecteerd > lukt nog niet.

Mijn vraag: kan dit überhaupt wel wat ik wil opzetten?


Hier screenshots van de firewall.

[Kabouterplop01]

TheCeet schreef op zaterdag 23 augustus 2025 @ 21:05:
Wie kan me helpen met hetvolgende:

Setup:
PC1: OpnSense met Unbound DNS.
PC2: Proxmox: LXC AdGuard Home en andere containers.
Er zijn firewall rules ingesteld in Opnsense zodat alle DNS forced naar Opnsense gaat mocht er een toestel zijn die hardcoded DNS heeft.

AdGuardHome is ingesteld met Quad9 upstream server.
Maar ik zou ook graag hebben dat dit via Unbound gaat en niet meer via Quad9.

Wat heb ik gedaan:
Firewall rules tijdelijk uitgeschakeld.
Nieuwe LXC container waar Unbound in draait opgezet via gekende Proxmox Helper scripts.
In AGH upstream ingesteld van die Unbound > werkt perfect.

Waar loopt het mis:
Zodra ik de firewall rules inschakel zie ik in de querylog in AGH alle requests "refused".
Alias aangemaakt met DNS servers van Opnsense router + IP van AGH.
In de firewall rule dan Destination deze geselecteerd > lukt nog niet.

Mijn vraag: kan dit überhaupt wel wat ik wil opzetten?

Het zou best kunnen werken, maar ik denk dat het niet aan je firewall ligt.
Een firewall werkt op de ip en port laag. Als je refuseds krijgt op je AGH dan denk ik dat de firewall werkt, je krijgt immers antwoord van je AGH, dat betekent dat je requests aankomen op de AGH (dus er is IP connectivity) en de applicatie geeft antwoord (de port staat open en is bereikbaar)

Ik gok dat je op je AGH moet checken

[stormfly]

@TheCeet werkt AGH + Unbound wel goed als je het AGH IP hard in je client/PC zet? Heb je die setup onafhankelijk getest zonder PBR/re-direct rules?

https://www.reddit.com/r/...edirect_all_dns_requests/
https://forum.opnsense.org/index.php?topic=9245.0

Ik denk dat je nog wat rules mist, vooral de verplichte inverted rules, die heb jij wel staan maar naar 127.0.0.1? Nou ja de links zijn eerste google hits mijn advies. Wis alle config, test eest of AGH en Unbound samen als set goed werken zonder enige vorm van redirect en dan bouw je de redirect opnieuw. Als je Unbound wilt uitsluiten van de redirect, want die moet immers naar de root servers, dan moet je die met een regel boven de redirect 1:1 door laten gaan. FW rules werken top down

[nike]

@TheCeet
Ik heb het anders ingericht, wel via pfsense, maar volgens mij komt dat redelijk overeen.
eerst 2x firewall op het lan die je wil.
Dan een forward regel naar je adguard.

[TheCeet]

@stormfly
Ja dat werkt perfect.
AGH IP manueel in iPhone gezet > alles DNS gaat keurig via Unbound.

Het loopt pas mis als ik die firewall rules inschakel.
Dan lukt Unbound gedeelte niet meer + als ik test met 1.1.1.1 manueel in iPhone komt er ook geen data meer door.
Ik denk niet dat het aan AGH gedeelte ligt, maar wel aan de FW rules. En daar ontbreek ik toch wat kennis.
Het blijft voor mij 1 grote leerschool dit.

[Kabouterplop01]

Dan doet je firewall het goed en is er iets wat je in de rules moet bekijken.
Wat zegt je logfile? *status> systemlogs> tabje firewall

Ik zie dat je een specifieke richting "in" toe laat, maar moet er ook een terugweg worden allowed?

[ Voor 27% gewijzigd door Kabouterplop01 op 24-08-2025 22:15 ]

[TheCeet]

Ja ik ga wat documentatie opzoeken zodat het toch nog slim komt. Momenteel tast ik wat in het duister

[wian]

Je kan het ook simpeler maken. Adguard Home container uitzetten.

In OPNsense -> Unbound DNS -> Blocklist -> enable en een paar blocklists aanvinken onder "Type of DNSBL". Met OISD Big ben je in principe al klaar, maar je kan ook de AdGuard lijst aanvinken. Grote voordeel hiervan is dat je voor je basis netwerkvoorzieningen niet meer afhankelijk bent van een extra server. Nadeel is dat je geen mooie statistiekjes hebt.

[ThinkPad]

AGH kan ook prima op OPNsense draaien, is gewoon een 3rd party plugin voor! Mimugmail repository: https://www.routerperformance.net/opnsense-repo/

AGH draait hier ook in OPNsense, op een custom port (53530 ofzo). Unbound op default 53. En dan een NAT rule om clients te forceren naar die custom AGH port. En in AGH kun je dan 127.0.0.1:53 opgeven als upstream. Werkt prima.

[ Voor 18% gewijzigd door ThinkPad op 28-08-2025 23:07 ]

[TheCeet]

Bedankt voor de tips.
Ga ik zeker eens bekijken!

Heb toch liefst AGH omwille van de UI en de statistieken.

[Rolfie]

Ik heb AGH gewoon op 53 op Opnsense draaien en voor bepaalde informatie naar unbound forward icm een alternative port, dan voornamelijk de reverse lookup, of interne FQDN die ik gebruik.

Werkt perfect moet ik zeggen, al krijg ik nog wel errors met de DNS als ik een verbinding heb met mijn OpenVPN. Daar moet ik nog tijd aan besteden.
Ik wil ook een 2de AGH neerzetten en dan de config laten repliceren, zodat ik niet afhankelijk ben van 1 DNS server.

Maar de setup werkt wel goed en eigenlijk beter dan de unbound en dan blocklists.

[ Voor 18% gewijzigd door Rolfie op 29-08-2025 09:18 ]

[TheCeet]

Ja maar ik wil gewoon meer controle.
Als er nu iemand op zijn/haar toestel DNS server aanpast naar 1.1.1.1 kunnen ze daar gebruik van maken.
Dus ik wil alles forceren richting de eigen DNS server IP's. Vooral omdat ik merk dat de Android TV toch forced Google DNS wil bezoeken ipv mijn eigen DNS.

[eymey]

nike schreef op zaterdag 16 augustus 2025 @ 13:39:
Zijn er ook al mensen die nadenken om hun PFsense of Opensense doosje te vervangen voor een unify cloud fiber.
Zeker ook gezien de specs https://store.ui.com/us/e...-fiber/products/ucg-fiber
Wat ik dan nog zou missen is haproxy dus daar zou ik een aparte lxc container voor moeten bouwen.
Maar ja ik draai al zolang zelf pfsense met zoveel rules en vlans etc... dat het nog een hele klus word om het over te zetten.

Maar iets nieuws is ook leuk, en ik heb al switchen en AP's van unify.

Toevallig heb ik daar onlangs niet alleen over na gedacht, maar ook de stap echt gemaakt. Van OPNSense, gevirtualiseerd in een KVM VM op een Proxmox server, naar een UCG-Fiber!

Net als @RobertMe had ik voorheen ook een Unifi Security Gateway, in 2018, nadat ik ook al switches en AP's van Ubiquiti had gekocht. Maar ik was vrij snel erg teleurgesteld over de slechte instelbaarheid van basic dingen (vooral qua DHCP en DNS en andere zaken). En toen ben ik me gaan verdiepen in OPNSense. Toen ook een Shuttle DH310 met Core i3-8100 CPU en 16 GB RAM gekocht.

Die gevirtualiseerde OPNSense, samen met een Home Assistant OS VM en wat LXC containers op die Shuttle heeft sinds begin 2019, dus ruim 6 jaar, rete stabiel gedraaid! Enige downtime was vanwege upgrades, paar keer in huis verplaatsen vanwege grondige herindeling van de meterkast, etc.

Een paar maanden terug begon de NVME SSD jn de Shuttle SMART errors te geven (hij was dik door zijn gespecificeerde aantal geschreven terabytes heen) en ook de fannetjes op het koelblok begonnen steeds meer lawaai te maken en ik kreeg het niet meer gefixt met schoonmaken. Toen heb ik dus met veel speurwerk passende fannetjes ( 2x 6 CM, 1 CM dik én met PWM ) gevonden en ook een nieuwe SSD ingebouwd, Proxmox opnieuw geinstalleerd en de VMs en LXC containers geimporteerd.

Inmiddels wilde ik echter eigenlijk ook wel eens op zoek naar wat nieuws als vervanging voor de Shuttle, het liefst ook iets waar ik mijn glasvezel met SFP+ module direct in kwijt kon, ipv de losse TP-link mediaconverter. Maar kwam er al vrij snel achter, ook via het zuinige server topic, dat de spoeling qua zuinige netwerkkaarten met SFP+ poorten behoorlijk dun was (of erg duur).

Inmiddels had de Unifi Cloud Gateway - fiber zich aangediend en waren de reviews die ik erover heb gezien lovend. Ook de Unifi Network applicatie van de controller was inmiddels flink uitgebreid met veel meer instelbaarheid en features, Wireguard, etc. En gezien mijn ervaring met het repareren van de Shuttle en het internet dat ik er toen ook uit moest gooien, ookal duurde het hooguit een half dagje, leek het me ook wel weer 'leuk' om internettoegang gewoon weer op aparte hardware te doen.

Afgelopen week heb ik de daadwerkelijke migratie van OPNSense naar de UCG-Fiber gedaan. Ik loop nog wel tegen wat dingen aan die nu op de UCG toch meer moeite lijken te gaan kosten of 'tegen vallen' qua customizability. Bijvoorbeeld:

• Ingebouwde Ad Blocking via DNS alleen gebaseerd op (te agressieve) propietary block list, terwijl ik de voorkeur aan OISD geef. Dat heb ik nu opgelost door NextDNS als DNS-servers te gaan gebruiken, daar OISD te kiezen en NextDNS via DOH vanuit de UCG in te stellen. Misschien ooit nog een Pi-hole containertje, maar dan heeft het thuisnetwerk toch weer een afhankelijkheid op de server.
• Interface voor registreren van interne hostnames of vastzetten van IP's in DHCP nog wel wat omslachtig, maar functioneel.
• Wireguard server voor site to site tunnel tussen de Fritzbox van mijn ouders en mijn netwerk, plus wireguard voor 'road warriors' moet ik nog aan beginnen/uitzoeken.
• Stroomverbruik van de UCG-Fiber toch wat tegenvallend hoog (rond de 8 watt), wat deels gecompenseerd wordt door ~5W reductie in verbruik doordat de Shuttle 1 NIC en 1 VM minder actief heeft.
• MTU van 1500 voor de PPPoE tunnel moet nog steeds 'hacky' met custom scripts, ipv dat je dit gewoon kan instellen.

Over het algemeen denk ik dat ik er (nog) geen spijt van heb dat ik de overstap heb geprobeerd, maar we zullen het de komende tijd zien of ik zelfbouw met OPNSense toch best wel zal gaan missen of niet.

Voordeel is wel dat ik mijn hele netwerk nu in één beheer interface heb, wat ook prettiger is als er ooit wat met mij mocht gebeuren en iemand in onze omgeving die niet helemaal digibeet is, maar ook niet per se verstand heeft van mijn Proxmox setup, zou mijn gezin moeten helpen bij issues. Ook is de Shuttle, zeker met het recente onderhoud, weer klaar voor nog wat jaartjes mee gaan met meer reserve capaciteit.

[wian]

Als je tevreden bent met alleen de OISD - Big blocklist (ik ook!) kun je ook gratis ControlD gebruiken (gevonden op OISD).

code:

IPv4
76.76.2.32
76.76.10.32

IPv6
2606:1a40::32
2606:1a40:1::32

Super eenvoudige en lightweight manier om OISD DNS filtering toe te passen op routers/firewalls zonder plugins.

Ben benieuwd naar je ervaringen. Heb een tijdje terug de stap gemaakt naar een UCGUltra (en weer terug naar OPNsense), maar blijft toch aantrekkelijk om alles in unifi te hebben. Single pane of glass en minder tijd kwijt aan beheer.

[ Voor 20% gewijzigd door wian op 29-08-2025 15:43 ]

[Tom Paris]

TheCeet schreef op vrijdag 29 augustus 2025 @ 10:15:
Ja maar ik wil gewoon meer controle.
Als er nu iemand op zijn/haar toestel DNS server aanpast naar 1.1.1.1 kunnen ze daar gebruik van maken.
Dus ik wil alles forceren richting de eigen DNS server IP's. Vooral omdat ik merk dat de Android TV toch forced Google DNS wil bezoeken ipv mijn eigen DNS.

Dit is een kwestie van firewall regels, staat los van je DNS server / adblock tool.

[eymey]

wian schreef op vrijdag 29 augustus 2025 @ 15:38:
Als je tevreden bent met alleen de OISD - Big blocklist (ik ook!) kun je ook gratis ControlD gebruiken (gevonden op OISD).

code:

IPv4
76.76.2.32
76.76.10.32

IPv6
2606:1a40::32
2606:1a40:1::32

Super eenvoudige en lightweight manier om OISD DNS filtering toe te passen op routers/firewalls zonder plugins.

Ben benieuwd naar je ervaringen. Heb een tijdje terug de stap gemaakt naar een UCGUltra (en weer terug naar OPNsense), maar blijft toch aantrekkelijk om alles in unifi te hebben. Single pane of glass en minder tijd kwijt aan beheer.

Hmm, ook interessant! Ik had hem wel voorbij zien komen, maar kan uit de website niet zo goed opmaken wat nou precies "free" is en wanneer je moet betalen. Zie wel dat ze ook ook een URL in het dnscrypt-formaat "DNS Stamp" geven. Dat is fijn, want in de Ubiquiti Network interface voor het instellen van DoH moet je, bij het opgeven van een custom DoH server met custom block lists, de URL in dat formaat opgeven. Alle bekende DNS providers zijn ook gewoon selecteren, maar je kan dan niet configureren met welke blocklist je ze wil laten werken.

Als ik wat meer ervaring heb zal ik deze wel eens delen de Ubiquiti-relateerde topcreeks (die is er vast )