Hilfe EdgeRouter zwei DHCP ein Subnetz

[MC Drehstuhl]

Moin,

Ich habe zwei Subnetze die getrennt sind, 34 und 36. Jetzt möchte ich ein paar Clients von 34 in 36 packen aber zugriff auf 34 haben.

Also Firewall Regel angelegt, kein Problem. Auf Basis von IPs (Adressgruppe) gewähre ich das Recht von 36 auf 34 zuzugreifen.

Es gibt zwei verschiedene DNS Server.
DNS34
DNS36

Die Clients die in 34 waren sollen aber weiterhin DNS34 benutzen, deswegen habe ich im Netz 36 zwei DHCP Server erstellen.
DHCP36.1 - DNS36
DHCP36.2 - DNS34

Die Clients aus 34 sollen DHCP36.2 bekommen, wo der DNS34 eingetragen ist. Damit da nichts falsch läuft habe ich den DHCP Bereich nur so groß gemacht wie Clients da sind und statisch über den DHCP vergeben. Allerdings bekommen die Clients immer eine IP von DHCP36.1 obwohl eine statische IP im DHCP36.2 vergeben ist. Die MAC ist richtig, auch die ID.

Weiß einer woran das liegen kann?

 

[hominidae]

Wenn Du wirklich sicherstellen willst, dass Clients immer den "richtigen" DNS nutzen, würde ich mich nicht auf DHCP verlassen.
Da Du schon mit Adressgruppen umgehen kannst, würde ich halt eine portforwarding rule je gruppe auf den passenden DNS machen (dest-nat für port 53 udp und tcp).
Wie das im Edgerouter geht weiss ich allerdings nicht...nutze RouterOS/Mikrotik.

 

[MC Drehstuhl]

Danke dir, Destination NAT hat geholfen. Funktioniert jetzt super. Ich werde heute Abend mal hier schreiben wie genau ich das jetzt gemacht habe falls das jemand anders braucht.

 

[MC Drehstuhl]

Edit: Ich habe durch fdsonne eine bessere Lösung gefunden. Conditional DNS Forwarding. Das ist mit ein paar Zeilen auf der CLI erledigt.

configure
set service dns forwarding options server=/home.lan/10.0.9.12
commit ; save

Dabei ist "home.lan" und "10.0.9.12" muss natürlich ausgetauscht werden. Nachzulesen hier.

Funktioniert nur wenn auf dem Edgerouter auch der DNS Cache genutzt wird.

Edit ende.

Eigentlich ist das ganz einfach, ich habe mich hauptsächlich hieran gehalten.

In meinem Aufbau habe ich zwei per Firewall getrennte VLANs, eins für die WG und eins wo meine Domäne läuft. Jetzt wollte ich aber meine Clients in das WG Netz aber meine Domäne sollte im anderen Netz bleiben und durch die Firewall getrennt, damit nicht jeder reinkommt. Damit das Funktioniert muss mein Domänenclient natürlich den AD DNS erreichen, aber die anderen sollen das nicht.

VLAN für die AD: 34
VLAN für die WG: 36

Interface VLAN34: Switch0.34
Interface VLAN36: Switch0.36

Subnetz VLAN34: 192.168.34.0/24
Subnetz VLAN36: 192.168.36.0/24

DHCP Server für VLAN34: VLAN34
DHCP Server für VLAN36: VLAN36

Neues Client IPs: 192.168.36.30, 192.168.36.31 (diese werden vom DHCP Server vergeben und dann statisch zugewiesen)

Als erstes weisen wir die IPs statisch zu.

Services > DHCP Server > Actions > View Leases

Dann rechts neben dem Gerät auf "Map Static" Klicken, dann kann die IP noch angepasst werden und dann Speichern.


Als nächstes eine Adressgruppe angelegen, wo die IPs der Clients eingetragen werden, um leichter zu managen wer umgeleitet wird.

Firewall / NAT > Firewall / NAT Groups > + Add Group

Name: Denkt euch was aus
Description: Was steckt drin?
Group Type: Address Group

Dann wieder auf "Actions" klicken und die IPs eintragen, die ihr eben statisch zugewiesen habt.

Dann kann man auch schon die Destination NAT Regel erstellen.

Firewall / NAT > NAT > +Add Destination NAT Rule

