Messages

Hallo an alle,

ich muss das Thema kurz wieder vorholen. Ziwchenzeitlich hab ich die Rules zu Rules new umgezogen und nun ist mir folgendes aufgefallen. Wenn ich nun einen Client auf beispielsweise 1.1.1.1 oder 8.8.8.8 DNS festklemme und nen internen Namen auflöse klappt es weiterhin. Was aber irritiert ist, dass der Client konstant zuerst zwei Mal ein DNS Request Timeout bekommt und erst beim dritten Versuch dann den internen Namen auflösen kann. Hat jemand eine Idee?

Zusätzlich bin ich mit dem DHCP noch auf Kea auf der OPnsense umgezogen.


Ich bin der Meinung zum damaligen Zeitpunkt, als ich den Thread erstellt habe, ging dies direkt mit der ersten Anfrage. Grübel Grübel.
Für Tipps und Hinweise wäre ich dankbar.

Beste Grüße

Hi nochmal,

jetzt wollte ich das Thema nochmal von der anderen Seite angehen. Aktuell hat der MiniPC zwei Anschlüsse mit Realtek Netzwerkchip und läuft sauber. Telekom Anschluss mit PppoE, WireGuard, zenarmor. Auch die Performance passt gut.

@meyergru und @patrick, ihr habt da sicherlich mehr Erfahrungswerte als ich. Ist ein Betrieb mit Realtek soweit ok oder muss ich befürchten, dass bei jedem Update oder so die Chance mit Realtek höher ist, dass etwas nicht klappt? Also sind mit Realtek Chipsätzen mehr Probleme zu erwarten oder kann man die Realteks bedenkenlos einsetzen, weil der Problematik mittlerweile beigekommen ist und der Treiber soweit stabil ist?

Erneut vielen Dank für eueren Input.

Grüße

Und wie ist is, wenn du mtu nicht spezifizierst und auf default Einstellungen lässt? Geh davon aus der physische Port ist exklusiv der VM zugewiesen?

Hallo,

noch ein etwas eher unfachmännischer Kommentar, der aus Sicht einer Person kommt, die mit IT eher auf der Prozess- und Organisationsebene zu tun hat....

Bin gestolpert über den Hinweis, sinngemäß... Standort, an dem bald keine Leute mehr sind....

Passt den die Organisation / Aufbau noch im Sinne, benötigt man das ,,komplexe" Konstrukt denn zukünftig noch, in dieser Art? Würde sich mit einer gewissen Reorganisation vielleicht auf die kommerziellen Produkte verzichten lassen?

Nur so ein Gedanke...

Beste Grüße

Du bekommst bei Amazon solche Mini-Firewalls als Barebones zwar für < 200€. Leider sind inzwischen die Preise für RAM stark gestiegen, weshalb Modelle mit RAM und SSD meist bei > 300€ landen. Der billigste 8 GByte SODIMM DDR5 kostet schon ca. 100€, eine 256 GByte SSD ca. 50€ - unter 300€ wirst Du wohl nur noch gebraucht landen.

Es gibt aber manche Modelle mit N100 (kaum langsamer), die noch DDR4 einsetzen, dann wird es etwas billiger:

https://www.amazon.de/dp/B0F5GJ2JHP
https://www.amazon.de/dp/B09F4CT8LV
https://www.amazon.de/dp/B07BL2WXB9

Ich habe auch einen mit N150 gefunden: https://www.amazon.de/dp/B0FCY3CFW7, allerdings sieht die Kühlung da schlechter aus.

Ich würde immer die Selbstaufrüstung vorziehen, weil Du dann keine No-Name-Bauteile bekommst.

Ach stimmt, die Barebones. Besten Dank @meyergru! Schau ich bei denen nochmal. Da steht glücklicherweise der Netzwerkchipsatz dabei.

Danke auch @Patrick.

😃👍🙏

Das hilft mir sehr und komme weiter!!!
P.s. auch dir besten Dank @newbe

Man findet reichlich Mini PCs mit 2x LAN Schnittstellen, Blackview, SOYO Mini, GMKtec...:

Mini-PC SOYO M4 Mini Intel Twin Lake N150 Prozessor LPDDR5 12 GB RAM 512 GB ROM Windows 11 Pro WiFi 5
https://de.aliexpress.com/item/1005010734755262.html
138,75€

