Zelfbouw project: Firewall / Router / AP

[Uberprutser]

float schreef op maandag 5 juli 2021 @ 19:31:
- iBOX-1115G4E (https://www.asrockind.com/en-gb/iBOX-1115G4E)
- DS10U3 (https://www.shuttle.eu/en/products/slim/ds10u3)
- Intel® NUC 11 Pro Kit NUC11TNHi30L (https://www.intel.com/con...hi30l/specifications.html) (niet fanless)

Mijn ervaring met ULV CPUs is wel dat wanneer je in low-power of balanced mode draait, ze maar langzaam de clocksnelheid verhogen. Waar ik het vooral aan merk is de opbouw van down/upload snelheden. Wanneer je in high-performance mode draait dan is het spot on maar het verbruik en de warmteontwikkeling ook een stukje hoger.

Misschien is dit met de nieuwste generatie CPUs beter maar tot de 7e gen Intel heb ik dit gezien.
Aardig wat boardjes e.d. getest afgelopen jaren.

[ Voor 9% gewijzigd door Uberprutser op 06-07-2021 09:16 ]

[Tom Paris]

stormfly schreef op maandag 5 juli 2021 @ 19:38:
IPTV van KPN lijkt niet goed om te gaan met 1 NIC router on a stick ontwerp.

Waarom niet? Werkt hier al 5 jaar feilloos

[wilbert11]

float schreef op maandag 5 juli 2021 @ 19:31:
Wat denken jullie van de volgende toestellen als firewall (debian) met inbegrip van VPN, (gateway) routing, DNS, DHCP en filtering (in de zin van de gekende pihole, dnsbl, pfblockerng) voor in een patchkast?

De lijn is momenteel een 300 Mbps download en 30 Mbps upload, maar moet bij voorkeur ook hogere snelheden aankunnen (lijnsnelheid 1000 Mbps download en 50 Mbps upload).

Het lijkt mij (meer dan) voldoende, misschien zelfs overkill, om een core i3 daarvoor te hebben. Ik ben helaas wat gebonden door mijn keuzes: kwaliteit gaat voor op de prijs (minstens verkrijgbaar in EU (geen bestellingen buiten de EU) en geen Protectli, Qotom, en alle varianten daarop), laag energieverbruik, intel NIC (minstens 2)

- iBOX-1115G4E (https://www.asrockind.com/en-gb/iBOX-1115G4E)
- DS10U3 (https://www.shuttle.eu/en/products/slim/ds10u3)
- Intel® NUC 11 Pro Kit NUC11TNHi30L (https://www.intel.com/con...hi30l/specifications.html) (niet fanless)

Wat denken jullie? Bedankt voor de inzichten en alternatieven :-)

Ik gebruik zelf de NUC 11 Pro kit met dual NIC en een i5. Die bevalt goed.

Op dit moment heb ik er Proxmox 7.0 (Debian bullseye) op draaien met Opnsense (VM) en Adguard home (LXC) HomeAssistant (VM).

Ik heb een KPN pppoe (IPv4) en DHCP (IPv6) verbinding 200/200 Mbps. In Opnsense gebruik ik ook de wireguard en suricata pakketten.

[ Voor 4% gewijzigd door wilbert11 op 06-07-2021 16:31 ]

[stormfly]

Tom Paris schreef op dinsdag 6 juli 2021 @ 11:35:
[...]


Waarom niet? Werkt hier al 5 jaar feilloos

Er ontbreken wat feiten in je post om mij te overtuigen na 2 weken troubleshooten, kan je iets meer delen?

[stormfly]

wilbert11 schreef op dinsdag 6 juli 2021 @ 11:35:
[...]


Ik gebruik zelf de NUC 11 Pro kit met dual NIC en een i5. Die bevalt goed.

Op dit moment heb ik er Proxmox 7.0-beta (Debian bullseye) op draaien met Opnsense (VM) en Adguard home (LXC) HomeAssistant (VM).

Ik heb een KPN pppoe (IPv4) en DHCP (IPv6) verbinding 200/200 Mbps. In Opnsense gebruik ik ook de wireguard en suricata pakketten.

Jouw OPNsense VM draait ook gevirtualiseerd? Meerdere NIC's om IPTV werkend te krijgen?

[Tom Paris]

stormfly schreef op dinsdag 6 juli 2021 @ 11:50:
[...]


Er ontbreken wat feiten in je post om mij te overtuigen na 2 weken troubleshooten, kan je iets meer delen?

Evenals er feiten ontbreken in jouw post dat het niet werkt

Vanaf FTU kabel in managed switch, VLANs 4 en 6 tagged op die poort. Van switch naar pfSense 1 kabel met VLANs 4, 6 en 10 tagged (10 is een voorbeeld, kan alles zijn). Alle overige poorten op VLAN 10 untagged.

In pfSense 3 interfaces aanmaken op VLANs 4 (IPTV), 6 (PPPoE) en 10 (LAN). Daarna kun je 'gewoon' het routed IPTV verhaal uitrollen, voor pfSense maakt het niet uit of die interfaces fysiek zijn of dat ze via VLANs een enkele fysieke poort delen. Zorg wel dat je op je switch IGMP snooping aanzet op poorten die verbinden met je FTU en pfSense. Je kunt dit uiteraard nog verder segmenteren met extra VLANs mocht je willen.

[stormfly]

Tom Paris schreef op dinsdag 6 juli 2021 @ 12:06:
[...]


Evenals er feiten ontbreken in jouw post dat het niet werkt

Vanaf FTU kabel in managed switch, VLANs 4 en 6 tagged op die poort. Van switch naar pfSense 1 kabel met VLANs 4, 6 en 10 tagged (10 is een voorbeeld, kan alles zijn). Alle overige poorten op VLAN 10 untagged.

In pfSense 3 interfaces aanmaken op VLANs 4 (IPTV), 6 (PPPoE) en 10 (LAN). Daarna kun je 'gewoon' het routed IPTV verhaal uitrollen, voor pfSense maakt het niet uit of die interfaces fysiek zijn of dat ze via VLANs een enkele fysieke poort delen. Zorg wel dat je op je switch IGMP snooping aanzet op poorten die verbinden met je FTU en pfSense. Je kunt dit uiteraard nog verder segmenteren met extra VLANs mocht je willen.

Is hij dan native met pfSense geinstalleerd, welke hardware is het?

[Tom Paris]

stormfly schreef op dinsdag 6 juli 2021 @ 12:31:
[...]


Is hij dan native met pfSense geinstalleerd, welke hardware is het?

Nee, VM in ESXi op een NUC. Maar dat is hetzelfde principe, middels een trunk poort alle VLANs doorzetten naar de pfSense VM en daar opsplitsen naar interfaces per VLAN. Heb het ook 'native' gedraaid op verschillende hardware, de configuratie in pfSense maakt geen verschil, je hebt alleen net dat extra laagje complexiteit van je hypervisor/vSwitch.

[stormfly]

Tom Paris schreef op dinsdag 6 juli 2021 @ 13:02:
[...]


Nee, VM in ESXi op een NUC. Maar dat is hetzelfde principe, middels een trunk poort alle VLANs doorzetten naar de pfSense VM en daar opsplitsen naar interfaces per VLAN. Heb het ook 'native' gedraaid op verschillende hardware, de configuratie in pfSense maakt geen verschil, je hebt alleen net dat extra laagje complexiteit van je hypervisor/vSwitch.

Interessant, ik ben blij dat het nu werkt hier. Je zou nog wat screenshots mogen delen als je zin hebt, kan ik nog eens kijken of ik wat gemist heb.

[wilbert11]

stormfly schreef op dinsdag 6 juli 2021 @ 11:55:
[...]


Jouw OPNsense VM draait ook gevirtualiseerd? Meerdere NIC's om IPTV werkend te krijgen?

Ja OPNSENSE is gevirtualiseerd. Ik heb geen IPTV van KPN. Ik heb 1 NIC voor LAN en 1 NIC voor WAN. Je kan het ook met 1 NIC doen.

[eymey]

stormfly schreef op dinsdag 6 juli 2021 @ 11:55:
[...]


Jouw OPNsense VM draait ook gevirtualiseerd? Meerdere NIC's om IPTV werkend te krijgen?

Ik zou eigenlijk niet zo goed weten waarom IPTV over een "1 nic setup" niet zou werken. Zolang je een goede VLAN-capable switch hebt die multicastverkeer gewoon netjes binnen het VLAN voor LAN houdt, dan is er technisch geen reden waarom het niet zou kunnen werken (maar mogelijk dat sommige 'router on stick' devices / chipsets het daar laten afweten?).

[stormfly]

eymey schreef op dinsdag 6 juli 2021 @ 13:38:
[...]


Ik zou eigenlijk niet zo goed weten waarom IPTV over een "1 nic setup" niet zou werken. Zolang je een goede VLAN-capable switch hebt die multicastverkeer gewoon netjes binnen het VLAN voor LAN houdt, dan is er technisch geen reden waarom het niet zou kunnen werken (maar mogelijk dat sommige 'router on stick' devices / chipsets het daar laten afweten?).

Het draait virtueel op een NUC, de onderliggende switch laag komt nog steeds op 1 NIC uit. Zowel fysiek als virtueel.

pfSense:
Virtueel met losse NIC's =OK
Fysiek met 1 NIC = wel MC stream maar enorm hakkelend

OPNsense
Virtueel met losse NIC's = OK
Fysiek met 1 NIC = geen enkele MC stream komt op gang.

Ik heb er gigantisch veel uren in zitten, tientallen topics gelezen, er heeft nooit een MCstream door OPNsense router on a stick gedraaid. Waarom pfSense dan welk de stream opzet maar het enorm hakkelt kan ik niet verklaren.

---

Ik zal mijn troubleshoot topic eens delen. Nu begrijp ik ook dat @Tom Paris aangaf dat ik te weinig info deelde, in dat ander topic heb ik 2 boeken vol geschreven.

de grote OPNsense KPN/Telfort IPTV how-to

[ Voor 4% gewijzigd door stormfly op 06-07-2021 13:56 ]

[Tom Paris]

Het klinkt een probleem met je IGMP snooping. Welke switch gebruik je en hoe heb je die ingericht? En is het een NUC met Intel NIC of Realtek?

[eymey]

@stormfly vooropgesteld: Het is alweer een tijdje geleden dat ik voor het laatst OPNSense (gevirtualiseerd) draaide terwijl ik IPTV in mijn abonnement had (bij Tweak, maar globaal werkte dat ongeveer hetzelfde als met KPN IPTV of aanverwanten). Ik draai inmiddels alweer een jaar of 2 met televisie uitsluitend Over The Top.

Wat ik in je topic mis, is hoe je het routeren van de IGMP streams uberhaupt hebt gedaan. Ik draaide destijds IGMPProxy, als schakel tussen het VLAN waar de STB in zat en het IPTV WAN (VLAN 4). Maar ik heb het ook niet helemáál doorgenomen.

Ik heb zelf ook nooit single NIC geprobeerd te draaien en ik kan me best voorstellen dat er NIC's of besturingssystemen zijn waarin dit compleet in de war gaat.

Maar theoretisch, als je op die single NIC gewoon alles strict met VLAN tags gescheiden houdt en je goede IGMP snooping hebt, dan zou het gewoon goed moeten kunnen gaan.

Maar ja, theorie en praktijk liggen soms mijlenver uit elkaar .

Sowieso is single NIC voor mij hier ook niet van toepassing, met een 1 Gbps verbinding en 1 Gbps apparatuur

[ Voor 4% gewijzigd door eymey op 06-07-2021 15:41 ]

[Theone098]

Tom Paris schreef op dinsdag 6 juli 2021 @ 14:02:
Het klinkt een probleem met je IGMP snooping. Welke switch gebruik je en hoe heb je die ingericht? En is het een NUC met Intel NIC of Realtek?

Ik gok ook igmp snooping. De virtuele laag zorgt er waarschijnlijk voor dat het verkeer automatisch in goede banen wordt geleid. Dat heb je niet op bare metal. Dan zul je in de eerstvolgende switch IGMP snooping moeten aanzetten.

[ Voor 5% gewijzigd door Theone098 op 06-07-2021 17:15 . Reden: Raar maar waar.... er zijn intel nuc's met realtek nics 8)7 ]

[float]

Uberprutser schreef op dinsdag 6 juli 2021 @ 09:15:
[...]

Mijn ervaring met ULV CPUs is wel dat wanneer je in low-power of balanced mode draait, ze maar langzaam de clocksnelheid verhogen. Waar ik het vooral aan merk is de opbouw van down/upload snelheden. Wanneer je in high-performance mode draait dan is het spot on maar het verbruik en de warmteontwikkeling ook een stukje hoger.

Misschien is dit met de nieuwste generatie CPUs beter maar tot de 7e gen Intel heb ik dit gezien.
Aardig wat boardjes e.d. getest afgelopen jaren.

wilbert11 schreef op dinsdag 6 juli 2021 @ 11:35:
[...]


Ik gebruik zelf de NUC 11 Pro kit met dual NIC en een i5. Die bevalt goed.

Op dit moment heb ik er Proxmox 7.0 (Debian bullseye) op draaien met Opnsense (VM) en Adguard home (LXC) HomeAssistant (VM).

Ik heb een KPN pppoe (IPv4) en DHCP (IPv6) verbinding 200/200 Mbps. In Opnsense gebruik ik ook de wireguard en suricata pakketten.

@wilbert11 Heb jij iets gemerkt op dat vlak (zie reactie van @Uberprutser)?

[stormfly]

eymey schreef op dinsdag 6 juli 2021 @ 15:40:
@stormfly vooropgesteld: Het is alweer een tijdje geleden dat ik voor het laatst OPNSense (gevirtualiseerd) draaide terwijl ik IPTV in mijn abonnement had (bij Tweak, maar globaal werkte dat ongeveer hetzelfde als met KPN IPTV of aanverwanten). Ik draai inmiddels alweer een jaar of 2 met televisie uitsluitend Over The Top.

Wat ik in je topic mis, is hoe je het routeren van de IGMP streams uberhaupt hebt gedaan. Ik draaide destijds IGMPProxy, als schakel tussen het VLAN waar de STB in zat en het IPTV WAN (VLAN 4). Maar ik heb het ook niet helemáál doorgenomen.

Ik heb zelf ook nooit single NIC geprobeerd te draaien en ik kan me best voorstellen dat er NIC's of besturingssystemen zijn waarin dit compleet in de war gaat.

Maar theoretisch, als je op die single NIC gewoon alles strict met VLAN tags gescheiden houdt en je goede IGMP snooping hebt, dan zou het gewoon goed moeten kunnen gaan.

Maar ja, theorie en praktijk liggen soms mijlenver uit elkaar .

Sowieso is single NIC voor mij hier ook niet van toepassing, met een 1 Gbps verbinding en 1 Gbps apparatuur

@ik222 @Coolhva @Tom Paris

Net nog even getest, immers op een VM OPNsense kan je heel gemakkelijk schakelen van losse interface naar een vlan interface. Het is 100% te reproduceren, zodra vlan 4 op de trunk terecht komt blijft de huidige tv stream doorlopen maar zappen lukt niet.

Dat is ook terug te zien in de captures, igmp join requests komen nooit meer aan op VLAN4 die worden niet meer geforward.

Op het moment dat je vlan 4 weer terugzet naar een normale losse NIC is alles instant hersteld. Het heeft vrijwel niets met IGMP snooping te maken, het gaat mis met de IGMP joins.

https://www.dropbox.com/s...zIsLhWiyTNpIhdUmJBSa?dl=0

[Tom Paris]

Eerder zei je "Fysiek met 1 NIC = geen enkele MC stream komt op gang", dat is nu dus ook "Virtueel met Trunk"

Dan blijf ik er bij dat er waarschijnlijk iets verkeerd zit in je switch. Als de vSwitch van je hypervisor er tussen zit gaat het kennelijk wel goed, dus die doet nog iets met je queries/joins.

[stormfly]

Tom Paris schreef op dinsdag 6 juli 2021 @ 21:20:
Eerder zei je "Fysiek met 1 NIC = geen enkele MC stream komt op gang", dat is nu dus ook "Virtueel met Trunk"

Dan blijf ik er bij dat er waarschijnlijk iets verkeerd zit in je switch. Als de vSwitch van je hypervisor er tussen zit gaat het kennelijk wel goed, dus die doet nog iets met je queries/joins.

Nee de switchlaag doet alles prima, die zou anders ook falen met de huidige setup. Of het nu virtueel is of fysiek het komt altijd met vlans op 1 NIC binnen op de switch. Vanuit ESXi is het nu ook slechts 1 NIC en draait het prima

Om het feitelijk te onderbouwen, dit is tijdens de defecte situatie waarbij ik niet kan zappen. Uit mijn KAN (beneden) komen deze IGMP's via de backbone gewoon aan in het datacenter boven.




Kijk je daarna op vlan 4 is het akelig stil



Bekijken we datzelfde gedrag met een losse vlan 4 interface op het LAN




Dan komen deze IGMP joins (zappen) keurig aan op het WAN.

Dit is gesnifferd op OPNsense, het komt in de foute situatie keurig aan uit het STB vlan, maar het wordt nooit meer doorgezet naar het WAN. Ik neig naar een igmp-proxy defect.

[ Voor 37% gewijzigd door stormfly op 06-07-2021 21:34 ]

[Tom Paris]

stormfly schreef op dinsdag 6 juli 2021 @ 21:28:
Ik neig naar een igmp-proxy defect.

Dat is een mogelijkheid... Maar dan zou je het in pfSense wel werkend moeten krijgen, want hier draait het zonder problemen op 2.5.0 / 2.5.1 / 2.5.2 RC. Zowel virtueel met Trunk in ESXi als 'native'.

[ANdrode]

Uberprutser schreef op dinsdag 6 juli 2021 @ 09:15:
[...]

Mijn ervaring met ULV CPUs is wel dat wanneer je in low-power of balanced mode draait, ze maar langzaam de clocksnelheid verhogen. Waar ik het vooral aan merk is de opbouw van down/upload snelheden. Wanneer je in high-performance mode draait dan is het spot on maar het verbruik en de warmteontwikkeling ook een stukje hoger.

Misschien is dit met de nieuwste generatie CPUs beter maar tot de 7e gen Intel heb ik dit gezien.
Aardig wat boardjes e.d. getest afgelopen jaren.

Misschien een windows artifact?

Vanaf skylake zouden ze binnen ~15ms van laagste -> hoge snelheid moeten wisselen. Bij Haswell ~120ms (https://www.anandtech.com...ore-responsive-processors). Ik denk dat er een ander effect mee moet spelen.

Bij linux merk ik in ieder geval geen vertraging

[Uberprutser]

ANdrode schreef op dinsdag 6 juli 2021 @ 21:46:
[...]
Misschien een windows artifact?

Was een reden om ULV dozen eruit te keilen en alleen nog met Atom / Xeon te werken. Hiermee geen van deze issues gezien.

[eymey]

stormfly schreef op dinsdag 6 juli 2021 @ 20:16:
[...]


@ik222 @Coolhva @Tom Paris

Net nog even getest, immers op een VM OPNsense kan je heel gemakkelijk schakelen van losse interface naar een vlan interface. Het is 100% te reproduceren, zodra vlan 4 op de trunk terecht komt blijft de huidige tv stream doorlopen maar zappen lukt niet.

Dat is ook terug te zien in de captures, igmp join requests komen nooit meer aan op VLAN4 die worden niet meer geforward.

Op het moment dat je vlan 4 weer terugzet naar een normale losse NIC is alles instant hersteld. Het heeft vrijwel niets met IGMP snooping te maken, het gaat mis met de IGMP joins.

https://www.dropbox.com/s...zIsLhWiyTNpIhdUmJBSa?dl=0

Dan is het misschien toch een raar defect in IGMP Proxy of iets anders in de networking stack van FreeBSD.

[A1AD]

Hmm heb veel packetloss op mijn Yanling bakje met opnsense, kan je duidelijk zien via health op de WAN-interface. Soms tot 30sec loss!
Wanneer dit gebeurd werkt de routing tussen de verschillende vlans ook niet meer.

Ik gebruik dezelfde aansluitingen als mijne vorige router.



Het enige abnormale dat ik kan zien in de dmesg logs is:
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
... repeat

Iemand een idee?

[stormfly]

A1AD schreef op zaterdag 10 juli 2021 @ 21:26:
Hmm heb veel packetloss op mijn Yanling bakje met opnsense, kan je duidelijk zien via health op de WAN-interface. Soms tot 30sec loss!
Wanneer dit gebeurd werkt de routing tussen de verschillende vlans ook niet meer.

Ik gebruik dezelfde aansluitingen als mijne vorige router.

[Afbeelding]

Het enige abnormale dat ik kan zien in de dmesg logs is:
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
... repeat

Iemand een idee?

Ben je dan aan het tcpdump-en in promiscuous mode? Blijkbaar is er iets wat jouw interface naar promiscuous mode schakelt wat een hik tot gevolg heeft.

[A1AD]

stormfly schreef op zaterdag 10 juli 2021 @ 21:34:
[...]


Ben je dan aan het tcpdump-en in promiscuous mode? Blijkbaar is er iets wat jouw interface naar promiscuous mode schakelt wat een hik tot gevolg heeft.

Nee ik doe helemaal niets, bare minimum install.

[Yoshimi]

A1AD schreef op zaterdag 10 juli 2021 @ 21:26:
Hmm heb veel packetloss op mijn Yanling bakje met opnsense, kan je duidelijk zien via health op de WAN-interface. Soms tot 30sec loss!
Wanneer dit gebeurd werkt de routing tussen de verschillende vlans ook niet meer.

Ik gebruik dezelfde aansluitingen als mijne vorige router.

[Afbeelding]

Het enige abnormale dat ik kan zien in de dmesg logs is:
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
... repeat

Iemand een idee?

Je schrijft bare minimum, als in “factory default”, dus zonder enige configuratie?
Indien je al verder bent gegaan met configureren: Heb je Suricata toevallig geactiveerd? Of firewall regels o.b.v. schedules?

[Mich]

Rayures schreef op maandag 7 juni 2021 @ 09:29:
kleine update mbt Partaker I29 Industrial Mini PC

Nu bijna 7 maanden uptime en gaat nog steeds als de brandweer :-) Aanrader.

Hier ook nog steeds. Nooit vastloper gehad. Temperaturen niet boven de 60 graden. Heb wel mijn eigen koelpasta er tussen gedaan

Vpn verbinding draait ook op 300mbit. (Op 300mbit verbinding). Cpu gebruik blijft onder de 10%

Moet nog steeds is gaan experimenteren met de IPS rules te activeren.

[Pietsnot56]

hi, ik zit met een vraag die al dan niet past in deze topic : Telenet 1G -Pfsence 2.5.2 (Yanling) - Openvpn 2.5.3 (win10).

Ik heb toevallig iets vastgesteld :
Bij het opbouwen van een Openvpn connectie naar een externe Nas Qnap valt de download snelheid van Telenet 1G terug op 13 à 15 Mb!
Verbreek ik de verbinding dan krijg ik terug 600 à 850Mb.
Is dit normaal?
Bij vorige versies van Pfsense heb ik weliswaar nooit die test gedaan, zodat ik niet kan besluiten of er een bug of een slechte instelling de boosdoener is.

Mijn toestellen en soft zijn wel up to date.

Gelukkig dien ik de vpn connectie maar sporadisch te doen, maar tijdens zulke sessie zullen de overige gebruikers wel gestoord zijn.

[Mschamp]

Pietsnot56 schreef op zondag 11 juli 2021 @ 11:23:
hi, ik zit met een vraag die al dan niet past in deze topic : Telenet 1G -Pfsence 2.5.2 (Yanling) - Openvpn 2.5.3 (win10).

Ik heb toevallig iets vastgesteld :
Bij het opbouwen van een Openvpn connectie naar een externe Nas Qnap valt de download snelheid van Telenet 1G terug op 13 à 15 Mb!
Verbreek ik de verbinding dan krijg ik terug 600 à 850Mb.
Is dit normaal?
Bij vorige versies van Pfsense heb ik weliswaar nooit die test gedaan, zodat ik niet kan besluiten of er een bug of een slechte instelling de boosdoener is.

Mijn toestellen en soft zijn wel up to date.

Gelukkig dien ik de vpn connectie maar sporadisch te doen, maar tijdens zulke sessie zullen de overige gebruikers wel gestoord zijn.

En wat is de internetverbinding aan de andere kant van je VPN?
Mogelijk gaat al je verkeer door je VPN (hangt af van instellingen), als daar de up& download lager is, is dat je bottleneck. (al je internetverkeer gaat daar dan door de up&download).
Als andere kant een 150 down/15up verbinding is, dan is de oorzaak gevonden

[ Voor 3% gewijzigd door Mschamp op 11-07-2021 11:39 ]

[Pietsnot56]

Misschien dien ik iets te verduidelijken.
Bij een Telenet speedtest zonder vpn connectie haal ik +- 600 à 800 Mb, al naargelang. Bij Fast of Ookla zelfs meer.
Na het opbouwen van de vpn connectie (die werkt) kreeg ik toevallig klachten van andere gebruikers dat internet "traag" was. Bij de speedtest leek de bandbreedte teruggevallen op +- 15Mb.
Bij het verbreken krijg ik de normale snelheid terug.

Ik zie niet goed in dat de verbinding tussen 1 pc en de externe Nas hier iets mee te maken heeft. De uploadsnelheid aan de nas zijde is inderdaad de beperkende faktor tussen de verbinding Pc - Nas..
Maar de overige gebruikers op mijn netwerk hebben daar toch niks mee te maken.

Processor gebruik op de Pfsense 2.5.2 (Yangling) varieert tussen 6% en 9%. Bij de VPN connectie vanuit een win10 pc stijgt dit nauwelijks, misschien 1 à 2 % meer, zelfs als ik met explorer de directory's op de nas aflees..

Hieruit zou ik durven afleiden dat niet de router aan de oorsprong van die terugval in snelheid ligt.

[nero355]

Pietsnot56 schreef op zondag 11 juli 2021 @ 12:41:
Processor gebruik op de Pfsense 2.5.2 (Yangling) varieert tussen 6% en 9%. Bij de VPN connectie vanuit een win10 pc stijgt dit nauwelijks, misschien 1 à 2 % meer, zelfs als ik met explorer de directory's op de nas aflees..

Hieruit zou ik durven afleiden dat niet de router aan de oorsprong van die terugval in snelheid ligt.

Welke CPU zit er in je Yangling

Gebruik je AES-NI voor de VPN of doe je alles over de CPU heen ??

Ik weet namelijk niet of je AES-NI offloading ook als CPU Usage kan zien...
En bij bepaalde instructies clocken sommige processoren zich terug om binnen hun TDP budget te blijven en ik weet niet of bij AES-NI dat ook het geval is ?!

Wat ook misschien interessant is : Hoe bouw je de verbinding op met je ISP
Misschien zit je te tunnellen door een tunnel heen en moet je met de MTU gaan spelen

[A1AD]

Yoshimi schreef op zondag 11 juli 2021 @ 09:49:
[...]


Je schrijft bare minimum, als in “factory default”, dus zonder enige configuratie?
Indien je al verder bent gegaan met configureren: Heb je Suricata toevallig geactiveerd? Of firewall regels o.b.v. schedules?

Geen IDS/IPS of schedules. Bare minimum om mijn netwerkt draaiende te houden. Zo weinig mogelijk services.

[Samplex]

Pietsnot56 schreef op zondag 11 juli 2021 @ 12:41:
Misschien dien ik iets te verduidelijken.
Bij een Telenet speedtest zonder vpn connectie haal ik +- 600 à 800 Mb, al naargelang. Bij Fast of Ookla zelfs meer.
Na het opbouwen van de vpn connectie (die werkt) kreeg ik toevallig klachten van andere gebruikers dat internet "traag" was. Bij de speedtest leek de bandbreedte teruggevallen op +- 15Mb.
Bij het verbreken krijg ik de normale snelheid terug.

Ik zie niet goed in dat de verbinding tussen 1 pc en de externe Nas hier iets mee te maken heeft. De uploadsnelheid aan de nas zijde is inderdaad de beperkende faktor tussen de verbinding Pc - Nas..
Maar de overige gebruikers op mijn netwerk hebben daar toch niks mee te maken.

Processor gebruik op de Pfsense 2.5.2 (Yangling) varieert tussen 6% en 9%. Bij de VPN connectie vanuit een win10 pc stijgt dit nauwelijks, misschien 1 à 2 % meer, zelfs als ik met explorer de directory's op de nas aflees..

Hieruit zou ik durven afleiden dat niet de router aan de oorsprong van die terugval in snelheid ligt.

Wat apart, als ik download dan zit de cpu al gelijk op 30/40% (ook yanling) , jij haalt 8/9% dat lijkt me voorbarig.

[A1AD]

Dit is echt niet te doen dit



Wat een drama

Edit:
De timeouts lopen duidelijk samen met dit:
2021-07-11T19:53:54 kernel pflog0: promiscuous mode disabled
2021-07-11T19:53:47 kernel pflog0: promiscuous mode enabled
2021-07-11T19:53:47 kernel pflog0: promiscuous mode disabled

[ Voor 25% gewijzigd door A1AD op 11-07-2021 19:55 ]

[Tom Paris]

Pietsnot56 schreef op zondag 11 juli 2021 @ 12:41:
Misschien dien ik iets te verduidelijken.
Bij een Telenet speedtest zonder vpn connectie haal ik +- 600 à 800 Mb, al naargelang. Bij Fast of Ookla zelfs meer.
Na het opbouwen van de vpn connectie (die werkt) kreeg ik toevallig klachten van andere gebruikers dat internet "traag" was. Bij de speedtest leek de bandbreedte teruggevallen op +- 15Mb.
Bij het verbreken krijg ik de normale snelheid terug.

Ik zie niet goed in dat de verbinding tussen 1 pc en de externe Nas hier iets mee te maken heeft. De uploadsnelheid aan de nas zijde is inderdaad de beperkende faktor tussen de verbinding Pc - Nas..
Maar de overige gebruikers op mijn netwerk hebben daar toch niks mee te maken.

Processor gebruik op de Pfsense 2.5.2 (Yangling) varieert tussen 6% en 9%. Bij de VPN connectie vanuit een win10 pc stijgt dit nauwelijks, misschien 1 à 2 % meer, zelfs als ik met explorer de directory's op de nas aflees..

Hieruit zou ik durven afleiden dat niet de router aan de oorsprong van die terugval in snelheid ligt.

Bedoel je nou dat je op de PC de OpenVPN verbinding opbouwt? Of toch op pfSense maar routeer je het verkeer van alleen die ene pc door de tunnel?

[Tom Paris]

A1AD schreef op zondag 11 juli 2021 @ 19:41:
Dit is echt niet te doen dit

[Afbeelding]

Wat een drama

Edit:
De timeouts lopen duidelijk samen met dit:
2021-07-11T19:53:54 kernel pflog0: promiscuous mode disabled
2021-07-11T19:53:47 kernel pflog0: promiscuous mode enabled
2021-07-11T19:53:47 kernel pflog0: promiscuous mode disabled

Op het Opnsense forum zie je dit probleem wel vaak terugkomen...

Loopt uiteen van offload settings tot defecte hardware als ik het zo even scan.

[A1AD]

Tom Paris schreef op zondag 11 juli 2021 @ 20:19:
[...]


Op het Opnsense forum zie je dit probleem wel vaak terugkomen...

Loopt uiteen van offload settings tot defecte hardware als ik het zo even scan.

Jep, maar niet echt een oplossing...

[Pietsnot56]

Antwoorfd op nero355:

Versie 2.5.2-RELEASE (amd64)
Gebouwd op Fri Jul 02 15:33:00 EDT 2021
FreeBSD 12.2-STABLE

Het systeem heeft de nieuwste versie.
Versie-informatie is bijgewerkt op Sun Jul 11 20:16:14 CEST 2021
CPU Type Intel(R) Celeron(R) CPU J3160 @ 1.60GHz
4 CPU's: 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
QAT Crypto: No
Hardware cryptografie AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS
Kernel PTI Ingeschakeld
MDS Mitigation Inactive
Uptime 1 Day 00 Hour 16 Minutes 01 Seconds
Huidige Datum/Tijd
Sun Jul 11 20:22:32 CEST 2021
DNS server(s)
127.0.0.1
1.1.1.1
1.0.0.1
Laatste configuratie wijziging Sat Jul 10 20:08:46 CEST 2021
State Tabel grootte
0% (223/1632000) Toon states
MBUF Gebruik
1% (12616/1000000)
Temperatuur
55.0°C
Gemiddelde belasting
0.57, 0.46, 0.46
Processor gebruik
6%
Geheugen gebruik
20% of 8040 MiB
SWAP gebruik
0% of 2689 MiB
Disk usage:
/
12%of55GiB - ufs
/var/run
5%of3.4MiB - ufs in RAM

Vpn:

Data Ciphers: AES-128-GCM, AES-128-CBC, AES-256-GCM
Digest: SHA256
D-H Params: 2048 bits

Ik bouw de vpn op vanaf een win10 pc. Dit is de enige verbinding.
Deze enkele vpn verbinding werkt aan een “normale, aanvaardbare” snelheid.
Om voor mij nog niet duidelijke reden trekt dit wel de de verbinding met de isp dramatisch naar beneden.
Vandaar de klacht van andere gebruikers en mijn toevallige vaststelling dat de terugval in snelheid onweerlegbaar gerelateerd is aan de openvpn verbinding.

[ANdrode]

A1AD schreef op zondag 11 juli 2021 @ 19:41:
De timeouts lopen duidelijk samen met dit:
2021-07-11T19:53:54 kernel pflog0: promiscuous mode disabled
2021-07-11T19:53:47 kernel pflog0: promiscuous mode enabled
2021-07-11T19:53:47 kernel pflog0: promiscuous mode disabled

Heb je iets van offloading aan staan (op de NIC of voor NAT)? Stap 1 is in zo'n geval vaak om zulke opties uit te zetten en te hopen dat het verschil maakt

offtopic:
Herinner mij dit rondom hardware checksumming en oid i8576 op linux. Wij hadden er korte productiedowntimes door

[ Voor 4% gewijzigd door ANdrode op 11-07-2021 21:14 ]

[A1AD]

ANdrode schreef op zondag 11 juli 2021 @ 21:14:
[...]


Heb je iets van offloading aan staan (op de NIC of voor NAT)? Stap 1 is in zo'n geval vaak om zulke opties uit te zetten en te hopen dat het verschil maakt

offtopic:
Herinner mij dit rondom hardware checksumming en oid i8576 op linux. Wij hadden er korte productiedowntimes door

Nope, staat allemaal al uit.

[A1AD]

Het weinige haar dat ik nog heb begint stilaan toch ook uit te vallen... nu heb ik een NUCi5 waar ik opnsense wil opzetten zodat ik mijn HW van de huidige is goed kan testen, backup file aangemaakt op huidige FW-doos, maar de restore op de nieuwe doet gewoon niets...

[Pietsnot56]

De terugval van internetsnelheid bij openvpn lijkt verklaard.
Bij een opbouw van de vpn tunnel lijkt alle verkeer door de tunnel te gaan.
De speedtest verliep dus ook door de tunnel.
Nooit te oud om iets bij te leren.

[A1AD]

Ik heb ook iets gevonden, ik heb een vrij grote WireGuard config en na het uitzetten van wg krijg ik geen drop-outs en geen kernel pflog0: promiscuous mode enabled kernel pflog0: promiscuous mode disabled meer

Maar er is natuurlijk een reden waarom ik een grote WG config heb... 1 voor 1 de tunnels opzetten en bekijken waar het probleem zich juist voordoet dan maar.

(gebruikt momenteel de WG-GO)

[ Voor 4% gewijzigd door A1AD op 13-07-2021 10:28 ]

[stormfly]

Uitgangspunt: snappie internet, snel flitsende page loads

Ik ben benieuwd ik merk dat ik op de NUC7i3 met VMware op zich een prima router heb. Alleen als er een tv stream loopt van 8mbit dan merk ik dat hij de DNS requests wat minder snel afhandelt. Je ziet dat aan de page loads, ipv als one page komt het een fractie trager binnen.

Nu heb ik de ERX van UI teruggezet en die heeft hardware offloading, dat vliegt toch echt wel lekker door het internet. Vanavond even testen met de TV stream aan.

Ik was benieuwd of jullie ook zo kritisch naar de load kijken? De NUC heeft niet super veel CPU maar is toch ook wel krachtig te noemen?

Bijvoorbeeld een hypervisor als proxmox is deze lichter dan ESXi? of een native install van de NUC7i3 met OPNsense of pfSense?

Je kan geen polls meer plaatsen? Maar waar zitten jullie het meeste op, ik neig naar OPNsense deze is in de GUI zoveel sneller dan pfSense met het doen van wijzigingen en het gebruik van GEOip block lijsten is ook veel simpeler. Met pihole/adguard vang ik ads af, beide hebben WireGuard. Ik neig dan toch naar OPNsense vanwege het actieve patch beleid en het sneller opvolgen van bugs in Unbound etc.

[nero355]

stormfly schreef op woensdag 14 juli 2021 @ 13:39:
Ik ben benieuwd ik merk dat ik op de NUC7i3 met VMware op zich een prima router heb. Alleen als er een tv stream loopt van 8mbit dan merk ik dat hij de DNS requests wat minder snel afhandelt. Je ziet dat aan de page loads, ipv als one page komt het een fractie trager binnen.

En je weet zeker dat het niks met slecht of niet ingestelde IGMP Snooping te maken heeft

Nu heb ik de ERX van UI teruggezet en die heeft hardware offloading, dat vliegt toch echt wel lekker door het internet. Vanavond even testen met de TV stream aan.

Als je netwerk wordt verzopen met Multicast verkeer dan kan de router daar weinig aan doen...

Ik was benieuwd of jullie ook zo kritisch naar de load kijken? De NUC heeft niet super veel CPU maar is toch ook wel krachtig te noemen?

Welk model is het PRECIES
Wat zijn de volledige specificaties ?!

Bijvoorbeeld een hypervisor als proxmox is deze lichter dan ESXi? of een native install van de NUC7i3 met OPNsense of pfSense?

Ik zou twee keer JA willen zeggen, maar de eerste weet ik niet zeker en Proxmox heeft mijn voorkeur dus ik ben biased...

Je kan geen polls meer plaatsen?

Dat ging altijd via een externe website

Maar waar zitten jullie het meeste op, ik neig naar OPNsense deze is in de GUI zoveel sneller dan pfSense met het doen van wijzigingen en het gebruik van GEOip block lijsten is ook veel simpeler.

IMHO een persoonlijke kwestie die jij voor jezelf moet bepalen

Met pihole/adguard vang ik ads af, beide hebben WireGuard.

Dat kan ook allemaal vanuit pfSense met pfBlockerNG en natuurlijk de VPN featues die in pfSense zitten, maar persoonlijk vind ik Pi-Hole echt een geweldig stukje software qua beheer

Ik neig dan toch naar OPNsense vanwege het actieve patch beleid en het sneller opvolgen van bugs in Unbound etc.

Bugs in Unbound kunnen ook zo gepatched worden dat het minder opvalt dus hoe merk jij dat of zie jij dat precies

Daarnaast kan je ook Unbound i.c.m. Pi-Hole draaien : https://docs.pi-hole.net/guides/dns/unbound/

[stormfly]

nero355 schreef op woensdag 14 juli 2021 @ 18:26:

En je weet zeker dat het niks met slecht of niet ingestelde IGMP Snooping te maken heeft

Nee het is een unicast stream

Als je netwerk wordt verzopen met Multicast verkeer dan kan de router daar weinig aan doen...

Unicast NLziet

Welk model is het PRECIES
Wat zijn de volledige specificaties ?!

NUC6i5syh i5-6260U
NUC7i3bnk 3-7100U

Ik zou twee keer JA willen zeggen, maar de eerste weet ik niet zeker en Proxmox heeft mijn voorkeur dus ik ben biased...

IMHO een persoonlijke kwestie die jij voor jezelf moet bepalen

Als ik zou moeten kiezen denk ik dat OPNsens het gaat winnen hier thuis ;-)

Bugs in Unbound kunnen ook zo gepatched worden dat het minder opvalt dus hoe merk jij dat of zie jij dat precies

Ik las dat op de frontpage dat iemand aangaf dat OPNsense een veel actiever patch beleid heeft, trekt mij wel.

Daarnaast kan je ook Unbound i.c.m. Pi-Hole draaien : https://docs.pi-hole.net/guides/dns/unbound/

Och ja er draaien hier al 2 dockers met unbound die twee PiHole dockers voorziet van upstream data, mooi redundant. Pihole gui is met het dark theme gewoon vet.

[Tom Paris]

stormfly schreef op woensdag 14 juli 2021 @ 19:45:
Ik las dat op de frontpage dat iemand aangaf dat OPNsense een veel actiever patch beleid heeft, trekt mij wel.

Ah ja dan is het waar

OPNsense test weinig maar brengt snel opvolgende releases uit, pfSense releast minder vaak maar test meer gedegen (buiten recente uitglijder met Wireguard-in-kernel om dan...). Als er een security patch is, ook van een extern pakket als Unbound is, brengt pfSense ook gewoon direct een update uit.

[stormfly]

Tom Paris schreef op woensdag 14 juli 2021 @ 20:55:
[...]


Ah ja dan is het waar

OPNsense test weinig maar brengt snel opvolgende releases uit, pfSense releast minder vaak maar test meer gedegen (buiten recente uitglijder met Wireguard-in-kernel om dan...). Als er een security patch is, ook van een extern pakket als Unbound is, brengt pfSense ook gewoon direct een update uit.

Je moet ergens beginnen met feiten en fabels te collecteren om een leercurve te starten

Jouw antwoord triggerde mij, de community van OPNsense lijkt vrij stil en passief. Dat sluit wel aan bij het weinige testen lijkt mij.

Is de pfSense community actiever, heb daar nog geen reden gehad tot het stellen van een vraag.

[Kabouterplop01]

Ik ben biased, ik draai op 2 industriële mini PC's (beiden dual NICs) pfsense (De ene is een celeron en de andere een core-i5) en op een NUC pihole in RAM. beiden draaien pfblocker en snort en de logging wordt in Splunk geduwd.
Zoals gezegd de pages laden FTL zoals het heurt. De rest van mn netwerkje heeft zowel windows, als mac als linux.

[stormfly]

OPNsense op ESX 7.0u2 gaat hier minder goed dan pfSense. Heb wegvallende RDP verbindingen naar internet en zelfs op het LAN zijn af en toe DNS servers onbereikbaar.

Dat is balen want ik had net voor OPNsense gekozen hahaha ik boot de pfSense VM wel ff, alle policies zijn identiek.

Zijn er Tweakers die specifieke vm tweaks hebben toegepast? Heb er al op GoT gevonden en op reddit.

EDIT: alle tunables terug naar default en op het UniFi netwerk flowcontrol ingeschakeld.

[ Voor 10% gewijzigd door stormfly op 15-07-2021 13:02 ]

[westlym]

Ik heb enkele maanden geleden een nieuwe mobo gehaald, namelijk een pricewatch: ASRock H570M-ITX/ac

Ik heb het laatste pfsense hierop geïnstalleerd, maar eenmaal als de pfsense boot, herkent ie geen NiCs en het toetsenbord valt ook uit, dus ik kan helemaal niks configureren.

Wat zou het probleem kunnen zijn? Ik hoor het graag.

[stormfly]

@Tom Paris @nero355 or others:

pfSense heeft een wat complexere aanpak met betrekking tot de GeoIP blocking. Ik denk dat ik het nu doorgrond maar toch zie ik nog Franse prefixen in mijn NL filter?

Ik zou heel graag zelf de GeoIP alias benoemen, GeoIP-NL maar dat lijkt niet mogelijk?

Wat ik gedaan heb:
Firewall/pfBlockerNG/Europe -> aan klikken van Nederland
Firewall/pfBlockerNG/Europe ->ListAction -> Alias Native

FirewallRulesWAN_KPN -> Rule aan de FW gekoppeld dmv de enige alias pfB_Europe_v4 maar dan zie je Franse IP's?

Alle guides op internet komen uit het jaar stenenkruik

[ Voor 3% gewijzigd door stormfly op 16-07-2021 11:39 ]

[Rayures]

Ik heb list action, alias permit.
Dan van de pfb_europe v4 een alias gemaakt
Die alias inde firewall rules als allowed source.

[Tom Paris]

westlym schreef op donderdag 15 juli 2021 @ 21:56:
Ik heb enkele maanden geleden een nieuwe mobo gehaald, namelijk een pricewatch: ASRock H570M-ITX/ac

Ik heb het laatste pfsense hierop geïnstalleerd, maar eenmaal als de pfsense boot, herkent ie geen NiCs en het toetsenbord valt ook uit, dus ik kan helemaal niks configureren.

Wat zou het probleem kunnen zijn? Ik hoor het graag.

De Realtek NIC wordt niet standaard ondersteund in pfSense, je moet daarvoor een aparte package met de Realtek driver installeren: zie hier

De Intel NIC wordt sinds april ondersteund in FreeBSD-HEAD, het is de vraag of dat backported wordt of dat je moet wachten op een volgende grote release.

Waarschijnlijk het beste om een ander moederbord te kopen met ondersteunde NICs of een Intel I350-based netwerkkaart te kopen.

[stormfly]

Rayures schreef op vrijdag 16 juli 2021 @ 13:45:
Ik heb list action, alias permit.
Dan van de pfb_europe v4 een alias gemaakt
Die alias inde firewall rules als allowed source.

Eigenlijk hetzelfde als bij mij? De FW rules heb je gemaakt in het reguliere pfSense FW menu? Als je daar "hoovert" over de fw alias naam, zie je dan dezelfde 2.16.x.y ip reeksen? Die zijn Frans en niet Nederlands...het lijkt een EU filter ipv een EU-NL filter. Hij neemt de gemaakte NL selectie niet mee...

Iemand anders die dit kan reproduceren en de oplossing weet?

[Rayures]

stormfly schreef op vrijdag 16 juli 2021 @ 19:50:
[...]


Eigenlijk hetzelfde als bij mij? De FW rules heb je gemaakt in het reguliere pfSense FW menu? Als je daar "hoovert" over de fw alias naam, zie je dan dezelfde 2.16.x.y ip reeksen? Die zijn Frans en niet Nederlands...het lijkt een EU filter ipv een EU-NL filter. Hij neemt de gemaakte NL selectie niet mee...

Iemand anders die dit kan reproduceren en de oplossing weet?

Nope, geen 2.16 range. En, toevallig net terug van een vakantie in .fr. Kwam echt niet bij de poorten welke de NL only geo ip allow hebben.

//check gedaan, ik had iig geen 2.16.x.x ip range tijdens de .fr vakantie.

[ Voor 5% gewijzigd door Rayures op 16-07-2021 21:21 ]

[stormfly]

Rayures schreef op vrijdag 16 juli 2021 @ 21:17:
[...]


Nope, geen 2.16 range. En, toevallig net terug van een vakantie in .fr. Kwam echt niet bij de poorten welke de NL only geo ip allow hebben.

//check gedaan, ik had iig geen 2.16.x.x ip range tijdens de .fr vakantie.

Heb jij dan alles geslecteerd behalve NL of alleen NL en de rest niet geselecteerd?

[Kabouterplop01]

@stormfly wow dat is dan best complex en bewerkelijk als je zoveel wil blocklisten. Heb je de optie CIDR aggregation al aangezet? (die maakt van al die specifics grote "superblocks")

Wat dat betreft heb ik het iets makkelijker denk ik, ik heb geen portforwards meer, dus ik blokkeer alles incomming.

edit: ik wil alleen maar weten wie er aankloppen; snort en pfblocker helpen daar prima mee.

[ Voor 13% gewijzigd door Kabouterplop01 op 17-07-2021 10:37 ]

[stormfly]

Kabouterplop01 schreef op zaterdag 17 juli 2021 @ 10:36:
@stormfly wow dat is dan best complex en bewerkelijk als je zoveel wil blocklisten. Heb je de optie CIDR aggregation al aangezet? (die maakt van al die specifics grote "superblocks")

Wat dat betreft heb ik het iets makkelijker denk ik, ik heb geen portforwards meer, dus ik blokkeer alles incomming.

edit: ik wil alleen maar weten wie er aankloppen; snort en pfblocker helpen daar prima mee.

Nou nee ik wil eigenlijk een NL permit only. Zoals de notes ook voorschrijven. Ik wil juist niet een “block world except NL” ik wil een “allow NL”. Maar mijn NL filter bevat ook vele andere EU prefixen. Dat klopt niet. Ik twijfel over een bug of een gebruikers fout.

Snort is het volgende project. Heb pfSense vanmorgen even op de NUC7i3 gezet, native.

PfBlocker kan ook inkomend liggen? Snort staat als volgend project op de lijst

[ Voor 4% gewijzigd door stormfly op 17-07-2021 11:03 ]

[Kabouterplop01]

PfBlocker kan ook inkomend liggen?

Als ik de logica van de firewall rules mag geloven (en ik heb er aardig wat jaartjes ervaring mee) dan ja.
(ik zie op zowel de wan als lan interface PfB_ rules)

[purge]

En zoiets?


Let wel op dat de action staat op Alias Native. Dan kan je hem direct gebruiken als alias in jouw firewall rules.
pfBlocker maakt automatisch een (url) alias aan met de naam pfB_NL_v4. Waarbij in dit geval NL is wat ingevuld is in het veld Name.

Of je zet de action op iets anders (bijv. permit inbound) en vul je eronder bij Advanced inbound firewall rules wat dingen in die je open wilt hebben. Zelf gebruik ik een alias omdat ik dan de rules netjes bij elkaar heb.

De tab GeoIP hoef je niet te gebruiken. De standaard config, niets dus
Al zou je hier wel andere dingen zoals, Top Spammers, in kunnen stellen.

[ Voor 33% gewijzigd door purge op 17-07-2021 15:48 ]

[stormfly]

purge schreef op zaterdag 17 juli 2021 @ 15:34:
En zoiets?
[Afbeelding]

Let wel op dat de action staat op Alias Native. Dan kan je hem direct gebruiken als alias in jouw firewall rules.
pfBlocker maakt automatisch een (url) alias aan met de naam pfB_NL_v4. Waarbij in dit geval NL is wat ingevuld is in het veld Name.

Of je zet de action op iets anders (bijv. permit inbound) en vul je eronder bij Advanced inbound firewall rules wat dingen in die je open wilt hebben. Zelf gebruik ik een alias omdat ik dan de rules netjes bij elkaar heb.

De tab GeoIP hoef je niet te gebruiken. De standaard config, niets dus
Al zou je hier wel andere dingen zoals, Top Spammers, in kunnen stellen.

EDIT
Okey ik denk dat het vanaf dag 1 al goed werkte, ik heb toevallig twee keer een Franse IP getest. (ik ga er even vanuit dat ik hem niet 2x verkeerd overtikte ) Met de optie van jou met een directe rule (via die syntax uit de vorige post) of met het aanklikken van NL in het landen menu, beide komen met dezelfde lijsten naar voren.

Eind goed al goed, het werkt! Dank voor jullie hulp

---

Ja dat ziet er goed uit bij jou, bij mij mist de optie GeoIP op die plaats?

Zou dit werken: /usr/local/share/GeoIP/cc/NL_v4.txt

[ Voor 40% gewijzigd door stormfly op 17-07-2021 21:36 ]

[stormfly]

purge schreef op zaterdag 17 juli 2021 @ 15:34:
En zoiets?
[Afbeelding]

Let wel op dat de action staat op Alias Native. Dan kan je hem direct gebruiken als alias in jouw firewall rules.
pfBlocker maakt automatisch een (url) alias aan met de naam pfB_NL_v4. Waarbij in dit geval NL is wat ingevuld is in het veld Name.

Of je zet de action op iets anders (bijv. permit inbound) en vul je eronder bij Advanced inbound firewall rules wat dingen in die je open wilt hebben. Zelf gebruik ik een alias omdat ik dan de rules netjes bij elkaar heb.

De tab GeoIP hoef je niet te gebruiken. De standaard config, niets dus
Al zou je hier wel andere dingen zoals, Top Spammers, in kunnen stellen.

Heb jij zelf ook een website draaien achter pfSense? Ik merk dat als ik de geolist op NL zet mijn hairpin nat stuk gaat. Alle mogelijke combinaties geprobeerd maar het enige wat werkt is er een rule voor maken met de LAN ip reeks...

Zijn er mooiere oplossingen?

[Rayures]

stormfly schreef op zondag 18 juli 2021 @ 09:35:
[...]


Heb jij zelf ook een website draaien achter pfSense? Ik merk dat als ik de geolist op NL zet mijn hairpin nat stuk gaat. Alle mogelijke combinaties geprobeerd maar het enige wat werkt is er een rule voor maken met de LAN ip reeks...

Zijn er mooiere oplossingen?


[Afbeelding]

Gebruik zelf haproxy op pfsense. Die laat ik ook luisteren op lan, dat werkt prima. Al het verkeer blijft intern.

[purge]

stormfly schreef op zondag 18 juli 2021 @ 09:35:
[...]
Heb jij zelf ook een website draaien achter pfSense? Ik merk dat als ik de geolist op NL zet mijn hairpin nat stuk gaat. Alle mogelijke combinaties geprobeerd maar het enige wat werkt is er een rule voor maken met de LAN ip reeks...

Zijn er mooiere oplossingen?

Zelf heb ik geen spannende dingen hier staan. Wel een (fake) website, met enkele dummy teksten en voor bekenden (whitelisted op ip adres) dashboard achtige zaken. Andere dingen staan voornamelijk extern. Meer om mijn public ip te beschermen, mogelijk dat er nog wat dingen via Cloudflare worden afgehandeld. Maar dat is voor dit onderwerp niet van toepassing.

Hairpinning i.c.m. pfSense
Ik moest even zoeken wat je ermee bedoelde. Maar hier wat info van Netgate/pfSense. Hier wordt verwezen naar documentatie over portforwarding

Mooiere oplossing?
Geen idee of het mooier/beter is maar net als de reactie hierboven gebruik ik HAproxy. Dit is, zeg maar, de split dns configuratie met een extra'tje.

• pfSense een Virtual IP (IP-Alias) aangemaakt op een Interface (LAN / DMZ/ ...) met het adres 192.168.2.20/32. Deze gebruik ik als HAproxy frontend adres.
• Intern draait de webserver op 192.168.1.10 en is toegevoegd als HAproxy backend server.
• pfSense NAT regels aangemaakt van WAN-adres naar 192.168.2.20 en port 80/443
• Extern laat ik het DNS record (www.example.com) verwijzen naar mijn WAN-adres (203.0.113.1).
• Interne DNS verwijst naar 192.168.1.10 (het HAproxy adres). De reden hiervoor is dat pfSense ook het https certificaat via https offloading afhandeld. Wanneer het https certificaat op de webserver zelf staat dan kan je natuurlijk ook de DNS direct naar je interne ip adres van de webserver laten verwijzen.

Probeer anders eerst de split-dns oplossing, zonder HAproxy. Als dat beter werkt kan je overwegen om ook de HAproxy te configureren. Dan is het eenvoudig extern dns record naar je publieke ip adres. Intern verwijs je deze naar je webserver.

pfSense > Services > DNS Resolver > Host Overrides
host: www
domain: example.com
ip-adres: 192.168.2.20

[stormfly]

purge schreef op zondag 18 juli 2021 @ 16:35:
[...]


Zelf heb ik geen spannende dingen hier staan. Wel een (fake) website, met enkele dummy teksten en voor bekenden (whitelisted op ip adres) dashboard achtige zaken. Andere dingen staan voornamelijk extern. Meer om mijn public ip te beschermen, mogelijk dat er nog wat dingen via Cloudflare worden afgehandeld. Maar dat is voor dit onderwerp niet van toepassing.

Hairpinning i.c.m. pfSense
Ik moest even zoeken wat je ermee bedoelde. Maar hier wat info van Netgate/pfSense. Hier wordt verwezen naar documentatie over portforwarding

Mooiere oplossing?
Geen idee of het mooier/beter is maar net als de reactie hierboven gebruik ik HAproxy. Dit is, zeg maar, de split dns configuratie met een extra'tje.

• pfSense een Virtual IP (IP-Alias) aangemaakt op een Interface (LAN / DMZ/ ...) met het adres 192.168.2.20/32. Deze gebruik ik als HAproxy frontend adres.
• Intern draait de webserver op 192.168.1.10 en is toegevoegd als HAproxy backend server.
• pfSense NAT regels aangemaakt van WAN-adres naar 192.168.2.20 en port 80/443
• Extern laat ik het DNS record (www.example.com) verwijzen naar mijn WAN-adres (203.0.113.1).
• Interne DNS verwijst naar 192.168.1.10 (het HAproxy adres). De reden hiervoor is dat pfSense ook het https certificaat via https offloading afhandeld. Wanneer het https certificaat op de webserver zelf staat dan kan je natuurlijk ook de DNS direct naar je interne ip adres van de webserver laten verwijzen.

Probeer anders eerst de split-dns oplossing, zonder HAproxy. Als dat beter werkt kan je overwegen om ook de HAproxy te configureren. Dan is het eenvoudig extern dns record naar je publieke ip adres. Intern verwijs je deze naar je webserver.

pfSense > Services > DNS Resolver > Host Overrides
host: www
domain: example.com
ip-adres: 192.168.2.20

Yes split dns is wel mooier ja, maar eens naar kijken. Ik had HA proxy werkend op OPNsense werkte mooi zeker met letsencrypt.

Mijn case gaat mis omdat de GeoIP list vanzelfsprekend niet mijn RFC1918 reeks bevat, dus NAT werkt prima alleen de GeoIP block laat hem niet door

[purge]

stormfly schreef op zaterdag 17 juli 2021 @ 21:19:
[...]

..., bij mij mist de optie GeoIP op die plaats?

Zou dit werken: /usr/local/share/GeoIP/cc/NL_v4.txt

Zelf gebruik ik -zoals veel mensen- de package pfBlockerNG-devel v3.0.0_16. Laat je niet misleiden door de naamgeving. Deze versie is 'gewoon' supported. En verder draait dit op pfSense 2.5.2.

Geen idee of de tekst bestanden goed (blijven) werken.

[purge]

stormfly schreef op zondag 18 juli 2021 @ 16:58:
[...]
Mijn case gaat mis omdat de GeoIP list vanzelfsprekend niet mijn RFC1918 reeks bevat, dus NAT werkt prima alleen de GeoIP block laat hem niet door

Inderdaad. Met split DNS heb je dat conflict niet meer.
Enkel een firewall rule op de interface van je computer/client. Maar die zal waarschijnlijk al iets bevatten als Pass http/https to any.

[lolgast]

In de hoop dat ik niet meteen word afgeschoten omdat ik een generale vraag stel, maar ik kom er niet echt uit en de meningen hier lijken in mijn nadeel te spreken. Dus hopelijk werkt dat

Ik ben voornemens om mijn Unifi USG op 'redelijk' korte termijn te gaan vervangen omdat we glasvezel krijgen hier. Een nieuw Unifi product wat aan mijn wensen voldoet zie ik niet en ik wil al lang klooien met pfSense/OPNsense.

- Ik wil pfsense/opnsense baremetal gaan draaien
- Ik zou graag ondersteuning willen voor de +/- 1Gb up/down van glasverbindingen in NL
- Ik wil (ook) een SFP port als WAN interface
- Ik wil er (lekker Nederlands) geen €500 aan uitgeven

Ik ben me helemaal krom aan het zoeken en het beste wat ik gevonden krijg is dan toch de Netgate SG-2100. Ben ik slecht in zoeken of zoek ik naar een eenhoorn?

[ Voor 4% gewijzigd door lolgast op 21-07-2021 10:43 ]

[Miki]

lolgast schreef op woensdag 21 juli 2021 @ 10:41:
In de hoop dat ik niet meteen word afgeschoten omdat ik een generale vraag stel, maar ik kom er niet echt uit en de meningen hier lijken in mijn nadeel te spreken. Dus hopelijk werkt dat

Ik ben voornemens om mijn Unifi USG op 'redelijk' korte termijn te gaan vervangen omdat we glasvezel krijgen hier. Een nieuw Unifi product wat aan mijn wensen voldoet zie ik niet en ik wil al lang klooien met pfSense/OPNsense.

- Ik wil pfsense/opnsense baremetal gaan draaien
- Ik zou graag ondersteuning willen voor de +/- 1Gb up/down van glasverbindingen in NL
- Ik wil (ook) een SFP port als WAN interface
- Ik wil er (lekker Nederlands) geen €500 aan uitgeven

Ik ben me helemaal krom aan het zoeken en het beste wat ik gevonden krijg is dan toch de Netgate SG-2100. Ben ik slecht in zoeken of zoek ik naar een eenhoorn?

Een tweedehands desktop pc in small form factor (SFF) icm met een nette intel netwerkkaart gaat wel lukken voor onder de €500. De vraag is alleen of je na een jaar of 2 nog gelukkig bent met je stroomkosten

Een PFsense doosje zoals de SG-2100 is gezien de prijsstelling te duur voor wat je krijgt en naar mijn weten is het niet duidelijk of de soc krachtig genoeg is om een 1Gb lijntje i.c.m. PPPoE te kunnen trekken.

[ Voor 8% gewijzigd door Miki op 21-07-2021 10:58 ]

[lolgast]

Miki schreef op woensdag 21 juli 2021 @ 10:56:
[...]

Een tweedehands desktop pc in small form factor (SFF) icm met een nette intel netwerkkaart gaat wel lukken voor onder de €500. De vraag is alleen of je na een jaar of 2 nog gelukkig bent met je stroomkosten

Een PFsense doosje zoals de SG-2100 is gezien de prijsstelling te duur voor wat je krijgt en naar mijn weten is het niet duidelijk of de soc krachtig genoeg is om een 1Gb lijntje i.c.m. PPPoE te kunnen trekken.

Een SFF vind ik te groot (voor in de meterkast). Ik weet dat iedereen de Netgate appatuur hier te duur vindt voor wat je er voor krijgt, vandaar de vraag. Ik hoop dat iemand hier roept: "STOP!!! Je moet [insert device] hebben want die heeft ook wat jij zoekt.

Ik kan [insert device] niet vinden namelijk

[Tom Paris]

@lolgast 1Gbit PPPoE vereist gewoon serieuze compute power. Daarnaast zijn en maar weinig apparaten met SFP slot, dus de suggestie van een SFF met SFP-NIC is vrij logisch. Als je de eis voor een SFP laat vallen is er al veel meer mogelijk... Sowieso, als je zegt "we gaan glasvezel krijgen" is dat vrijwel zeker GPON. Bij GPON werkt een eigen SFP niet meer, maar moet je de KPN mediaconverter gebruiken.

[lolgast]

@Tom Paris Ah oke. Dat is nuttige info, dan kan ik die voorwaarde laten varen ja. Jammer vanuit hoeveelheid devices oogpunt, maar opent wel een hoop andere deuren dan. Dan ga ik mijn zoektocht even opnieuw beginnen!

Ik heb mijn verbinding aangevraagd bij Tweak, als ik me niet vergis doen zijn niets met PPPoE. Maar of dat ook bij deze nieuw aan te leggen verbinding (door E-Fiber) ook geldt weet ik nog niet.

[nero355]

lolgast schreef op woensdag 21 juli 2021 @ 15:41:
Ik heb mijn verbinding aangevraagd bij Tweak, als ik me niet vergis doen zijn niets met PPPoE.
Maar of dat ook bij deze nieuw aan te leggen verbinding (door E-Fiber) ook geldt weet ik nog niet.

Tweak als in gewoon 1 Gbps synchroon

Dan krijg je daar volgens mij gewoon een NAT WiFi Routertje bij dus wacht gewoon effe totdat je online bent en kijk dan effe goed wat het handigst is

Krijg je echter de 1 Gbps + 10 Gbps aansluiting dan wordt het een ander verhaal!

[Raven]

nero355 schreef op woensdag 21 juli 2021 @ 15:51:
[...]

Tweak als in gewoon 1 Gbps synchroon

Dan krijg je daar volgens mij gewoon een NAT WiFi Routertje bij dus wacht gewoon effe totdat je online bent en kijk dan effe goed wat het handigst is

Bij internet-only abo volgens mij alleen mediaconverter.

[Ankh]

Tom Paris schreef op woensdag 21 juli 2021 @ 15:00:
@lolgast 1Gbit PPPoE vereist gewoon serieuze compute power. Daarnaast zijn en maar weinig apparaten met SFP slot, dus de suggestie van een SFF met SFP-NIC is vrij logisch. Als je de eis voor een SFP laat vallen is er al veel meer mogelijk... Sowieso, als je zegt "we gaan glasvezel krijgen" is dat vrijwel zeker GPON. Bij GPON werkt een eigen SFP niet meer, maar moet je de KPN mediaconverter gebruiken.

PPPoE hoeft helemaal compute power te hebben, zolang je maar offloading op de CPU hebt. De normale Intel CPU's hebben die niet, maar als je specifieke netwerk CPUs dan wel. Als voorbeeld de Mediatek CPU van een EdgeRouter X heeft PPPoE offloading en haalt met die magere 500MHz gewoon 500Mbps throughput naar het schijnt.

[Tom Paris]

Ankh schreef op woensdag 21 juli 2021 @ 19:52:
[...]

PPPoE hoeft helemaal compute power te hebben, zolang je maar offloading op de CPU hebt. De normale Intel CPU's hebben die niet, maar als je specifieke netwerk CPUs dan wel. Als voorbeeld de Mediatek CPU van een EdgeRouter X heeft PPPoE offloading en haalt met die magere 500MHz gewoon 500Mbps throughput naar het schijnt.

Correct, maar we hebben het in dit geval over pfSense/OPNsense. Dat draait alleen maar op x86 (paar ARM-uitzonderingen daargelaten die prorietary en/of experimenteel zijn)

Offloading vereist een strike combi van hardware en software, en dat is zelfbouw vrijwel nooit.

[lolgast]

@nero355 @Raven Ik heb inderdaad toevallig het internet only abonnement gekozen, waar je je eigen router moet regelen.

Vandaar dat ik dacht, ik ga me vast oriënteren Op de website van Tweak staat het volgende:

quote: https://www.tweak.nl/support/apparatuur-configureren.html

Internet Only
De verbinding is untagged (dus geen VLAN’s).
Gebruik de WAN-poort van je eigen router om onze mediaconvertor op aan te sluiten.
Gebruik de standaard-instellingen om een IP-adres te verkrijgen.

Eigen SFP-modules
Als je liever een eigen optic of SFP-module aansluit moet je er op letten onderstaande frequenties te gebruiken.

TX: 1310 nm
RX: 1490/1550 nm

Lijkt mij dat ik dan geen PPPoE nodig heb en ook geen media converter hoef te gebruiken. Maar ik heb nog even gelukkig, dus overhaaste beslissingen maken hoeft niet

[Miki]

Tom Paris schreef op woensdag 21 juli 2021 @ 19:57:
[...]


Correct, maar we hebben het in dit geval over pfSense/OPNsense. Dat draait alleen maar op x86 (paar ARM-uitzonderingen daargelaten die prorietary en/of experimenteel zijn)

Offloading vereist een strike combi van hardware en software, en dat is zelfbouw vrijwel nooit.

En aanvullend is FreeBSD ook fors minder efficiënt dan Linux. Debian of bijv. Open-WRT heeft bijvoorbeeld veel minder performante hardware nodig om dezelfde prestaties te leveren.

Alleen ja.. PFsense en OPNsense zijn dusdanig goed door ontwikkelt dat bovengenoemde alternatieven een flinke stap terug doen is in functionaliteiten en gebruiksgemak.

[Tom Paris]

Miki schreef op woensdag 21 juli 2021 @ 21:15:
[...]

En aanvullend is FreeBSD ook fors minder efficiënt dan Linux. Debian of bijv. Open-WRT heeft bijvoorbeeld veel minder performante hardware nodig om dezelfde prestaties te leveren.

Alleen ja.. PFsense en OPNsense zijn dusdanig goed door ontwikkelt dat bovengenoemde alternatieven een flinke stap terug doen is in functionaliteiten en gebruiksgemak.

Dat is zeker waar ja. Die verschillen vielen nog niet zo op toen we nog op 100Mbit DSL/kabel zaten, maar met fiber begin je het zeker te zien. OpenWRT kan uiteindelijk hetzelfde (en meer) als *sense, maar het gebruiksgemak is er idd niet helemaal. De ontwikkelaars van pfSense hebben al aangegeven dat wat hun betreft de toekomst bij Linux ligt, hun eerste stap daartoe is al genomen met TNSR.

[nero355]

Ankh schreef op woensdag 21 juli 2021 @ 19:52:
PPPoE hoeft helemaal compute power te hebben, zolang je maar offloading op de CPU hebt. De normale Intel CPU's hebben die niet, maar als je specifieke netwerk CPUs dan wel. Als voorbeeld de Mediatek CPU van een EdgeRouter X heeft PPPoE offloading en haalt met die magere 500MHz gewoon 500Mbps throughput naar het schijnt.

Ik vraag me altijd of of al die Offloading Features nou aparte chips zijn of in de SoC zelf zitten

Miki schreef op woensdag 21 juli 2021 @ 21:15:
En aanvullend is PPPoE onder FreeBSD ook fors minder efficiënt dan Linux. Debian of bijv. Open-WRT heeft bijvoorbeeld veel minder performante hardware nodig om dezelfde prestaties i.c.m. PPPoE te leveren.

There... I fixed it!

Alleen ja.. PFsense en OPNsense zijn dusdanig goed door ontwikkelt dat bovengenoemde alternatieven een flinke stap terug doen is in functionaliteiten en gebruiksgemak.

Dat valt ook reuze mee!

Het is juist allemaal hartstikke flexibel en makkelijk aan je wensen aan te passen, zelfs als iets niet standaard aanwezig is kan je het vaak zelf nog toevoegen zonder enig probleem!


Verder vraag ik me het volgende af wat betreft pfSense en ARM SoC's :

- Als je FreeBSD installeert dan kan je daarna als applicatie gewoon pfSense installeren voor zover ik weet.
- Ondanks dat FreeBSD ook op ARM kan draaien raadt men vaak NetBSD aan, want "die zou zelfs op je broodrooster moeten kunnen draaien" zogenaamd

Dus...

Zou je dan NetBSD kunnen installeren op een of ander ARM SoC gebakje en daarna pfSense erop knallen, zodat je pfSense op ARM kan draaien

_{/Brainfart...}

[Tom Paris]

nero355 schreef op donderdag 22 juli 2021 @ 14:59:
Ik vraag me altijd of of al die Offloading Features nou aparte chips zijn of in de SoC zelf zitten

Het zit echt in de SoC zelf. Vergelijk het met offloading voor videocodecs in (i)GPU's. Je moet dat meecompileren in de kernel, wat voor open source projecten vaak lastig is (want niet alle benodigde code is openbaar). De hardware-offloading van de Mediatek SoC's zoals in de genoemde Ubiquiti ER-X is in bijv. OpenWRT erg fragiel.

nero355 schreef op donderdag 22 juli 2021 @ 14:59:
Verder vraag ik het volgende af wat betreft pfSense en ARM SoC's :

- Als je FreeBSD installeert dan kan je daarna als applicatie gewoon pfSense installeren voor zover ik weet.
- Ondanks dat FreeBSD ook op ARM kan draaien raadt men vaak NetBSD aan, want "die zou zelfs op je broodrooster moeten kunnen draaien" zogenaamd

Dus...

Zou je dan NetBSD kunnen installeren op een of ander ARM SoC gebakje en daarna pfSense erop knallen, zodat je pfSense op ARM kan draaien

Ja en nee. Ten eerste moet je *sense compileren van source voor het target platform. Dat is in principe nog wel te doen, immers draaien de Netgate appliances op ARM en de community heeft een port gemaakt voor OPNsense op NanoPi. Het grote probleem zit 'm in de hardware support, waar ontbrekende drivers veel ARM platformen onbruikbaar maken. Of NetBSD daar beter in is weet ik niet, maar ook hier geldt dat als het compileert, het zou moeten werken... Echter, de verschillen tussen FreeBSD en NetBSD zullen toch significante wijzigingen aan de code base van *sense vereisen voordat het inderdaad te compileren valt...

[stormfly]

Kabouterplop01 schreef op zaterdag 17 juli 2021 @ 10:36:
@stormfly
edit: ik wil alleen maar weten wie er aankloppen; snort en pfblocker helpen daar prima mee.

Inmiddels SNORT ook draaien, als ik wat google is het advies om het niet op de WAN interface te draaien, maar juist op al je LAN subnets. Heb jij dat ook zo ingeregeld, of gebruik jij de "aanklop detectie" via een WAN configuratie?

[Muncher]

Sinds een paar weken heeft mijn Zotac Opnsense het begeven. (https://minipc.eu/webshop...pc/zotac-zbox-ci329-nano/) RMA aangevraagd maar helaas is de CI329 EOL en kan ik nu voor 92 euro, bovenop het credit bedrag, de opvolger kopen (https://minipc.eu/webshop...ieve-pc/zotac-zbox-ci341/). Dit begint een beetje duur aan te voelen allemaal. Ik draai Opnsense icm Sensei, dus heb wel een behoorlijke hoeveelheid RAM nodig. Ik zit nu naar alternatieven te kijken, maar kan eigenlijk niet echt iets fatsoenlijks vinden dat:

- een kleine form factor heeft
- passief gekoeld is
- minimaal 8 GB ram aan boord heeft.

Ik heb een T-Mobile thuis verbinding. Welke hardware zouden jullie mij aanraden?

[Tom Paris]

Muncher schreef op vrijdag 23 juli 2021 @ 10:07:
Sinds een paar weken heeft mijn Zotac Opnsense het begeven. (https://minipc.eu/webshop...pc/zotac-zbox-ci329-nano/) RMA aangevraagd maar helaas is de CI329 EOL en kan ik nu voor 92 euro, bovenop het credit bedrag, de opvolger kopen (https://minipc.eu/webshop...ieve-pc/zotac-zbox-ci341/). Dit begint een beetje duur aan te voelen allemaal. Ik draai Opnsense icm Sensei, dus heb wel een behoorlijke hoeveelheid RAM nodig. Ik zit nu naar alternatieven te kijken, maar kan eigenlijk niet echt iets fatsoenlijks vinden dat:

- een kleine form factor heeft
- passief gekoeld is
- minimaal 8 GB ram aan boord heeft.

Ik heb een T-Mobile thuis verbinding. Welke hardware zouden jullie mij aanraden?

Goedkoper dan die basisprijs van €311 lijkt me niet echt reëel gezien de prijzen voor NUC-achtige system op het moment. Waarom denk je dat het te duur is?

[Kabouterplop01]

stormfly schreef op donderdag 22 juli 2021 @ 16:23:
[...]


Inmiddels SNORT ook draaien, als ik wat google is het advies om het niet op de WAN interface te draaien, maar juist op al je LAN subnets. Heb jij dat ook zo ingeregeld, of gebruik jij de "aanklop detectie" via een WAN configuratie?

Ik heb het standaard op de WAN interface gedraaid in IPS mode en pfblocker op de LAN.
Ik had een brakke exchange machine en daarom port 25 open, maar nu is het alleen maar aankloppen er staat niets meer open.
(De snort rules die gaven nogal wat false positives op de LAN kant en heb ik uit gezet, dat neemt niet weg dat het niet goed werkt hoor, maar ik zat thuis per dag toch zeker een uur te tunen en daar heb ik geen zin an)

[nero355]

Muncher schreef op vrijdag 23 juli 2021 @ 10:07:
Sinds een paar weken heeft mijn Zotac Opnsense het begeven. (https://minipc.eu/webshop...pc/zotac-zbox-ci329-nano/) RMA aangevraagd maar helaas is de CI329 EOL en kan ik nu voor 92 euro, bovenop het credit bedrag, de opvolger kopen (https://minipc.eu/webshop...ieve-pc/zotac-zbox-ci341/). Dit begint een beetje duur aan te voelen allemaal. Ik draai Opnsense icm Sensei, dus heb wel een behoorlijke hoeveelheid RAM nodig.

Dit kwam vandaag langs : https://nl.hardware.info/...jd-met-intel-nucs-aangaan

Opzich wel relatief goedkoop als je beseft wat erin zit!

Ik zit nu naar alternatieven te kijken, maar kan eigenlijk niet echt iets fatsoenlijks vinden dat:

- een kleine form factor heeft
- passief gekoeld is
- minimaal 8 GB ram aan boord heeft.

Ik heb een T-Mobile thuis verbinding. Welke hardware zouden jullie mij aanraden?

Had T-Mobile nou wel of geen PPPoE

Dan kan je misschien wat geld besparen op de CPU maar ik weet weer niet wat voor effect dat heeft op je Sensei setup ?!

[geenwindows]

nero355 schreef op vrijdag 23 juli 2021 @ 19:05:
[...]

Had T-Mobile nou wel of geen PPPoE

Dan kan je misschien wat geld besparen op de CPU maar ik weet weer niet wat voor effect dat heeft op je Sensei setup ?!

T-mobile gebruikt DHCP

Sensei heeft wel wat cpu power nodig, (aanbevelingen qua hardware wordt zelfs tijdens de setup gecheckt) al heb ik wel het idee dat het iets minder zwaar is dan Suricata.
Op mijn OPNsense bakkie haalde ik met Suricata met Iperf3 testjes tussen de 1 tot 2 Gbit, terwijl ik nu met Sensei tussen de 3 en 4Gbit zit. Hoewel de CPU niet volledig belast wordt, Beide applicaties gebruiken Netmap, lijkt wel of deze maar één thread gebruikt...

[luminous]

lolgast schreef op woensdag 21 juli 2021 @ 10:41:
In de hoop dat ik niet meteen word afgeschoten omdat ik een generale vraag stel, maar ik kom er niet echt uit en de meningen hier lijken in mijn nadeel te spreken. Dus hopelijk werkt dat

Ik ben voornemens om mijn Unifi USG op 'redelijk' korte termijn te gaan vervangen omdat we glasvezel krijgen hier. Een nieuw Unifi product wat aan mijn wensen voldoet zie ik niet en ik wil al lang klooien met pfSense/OPNsense.

- Ik wil pfsense/opnsense baremetal gaan draaien
- Ik zou graag ondersteuning willen voor de +/- 1Gb up/down van glasverbindingen in NL
- Ik wil (ook) een SFP port als WAN interface
- Ik wil er (lekker Nederlands) geen €500 aan uitgeven

Ik ben me helemaal krom aan het zoeken en het beste wat ik gevonden krijg is dan toch de Netgate SG-2100. Ben ik slecht in zoeken of zoek ik naar een eenhoorn?

Zelf maak ik gebruik van een Yanling pc. Is wellicht overkill maar doet het goed met 1Gbit T-Mobile Thuis verbinding.

[lolgast]

luminous schreef op dinsdag 27 juli 2021 @ 19:45:
[...]


Zelf maak ik gebruik van een Yanling pc. Is wellicht overkill maar doet het goed met 1Gbit T-Mobile Thuis verbinding.

Ik merk dat ik een beetje pingpong tussen yanling/qotom/protectli, zelfbouw, native appliance (Netgate) of bijvoorbeeld Mikrotik.

Ik zou heel graag iets met IPS doen, maar ik zou ook heel graag gewoon 1Gbps halen. 1Gbps omdat ik er voor betaal (tzt.. ) en IPS omdat het wel tof is. Maar beide, voor een normale prijs, is lastig. Daar komt bij dat ik het stroomverbruik ook een belangrijke factor vind. De Unifi USG + Ziggo Connectbox doen samen zo'n 15W. Het zou mooi zijn als ik rond diezelfde cijfers blijf.

Met een Mikrotik RB5009UG+S+IN lijkt dat mogelijk én die heeft meer dan genoeg vermogen om 1Gbps te halen met alle voor mij benodigde firewall regels. Als het goed is ook zonder FastTrack, voor IPv6. Dan mis ik de fancy PFsense features, maar ik ben nog niet overtuigd of ik daar €250+ voor over heb

[sambaloedjek]

lolgast schreef op woensdag 28 juli 2021 @ 16:14:
[...]

Ik merk dat ik een beetje pingpong tussen yanling/qotom/protectli, zelfbouw, native appliance (Netgate) of bijvoorbeeld Mikrotik.

Ik zou heel graag iets met IPS doen, maar ik zou ook heel graag gewoon 1Gbps halen. 1Gbps omdat ik er voor betaal (tzt.. ) en IPS omdat het wel tof is. Maar beide, voor een normale prijs, is lastig. Daar komt bij dat ik het stroomverbruik ook een belangrijke factor vind. De Unifi USG + Ziggo Connectbox doen samen zo'n 15W. Het zou mooi zijn als ik rond diezelfde cijfers blijf.

Met een Mikrotik RB5009UG+S+IN lijkt dat mogelijk én die heeft meer dan genoeg vermogen om 1Gbps te halen met alle voor mij benodigde firewall regels. Als het goed is ook zonder FastTrack, voor IPv6. Dan mis ik de fancy PFsense features, maar ik ben nog niet overtuigd of ik daar €250+ voor over heb

Een MTik RB4011 haalt ook makkelijk 1 gbps (zonder FT) en is ongeveer 10 tot 15w(non-FT) normaalgebruik. Die nieuwe RB5009UG (18w minimaal) is nog niet beschikbaar op de markt, en moet het nog maar allemaal gaan bewijzen met RouterOS v7 restrictie, wat nu nog beta status heeft.
Zelf draai ik Qotom/pfsense momenteel, met een goede switch erachter en ervoor (IPTV). Pfsense/OPNsense heeft geen hardware-supported bridge functie. RB4011 ietsje beter; inter-vlan ondersteuning gaat redelijk vlotter op de Mtik dan op een Pfsense/OPNsense, met voorzichtige instellingen.
Maar als die nieuwe RB5009UG de Marvell Amethyst chip goed kan ondersteunen is dit idd een no-brainer, maar even afwachten.

[nero355]

sambaloedjek schreef op woensdag 4 augustus 2021 @ 19:58:
Die nieuwe RB5009UG (18w minimaal) is nog niet beschikbaar op de markt, en moet het nog maar allemaal gaan bewijzen met RouterOS v7 restrictie, wat nu nog beta status heeft.

Maar als die nieuwe RB5009UG de Marvell Amethyst chip goed kan ondersteunen is dit idd een no-brainer, maar even afwachten.

Ik kreeg die tip net ook van @FreshMaker onderaan een nieuwsartikel : https://mikrotik.com/product/rb5009ug_s_in

Leuk ding!

Pfsense/OPNsense heeft geen hardware-supported bridge functie.

Waar zou je die voor willen gebruiken dan

RB4011 ietsje beter; inter-vlan ondersteuning gaat redelijk vlotter op de Mtik dan op een Pfsense/OPNsense, met voorzichtige instellingen.

Hoe of wanneer merk je dat dan

[stormfly]

nero355 schreef op donderdag 5 augustus 2021 @ 19:19:
[...]

Ik kreeg die tip net ook van @FreshMaker onderaan een nieuwsartikel : https://mikrotik.com/product/rb5009ug_s_in

Leuk ding!


[...]

Waar zou je die voor willen gebruiken dan


[...]

Hoe of wanneer merk je dat dan

Ik vroeg het mij ook af @nero355 ben benieuwd. 1Gbps intervlan verkeer is toch 1Gbps 😵‍💫

[sambaloedjek]

nero355 schreef op donderdag 5 augustus 2021 @ 19:19:
[...]
Waar zou je die voor willen gebruiken dan

Voor te switchen met line-rate, zonder CPU (software) interventie.

[...]
Hoe of wanneer merk je dat dan

MTik hardware heeft (meerdere) dedicated switch chips. OPN/Pfsense niet; alles in software, via CPU. Denk aan IPTV vlan multicast bridging met MEERDERE IP-TVboxes. Dat verkeer wil je niet over je CPU laten gaan. Met een MTik kun je dit verkeer binnen 1 switch chip laten lopen zonder impact op andere switch-chip ports.

[stormfly]

sambaloedjek schreef op maandag 9 augustus 2021 @ 19:55:
[...]


Voor te switchen met line-rate, zonder CPU (software) interventie.


[...]


MTik hardware heeft (meerdere) dedicated switch chips. OPN/Pfsense niet; alles in software, via CPU. Denk aan IPTV vlan multicast bridging met MEERDERE IP-TVboxes. Dat verkeer wil je niet over je CPU laten gaan. Met een MTik kun je dit verkeer binnen 1 switch chip laten lopen zonder impact op andere switch-chip ports.

Muah weet niet of ik het daar mee eens ben, zo'n 7,2 Mbps stream, als je dat in vayatta routeert op een VM dan kost het 127Mhz. Volgens mij transformeert de markt juist naar chiploze routers, denk aan een UDM of pfSense/OPNsense.

Hier een intel NUC7i3, met een TV stream van 8Mbit je ziet de CPU niet eens veranderen hij blijft op 2%...inclusief SNORT inspectie (no blocking) modus. Vergeet niet dat een rPi al met gemak 100Mbit kan routeren

[sambaloedjek]

stormfly schreef op maandag 9 augustus 2021 @ 20:54:
[...]


Muah weet niet of ik het daar mee eens ben, zo'n 7,2 Mbps stream, als je dat in vayatta routeert op een VM dan kost het 127Mhz. Volgens mij transformeert de markt juist naar chiploze routers, denk aan een UDM of pfSense/OPNsense.

Hier een intel NUC7i3, met een TV stream van 8Mbit je ziet de CPU niet eens veranderen hij blijft op 2%...inclusief SNORT inspectie (no blocking) modus. Vergeet niet dat een rPi al met gemak 100Mbit kan routeren

[Afbeelding]

nuc7i3? klinkt als een router-on-a-stick. Jij maakt dus geen gebruik van software bridging. Andere use-case.

[Kabouterplop01]

Kwam net deze tegen. https://shop.tx-team.de/N...l/DuoBox-Business::8.html

Weet uiteraard niet of dat schaalt met bijvoorbeeld de huidige thuis Gbit verbindingen, maar toch het vermelden waard.

[Tom Paris]

Kabouterplop01 schreef op dinsdag 10 augustus 2021 @ 08:13:
Kwam net deze tegen. https://shop.tx-team.de/N...l/DuoBox-Business::8.html

Weet uiteraard niet of dat schaalt met bijvoorbeeld de huidige thuis Gbit verbindingen, maar toch het vermelden waard.

Een dual-core uit 2013 zonder AES-NI... Voor het geld is er heel veel beters te krijgen

[GoldenBatt]

Tom Paris schreef op dinsdag 10 augustus 2021 @ 11:57:
[...]


Een dual-core uit 2013 zonder AES-NI... Voor het geld is er heel veel beters te krijgen

Die zag ik in eerste instantie nog over het hoofd, viel al beetje over de "2x Realtek" poorten en een niet gespecificeerde "300 Mbit Dual-Band WLAN module"

Draai zelf al tijdje pfSense in een VM op mijn unraid server. Al merk ik dat deze het er soms lastig mee heeft, maar een intel G4560 draaien, en met wat andere load er bij op, en wat openvpn verbindingen heeft deze CPU het soms zwaar te voorduren. Ook als met server wat onderhoud doe oid heb ik tijdelijk geen internet. Toch eens kijken of niet een leuk boxje aan kan schafen, maar vindt nogal lastig om iets uit te zoeken en te weten wat ik nu echt nodig heb als ik met kpn pppoe 1gbit wil draaien, met dingen als snort er bij aan.