Description: Denkt euch was aus
Inbound Interface: Switch0.36 _______________ Das Interface auf dem die Anfragen der Clients ankommen.
Translation Address: 192.168.34.42 ___________ Die IP den DNS Servers auf den umgeleitet werden soll.
Translation Port: 53
Protocol: Both TCP and UDP
Src Address Group: Eure erstellte Adressgruppe _ Nur diese Adressen werden umgeleitet, alle anderen benutzen den im DHCP Server benutzen DNS Server.
Dest Port: 53



Danach muss noch eine Firewall Regel erstellt werden, damit die Clients zum DNS Server im anderen Subnetz kommunizieren dürfen. Aber auch nur wenn ihr die Subnetze getrennt habt, so wie hier.

Firewall / NAT >Firewall Policies > und da eure Guest_In bzw. die Regel die auf dem Interface ist, in dem die Clients sich befinden werden.

Reiter "Basic":

Description: Denkt euch wieder was aus
Action: Accept
Protocol: Both TCP ans UDP

Reiter "Source"

Address Group: Eure erstellte Gruppe
Port: 53

Reiter "Destination"

Address: Die IP des DNS auf den ihr weiterleiten wollt
Port: 53

Oder ihr lasst den ganzen Verkehr zu, wie ich damit ich mit meinen Clients auch die Restlichen Server erreichen kann.

Reiter "Basic":

Description: Denkt euch wieder was aus
Action: Accept
Protocol: all

Reiter "Source"

Address Group: Eure erstellte Gruppe

Reiter "Destination"

Network Group: Die Gruppe wo eure abgetrennten Netze drin sind (Wurde erstellt als die Subnetze durch die Firewall getrennt wurden)

Ich hoffe alles ist verständlich und auch richtig. Falls jemandem etwas auffällt was falsch ist bitte bescheid geben.

 

[hominidae]

...ich würde evtl. die Regel so erweitern bzw eine weitere davor einbauen (forward), welche die DNS-Server vom DST-NAT für DNS ausnimmt....falls mal die IP "irgendwie" in der falschen Gruppe landen...

 

[MC Drehstuhl]

Du meinst das ich dem DNS Server aus VLAN36 die Kommunikation zum DNS Server aus VLAN34 verbiete oder wie meinst du das genau?

 

[fdsonne]

Warum eigentlich so umständliche Konstrukte?
Du weist IPs quasi statisch zu - per DHCP mit Reservierung oder direkt als fixe IP in der Client-Config. WENN das eh so schon läuft - warum dann nicht einfach je nach Client den DNS richtig setzen?


Das was da gemacht wurde ist irgendwie nur halbgar. Wozu der Aufwand? Was bezweckst du denn damit? Welchen Mehrwert versprichst du dir davon?

 

[hominidae]

Nein, ich meine eine Regel die verhindert, dass die DNS-Server durch die DST-Nat Regeln ausgesperrt werden,...wenn durch eine fehlerhafte IP-Adressliste (wenn die IP des DNS A oder DNS B da reinrutscht) in der config zB dann die DST-NAT Regel verhindert, dass die eigentlichen DNS-Server noch mit ihren DNS-Anfragen (ist ja der gleiche Port - Anfrage von A wird dann an A weitergeleitet -> loop, stille, nada) an den "Haupt-"-DNS-Server ins I-Net kommen.
In einem solchen Fall hättest Du Dich von DNS komplett ausgesperrt...unschön und, wie man ja sagt "shit happens"...also lieber eine Regel davor einschieben, die DNS Anfragen ins I-Net von den DNS-A oder DNS-B Servern erlaubt.

- - - Updated - - -

Warum eigentlich so umständliche Konstrukte?
Du weist IPs quasi statisch zu - per DHCP mit Reservierung oder direkt als fixe IP in der Client-Config. WENN das eh so schon läuft - warum dann nicht einfach je nach Client den DNS richtig setzen?

...weil Clients das über DHCP erhaltene Setting überschreiben können?

 

[fdsonne]

...weil Clients das über DHCP erhaltene Setting überschreiben können?

Und ohne DHCP wohl nicht?

 

[hominidae]

...doch, natürlich, aber war das hier die Frage?
Wenn ich sicher sein will, dass jeder Client den für ihn vorgesehenen DNS benutzt greife ich die Anfragen in der FW ab und leite die an den vorgesehenen DNS, egal was der Client eingestellt hat.

 

[fdsonne]

Nein, war nicht die Frage - aber die Frage, die gestellt wurde, ist halt bisschen "komisch", weil sie auf ein Konstrukt hin ausgerichtet ist, was so einfach keinen Sinn ergibt.