Ich habe u.a. Blackview und kann nicht meckern, auch welche die seit Monaten 24/7 laufen.

Nutzererfahrung findest du auch hier: https://www.mydealz.de/gruppe/mini-pc

Hi,

mein Thema war nicht einen Mini-PC zu finden sondern einen der Dual LAN mit Intel Netzwerkchipsätzen hat...

Danke dir!

Der Beelink EQ14 hätte z.B. definitiv Intel-Schnittstellen (KTI226-V). Ich hab einen ME-Mini von denen als NAS und bin recht zufrieden.

https://www.bee-link.com/de/products/beelink-eq14-n150

Hallo Patrick,

besten Dank dir! Leider übersteigt die Empfehlung etwas mein Budget. Kennst du einen, der unter 300€ liegt?

Dankeschön:-)

Hi,

ich bin auf der Suche nach neuer Hardware. Ich möchte mir einen dieser kleinen Mini-China-PCs holen mit dem N150 und Dual-Lan. Soweit passt auch alles, nur leider bekommt man so gut wie nicht raus, welcher Chipsatz für die Netzwerkkarten verwendet wird. Habe jetzt schon zwei Stück bei Amazon testweise bestellt und beide hatten einen Realtek Chip.

Daher die Frage, ob jemand einen dieser N150 Mini-PCs in Verwendung hat und mir empfehlen kann, allerdings mit Intel Netzwerkchip?

Die Dinger findet man zu Hauf bei Amazon, oft auch mit Dual-Lan, nur den Chipsatz gibt keiner an...

Vielen Dank vorab und beste Grüße

ok, opnsense doin' the job right already. Thanks again!

Ok. Thx Patrick. It seems we have the same setup with telekom, vlan 7, pppoe . May I ask what mtu values you definded and entered in your setup for

1. physical adapter =
2. vlan adapter =
3. pppoe mtu in pppoe config not wan =

This would a big help to me. Thank you!

@meyergru
Thx for the information. In first place the ip was another one: 1.1.1.1 But I get really strange values running the script wit an externel ip. Maximum MTU size would the be 3654 which looks incorrect to me. Iirc was 192.168.1.1 is the ip fo my modem but your right. Also makes no sense testing with that.

Thx Patrick. So the this would end up in leavin the mtu fields in physical adapter, vlan and pppoe empty because of calculated mtu size of pppoe is right and set by opnsense?

Or only set 1492 in pppoe settings?

Without any mtu set and running the provided script with destination ip 192.168.1.1 the result I get is 1226. Don't get it whats the matter here.

Thx again!

Hi and thx for the guide. I red it an my question ist related to telekom internet via pppoe and an underlying vlan 7. All i could find stated that the telekom don't support jumbo frames. In this case, the opnsense calculated mtu of 1492 (in settings of pppoe)  is ideal?
I'm not sure because of this article is my conclusion that the mtu of the pppoe interface should be 1488. Assuming telekom backbone hardware runs ethernet with mtu 1500, then subtract 4 for vlan and 8 for pppoe. What I'm missing in this theory?

Thx a lot!

Hi und vielen Dank für die Beteiligung zu meiner Frage. So wie Patrick es darstellt war auch mein Gedanke, welcher jetzt nochmal bestätigt wurde.
@viragomann - ich hatte auch zuerst meine Zweifel ob da nicht doch as vorbeigeht und deswegen nochmal auf ip basis auf der opnsense hinterlegt. Aber die logik ist wie patrick sie beschrieben hat auch wenns erstmal nicht logisch klingt, dass doh sich selber ersteinmal auflösen muss... aber pihole blockt es schön weg und das wollte ich erreichen: alle anfragen an pihole und wenn du dich absolut weigerst meinen pihole dns zu nutzen, dann block ich dich. klar, mit blocklisten hängst immer ein wenig hinterher, aber alles besser wie ohne :-)

Für den Fall, dass ips von doh servern hart-codiert sind, darf die opnsene eben auch noch blocken. hagezi hat dafür extra ein liste mit ip adressen, die nicht vorher aufgelöst werden müssen und direkt verwendet werden kann.

Besten Dank euch nochmal. @meyergru -> dot ist mit port 853 einfach geblockt und somit erledigt.