Wenn der Client eh IP und DNS nach belieben verändern könnte - was bringt dir dann das NAT?
Mit dem selben Maßstab, dass es "OK" wäre, wenn er das tut - dann gehts halt im Zweifel nicht, könnte man einfach per statischem DNS (bei statischer IP Vergabe) oder eben per DHCP Reservierung mit anderen DNS Einträgen arbeiten. -> Das Risiko, dass die Einträge am Client geändert werden ist exakt identisch. Fingert der User nicht in der Config - gehts. Fingert er drin rum, dann kann er es auch verbiegen wie er lustig ist.

PS: euer NAT Konstrukt bietet auch effektiv keinen Schutz oder so. Eine Firewall die offen ist, ist halt nicht wirksam. Und die beschriebene Regel besagt, dass eine Source IP so und so per DNS zum 34er DNS Kommunizieren darf. WENN man nun also davon ausgeht, dass da Spielmätze unterwegs sind. Warum geht man dann nicht auch einfach davon aus, dass da einer bei sein könnte, der sich vllt mal an einem Source NAT probiert? Geht mit jedem x-beliebigen Linux. Bei Windows brauchs eine Server Version. Und schon ist man (ohne dass das primär erstmal jemand merken wird) in der Lage, DNS zum 34er zu sprechen ohne das das eigentlich funktionieren soll...
Wozu also der Aufwand??

 

[MC Drehstuhl]

Warum eigentlich so umständliche Konstrukte?
Du weist IPs quasi statisch zu - per DHCP mit Reservierung oder direkt als fixe IP in der Client-Config. WENN das eh so schon läuft - warum dann nicht einfach je nach Client den DNS richtig setzen?


Das was da gemacht wurde ist irgendwie nur halbgar. Wozu der Aufwand? Was bezweckst du denn damit? Welchen Mehrwert versprichst du dir davon?

Der Mehrwert ist für mich ganz einfach. Ich wohne in einer WG, meine Mitbewohner wollen kein Gastnetz und Freunde sollen auch mal was an den FireTV Stick schicken können. Ich möchte aber nicht das jeder der im WLAN ist einfach meine Server erreichen kann, obwohl sie über eine ordentliche Rechtevergabe und Benutzerkonfiguration abgesichert sind. Außerdem möchte ich nicht das alle den DNS Server der Domäne benutzen, umso weniger da los ist umso besser die Performance.
So jetzt hat es mich aber genervt immer wenn ich was auf dem FireTV abspielen wollte oder Musik über Spotify Connect hören will, was ziemlich oft vorkommt, immer das WLAN zu wechseln oder das Handy zu holen. Oder wenn ich mal kurz mit einem hier ne runde ein Spiel im LAN spielen will.
Also brauchte ich eine Lösung dafür, und die Vorgeschlagene ist deutlich besser als mein DHCP Zeug was ich mir gedacht habe.
Das mit dem FireTV könnte man lösen, wenn DNS Multicast VLAN übergreifend laufen würde, die EdgeRouter eigene Lösung hat nicht funktioniert und den Avahi Deamon ,der laut Internet funktioniert, möchte ich nicht installieren, weil wenn irgendetwas mit dem Router ist, ich einfach einen Reset machen und eine Config Datei Hochladen will. Avahi müsste ich dann wieder manuell installieren.

Eine feste IP Config auf den Clients ist doof, da alle Geräte auch wo anders benutzt werden und ich nicht ständig etwas ändern möchte, auch wenn man was mit Scripten bauen könnte, will ich einfach den Laptop aufklappen und loslegen.

Nein, ich meine eine Regel die verhindert, dass die DNS-Server durch die DST-Nat Regeln ausgesperrt werden,...wenn durch eine fehlerhafte IP-Adressliste (wenn die IP des DNS A oder DNS B da reinrutscht) in der config zB dann die DST-NAT Regel verhindert, dass die eigentlichen DNS-Server noch mit ihren DNS-Anfragen (ist ja der gleiche Port - Anfrage von A wird dann an A weitergeleitet -> loop, stille, nada) an den "Haupt-"-DNS-Server ins I-Net kommen.
In einem solchen Fall hättest Du Dich von DNS komplett ausgesperrt...unschön und, wie man ja sagt "shit happens"...also lieber eine Regel davor einschieben, die DNS Anfragen ins I-Net von den DNS-A oder DNS-B Servern erlaubt.