Ich würde nun gerne wissen, ob das so sinnig ist (ja, es funktioniert)

Ja, alle Settings sind nötig, damit es funktioniert.

oder ob man es schöner lösen kann

Ja, man könnte den PiHole in ein eigenes Netzwerksegment legen.
Dann wäre die Outbound NAT Regel überflüssig. Damit würde der Pi DNS die tatsächlichen Client IPs sehen anstatt jener der OPNsense.

und ob ich für Wireguard Road Warriors (iPhone, Notebook), die sich zu Hause einwhählen auch die Outbound und NAT Port Forward Rule entsprechend analog hinterlegen muss?

Die Road Warriors kannst du erstmal nicht zwingen, DNS Anfragen zum VPN Server zu senden. Sie können das nur freiwillig tun.
Die Outbound NAT Regel ist nicht nötig. Die wird nur benötigt, wenn DNS Clients und Server im selben Netzwerksegment liegen.
Die Port Forwarding Regel macht Sinn für den Fall, dass die DNS Anfrage an der OPNsense ankommt, aber zum Internet raus will. D.h., wenn der gesamte Upstream Traffic der Clients über die VPN geroutet wird.

Edit:
Möchte noch hinzufügen, die Block-Regel ist in meinen Augen überflüssig. Denn alle DNS Anfragen, die von anderen Geräten als dem PiHole kommen und ein anderes Ziel als diesen haben, werden ohnehin umgeleitet und erlaubt.
Was da übrig bleibt, ist gleich null.
Aber ich weiß, manche Leute schlafen dennoch besser, wenn sie das zusätzlich noch blockieren.

Du könntest aber erwägen, DNS ober HTTPS zu blockieren, um hier den Clients keine Alternative zu ermöglichen. Dafür gibt es IP-Listen im Internet.

Hi viragomann,
vielen Dank für deinen Input :-). Hilft mir sehr.... DoT hab ich generell geblock und DoH über Blocklisten. Die Blocklisten hab ich auch auf dem PiHole hinterlegt, der da schon einiges wegblockt. Trotzdem hab ich sie auch auf der OPNSense hinterlegt. Da die OPNsense auch den PiHole für DNS nutzt hab ich auf dem PiHole eine neue Group hinterlegt in der nur die OPNsense ist und die DoH Blocklisten nicht angewendet werden, damit OPNsense wiederum die Alias abfrage machen kann und die entsprechenden IPs bekommt.

Hallo,
es gibt dafür bereits einige Threads etc. Allerdings hatte ich immer wieder die Schwierigkeit, dass einzeln genommen keine wirklcih funktioniert hat bei mir. Aktuell klappt es mit einem Mix aus mehreren Posts ich würde aber gerne wissen, ob die Einstellungen so korrekt sind.

 
Es geht darum Clients zu zwingen PiHole zu verwenden und ggf. die Anfragen dahin umzuleiten. Es wurden dazu der Post auf labzilla DNS SmartTV und Threads im hier im Forum verwendet.

Setup: OPNSense ist Gateway, PiHole DHCP und DNS Server

Interface LAN:

1. Regel -> Erlaube DNS Anfragen von PiHole
2. Regel -> Blocke alle DNS anfragen LAN NET

NAT Port forward:

1. Regel: Alle DNS Anfragen  die nicht von PiHole kommen und nicht zu PiHole wollen redirecten zu PiHole DNS Port

Allerdings hatte ich damit nicht den gewünschten Erfolg. Wenn ich auf nem Windows Client nen public DNS Server hinterlegt hatte aber einen nur intern verfügbaren Namen auflösen wollte klappte das nicht.

Also noch eine Outbound Rule hinzugefügt

1. Anfragen mit Source LAN Net mit dem Ziel PiHole und Port DNS erfolgt Translation / Target Interface Adress

Und so funktioniert es dann. Interner Windows Client mit fest eingetragenem externen DNS 8.8.8.8 kann nur intern verfügbare Domains auflösen

Ich würde nun gerne wissen, ob das so sinnig ist (ja, es funktioniert) oder ob man es schöner lösen kann und ob ich für Wireguard Road Warriors (iPhone, Notebook), die sich zu Hause einwhählen auch die Outbound und NAT Port Forward Rule entsprechend analog hinterlegen muss?