Aber macht die Regel Sinn? Ich habe ja als Interface für die Anfragen Switch0.36 angegeben, das heißt es werden nur anfragen umgeleitet die auf diesem Interface reinkommen. Und mein DNS Server auf den ich umleite kommuniziert ja über Switch0.34 mit dem Internet. Also auch wenn ich die IP versehentlich eintrage macht das doch nichts, da Switch0.34 nicht betroffen ist.
Und falls die IP vom DNS Server im VLAN36 da rein rutscht werden seine Anfragen doch über den DNS im VLAN34 verarbeitet und gehen von da ins Internet.

Oder habe ich da jetzt einen Denkfehler?

Aber ja den DNS Server aus VLAN36 kann ich so absichern, damit er nicht alles im Fall der fälle auf meinen DNS weiterleitet.

 

[hominidae]

...ja, das Kontrukt ist "komisch", aber deswegen ging es mir um eine schnelle Lösung für den TE....hat ja wohl auch funktioniert.
Das Thema "Schutz" ist im Kontext DNS eh fragwürdig...die IP eines Ziel-Servers kriege ich, mit ein wenig Ausdauer, auch ohne DNS-Query raus...

 

[MC Drehstuhl]

Nein, war nicht die Frage - aber die Frage, die gestellt wurde, ist halt bisschen "komisch", weil sie auf ein Konstrukt hin ausgerichtet ist, was so einfach keinen Sinn ergibt.

Wenn der Client eh IP und DNS nach belieben verändern könnte - was bringt dir dann das NAT?
Mit dem selben Maßstab, dass es "OK" wäre, wenn er das tut - dann gehts halt im Zweifel nicht, könnte man einfach per statischem DNS (bei statischer IP Vergabe) oder eben per DHCP Reservierung mit anderen DNS Einträgen arbeiten. -> Das Risiko, dass die Einträge am Client geändert werden ist exakt identisch. Fingert der User nicht in der Config - gehts. Fingert er drin rum, dann kann er es auch verbiegen wie er lustig ist.

Im Edgerouter kann ich, in der GUI jedenfalls, keinen extra DNS Server für eine Statische IP angeben, es wird die aus dem DHCP Server genommen. Auf jeden Fall nicht das ich wüsste. Der DHCP muss aber über den Router laufen, weil wenn ich was am Server kaputt mache und meine Mitbewohner deswegen kein Internet haben ist das nicht gut. Nur weil ich mir eine Extrawurst gönne sollen die andern nicht gestört werden.

PS: euer NAT Konstrukt bietet auch effektiv keinen Schutz oder so. Eine Firewall die offen ist, ist halt nicht wirksam. Und die beschriebene Regel besagt, dass eine Source IP so und so per DNS zum 34er DNS Kommunizieren darf. WENN man nun also davon ausgeht, dass da Spielmätze unterwegs sind. Warum geht man dann nicht auch einfach davon aus, dass da einer bei sein könnte, der sich vllt mal an einem Source NAT probiert? Geht mit jedem x-beliebigen Linux. Bei Windows brauchs eine Server Version. Und schon ist man (ohne dass das primär erstmal jemand merken wird) in der Lage, DNS zum 34er zu sprechen ohne das das eigentlich funktionieren soll...
Wozu also der Aufwand??

Ich gehe nicht davon aus das hier Spielmätze unterwegs sind, sondern das jemand etwas unbeabsichtigt macht oder einschleppt. Und wenn jemand was böses wollte, müsste er erstmal eine der IPs herausfinden, die Statisch vergeben sind.

 

[hominidae]

...Dein Denkfehler besteht darin, dass Du den UseCase untersuchst, ob er standardmässig unter den von Dir vorgegebenen Randbedingungen funktioniert, was er ja tut.....was passiert, wenn Du unabsichtlich eine Fehlconfig machst und Deine Annahmen nicht mehr stimmen?
Ich würd mich aber jetzt nicht so reinhängen für dieses Ding ;-)

- - - Updated - - -

Im Edgerouter kann ich, in der GUI jedenfalls, keinen DNS Server für eine Statische IP keinen eigenen DNS Server angeben. Auf jeden Fall nicht das ich wüsste.

Wie gesagt kenne ich das Teil nicht, aber das ist kein Thema der DNS-Config, sondern des DHCP-Servers (oder des DHCP-Pools)....welche Parameter dem Client bei einer Zuteilung übergeben werden.
Edit: guck mal hier: EdgeRouter - Custom DHCP Server Options Ubiquiti Networks Support and Help Center

 

[MC Drehstuhl]

...ja, das Kontrukt ist "komisch", aber deswegen ging es mir um eine schnelle Lösung für den TE....hat ja wohl auch funktioniert.
Das Thema "Schutz" ist im Kontext DNS eh fragwürdig...die IP eines Ziel-Servers kriege ich, mit ein wenig Ausdauer, auch ohne DNS-Query raus...

Und für deine schnelle Hilfe die zielführend war möchte ich dir danken.

Aber ist es nicht eher Sinnvoll mit der Ausdauer eine der IPs die frei sind herauszubekommen? Dann darfst du im ganzen Netz unterwegs sein und nicht nur zum DNS Server.

...Dein Denkfehler besteht darin, dass Du den UseCase untersuchst, ob er standardmässig unter den von Dir vorgegebenen Randbedingungen funktioniert, was er ja tut.....was passiert, wenn Du unabsichtlich eine Fehlconfig machst und Deine Annahmen nicht mehr stimmen?
Ich würd mich aber jetzt nicht so reinhängen für dieses Ding ;-)

- - - Updated - - -


Wie gesagt kenne ich das Teil nicht, aber das ist kein Thema der DNS-Config, sondern des DHCP-Servers (oder des DHCP-Pools)....welche Parameter dem Client bei einer Zuteilung übergeben werden.

Naja für den Fall der Fehlconfig habe ich ja von davor ein Configfile und in 5min bin ich am ausgangspunkt
Ja ich weiß ich kann aber nur einen für den gesamten Pool angeben. Der Satz ist ein bisschen falsch, ich schiebe es auf die Uhrzeit.

 

[fdsonne]

Im Edgerouter kann ich, in der GUI jedenfalls, keinen extra DNS Server für eine Statische IP angeben, es wird die aus dem DHCP Server genommen.

Wie gesagt kenne ich das Teil nicht, aber das ist kein Thema der DNS-Config, sondern des DHCP-Servers (oder des DHCP-Pools)....welche Parameter dem Client bei einer Zuteilung übergeben werden.

Das wäre halt der einfache(re) Weg das einfach rauszubekommen. Dann spart man sich den ganzen NAT Unsinn komplett. Und wenn man dann noch keinem böses unterstellt ist das auch alles im Lot.

Nenn doch mal den exakten Typ des Routers - vllt kann dir da geholfen werden.

Und nicht falsch verstehen, das NAT Konstrukt geht technisch. Aber NAT ist einfach keine gute Lösung. Bringt dir möglicherweise auch ein mal Probleme - ein Client könnte bspw. die NAT Table voll schreiben und dann macht der Router vllt nix mehr, knickt in der Performanc ein, verwirft Pakete oder weis der Geier was. (alles schon erlebt)
Bei Windows Clients wird dir sowas wahrscheinlich nicht passieren - aber mit Linux oder irgendwelchen Geräten unbekannter Natur wäre das denkbar. Vor allem dann, wenn kein lokaler DNS Cache aktiv ist auf dem Client Gerät. (was nicht zwangsweise der Fall sein muss - bei Windows ist es das per Default)

Der DHCP muss aber über den Router laufen, weil wenn ich was am Server kaputt mache und meine Mitbewohner deswegen kein Internet haben ist das nicht gut. Nur weil ich mir eine Extrawurst gönne sollen die andern nicht gestört werden.

Dafür kannst du doch "kreuz" jeweils den anderen hinterlegen. So dass der Spaß immer beim Client mindestens mit einem Server funktioniniert.
Theoretisch wäre sogar an der Stelle ein conditional DNS Forwarder für die Domain deines ADs noch einfacher. Denn dann fragen die beiden Sonder-Clients im 36er Netz einfach den normalen DNS aus dem 36er, welcher alle Anfragen zum AD einfach zu diesem weiter leitet.
Dass DNS Anfragen in so einem vergleichsweise kleinen Rahmen groß Performance kosten ist auch kein wirkliches Thema - das sind Peanuts.

 

[hominidae]

Aber ist es nicht eher Sinnvoll mit der Ausdauer eine der IPs die frei sind herauszubekommen? Dann darfst du im ganzen Netz unterwegs sein und nicht nur zum DNS Server.

...aber dafür hast Du doch verschiedene Netze und nen Router mit ner FW dazwischen ... und auf L2-Ebene kann man auch was filtern...dann müsste man IP und passende MAC herausfinden, die gerade "frei" sind um im Netzwerk rumzuspuken.
Unbekannte MACs kann man ja erstmal auf nen Hotspot umleiten...Präferenz der WG für Gästenetz hin oder her ;-)

- - - Updated - - -

Naja für den Fall der Fehlconfig habe ich ja von davor ein Configfile und in 5min bin ich am ausgangspunkt

...ich weiss nicht, meine Configfiles sind irgendwie immer gerade am eigentlichen Zeitpunkt vorbei erstellt, den ich wieder bräuchte ;-)

 

[MC Drehstuhl]

Das wäre halt der einfache(re) Weg das einfach rauszubekommen. Dann spart man sich den ganzen NAT Unsinn komplett. Und wenn man dann noch keinem böses unterstellt ist das auch alles im Lot.


Nenn doch mal den exakten Typ des Routers - vllt kann dir da geholfen werden.

Das geht im DHCP nicht, auch nicht über die CLI. Ist ein Edgerouter ER-X.

Und nicht falsch verstehen, das NAT Konstrukt geht technisch. Aber NAT ist einfach keine gute Lösung. Bringt dir möglicherweise auch ein mal Probleme - ein Client könnte bspw. die NAT Table voll schreiben und dann macht der Router vllt nix mehr, knickt in der Performance ein, verwirft Pakete oder weis der Geier was. (alles schon erlebt)
Bei Windows Clients wird dir sowas wahrscheinlich nicht passieren - aber mit Linux oder irgendwelchen Geräten unbekannter Natur wäre das denkbar. Vor allem dann, wenn kein lokaler DNS Cache aktiv ist auf dem Client Gerät. (was nicht zwangsweise der Fall sein muss - bei Windows ist es das per Default)

Ok, das wusste ich nicht. Aber besser als das es garnicht geht. Clients sind nur Windows und ein Android.

Dafür kannst du doch "kreuz" jeweils den anderen hinterlegen. So dass der Spaß immer beim Client mindestens mit einem Server funktioniniert.
Theoretisch wäre sogar an der Stelle ein conditional DNS Forwarder für die Domain deines ADs noch einfacher. Denn dann fragen die beiden Sonder-Clients im 36er Netz einfach den normalen DNS aus dem 36er, welcher alle Anfragen zum AD einfach zu diesem weiter leitet.
Dass DNS Anfragen in so einem vergleichsweise kleinen Rahmen groß Performance kosten ist auch kein wirkliches Thema - das sind Peanuts.

Ne, das mit dem über "Kreuz" lass ich. Aber danke für den Tipp mit dem conditional DNS Forwarder. Das kannte ich noch gar nicht. Das geht, dafür muss ich aber auf dnsmasq als DHCP umsteigen, kann ich also erst die Tage machen wenn keiner Zuhause ist. EdgeOS kann halt nur dnsmasq oder ISC DHCP aber nicht beides gleichzeitig.

...aber dafür hast Du doch verschiedene Netze und nen Router mit ner FW dazwischen ... und auf L2-Ebene kann man auch was filtern...dann müsste man IP und passende MAC herausfinden, die gerade "frei" sind um im Netzwerk rumzuspuken.
Unbekannte MACs kann man ja erstmal auf nen Hotspot umleiten...Präferenz der WG für Gästenetz hin oder her ;-)

- - - Updated - - -


...ich weiss nicht, meine Configfiles sind irgendwie immer gerade am eigentlichen Zeitpunkt vorbei erstellt, den ich wieder bräuchte ;-)

Ja ich weiß, war auf dein IP des DNS Server herausfinden bezogen. Ist ja auch egal. Ans MAC Filtern habe ich noch gar nicht gedacht, da die Netze bis jetzt ja von einander getrennt war. Das "Gastnetz" durfte nur auf anfragen Antworten.

Ich erstelle Configfiles deswegen bevor ich was ändere und wenn es funktioniert danach wieder

 

[MC Drehstuhl]

Ne, das mit dem über "Kreuz" lass ich. Aber danke für den Tipp mit dem conditional DNS Forwarder. Das kannte ich noch gar nicht. Das geht, dafür muss ich aber auf dnsmasq als DHCP umsteigen, kann ich also erst die Tage machen wenn keiner Zuhause ist. EdgeOS kann halt nur dnsmasq oder ISC DHCP aber nicht beides gleichzeitig.

So, ich muss mich selbst berichtigen, es geht auch ohne dnsmasq als DHCP Server und man kann auch beides gleichzeitig nutzen, nur nicht im gleichen Subnetz.