interner DNS für 1 client untersagen [solved]

noplan

gibts hier so eine "kranke" FW regel
das ich einen Client (IP) über ein eigenes Gateway (WAN3) rausschicken kann (ja das geht)
und ihm nebenbei noch verbiete (dem CLIENT also der IP) die PFs als DNS zu befragen.

ergo das log eines server der hinter der pfS rennt
die externe IP des (WAN3) Clients im log hat.

es ist ja schon Freitag .... ;)

lgNP

----SOLVED----
siehe Begründung hier (dann muss man nicht nach unten lesen)
https://forum.netgate.com/topic/156939/interner-dns-f%C3%BCr-1-client-untersagen/8?_=1600584802662

viragomann

@noplan said in interner DNS für 1 client untersagen:

und ihm nebenbei noch verbiete (dem CLIENT also der IP) die PFs als DNS zu befragen.

Das kannst du mit einer normalen Block-Regel machen, doch wenn der Client die pfSense als DNS konfiguriert hat (bspw. per DHCP) wird er dann nix auflösen können.
Da wäre es sinnvoller, sämtliche DNS-Abfragen des Client per NAT-Regel auf einen bestimmten Server zu leiten.

@noplan said in interner DNS für 1 client untersagen:

ergo das log eines server der hinter der pfS rennt
die externe IP des (WAN3) Clients im log hat.

Was? Der Client soll mittels WAN3 IP auf den internen Server gehen?

noplan

@viragomann

der soll übers non default gateway raus
und übers wan1 zb wieder auf den internen server rauf

jop das mit der regel hab ich mir schon überlegt,
beim NAT fehlt mir die Phantasie ... kommt aber noch ist ja noch früh ;)

danke mal für Input

viragomann

@noplan said in interner DNS für 1 client untersagen:

der soll übers non default gateway raus
und übers wan1 zb wieder auf den internen server rauf

Aha, deswegen das Adjektiv "krank".

Ich sah noch keine Notwendigkeit, etwas derartiges umzusetzen, daher keine Erfahrung, aber auch das sollte mit einer NAT-Regel gehen, Outbound NAT.
Eine Regel am Interface, an das der Server angebunden ist, mit der Client-IP als Quelle und dem Server als Ziel. Wenn gewünscht, kann auch noch der Zielport eingeschränkt werden. Als Translation Adress die Inface IP setzen (Standard).

Voraussetzung, dass es funktionieren kann, ist, dass dieses pfSense Interface das Default Gateway auf dem Server ist, denn dahin schickt er dann die Antworten für den Client, aber davon gehe ich aus.

Das Outbound NAT muss natürlich im Hybrid- oder Automatikmodus arbeiten.

noplan

@viragomann

jop so in etwa hab ich mir das aufn zettel gemalt ...
wird a spaß das zu testen ...

viragomann

@noplan
Ah ja, NAT Reflection wir da auch noch nötig sein für die NAT-Regel des Servers. Alternativ kannst du auch für den Client eine NAT-Regel externe IP > interne Server IP hinzufügen.

Mein Gott, das ist ja wirklich ein Murx. Schaffst du es, uns den Sinn dahinter zu erklären?

noplan

@viragomann

ich seh den sinn hier gerade selbst absolut nicht ...
weil wahrscheinlich freitag ist und sie hier a bissal Panik vorm nächsten homeOffice run haben ;)

geht hier glaub ich darum
hinter einer multi WAN pfs
die vidConf zu testen bei welchem provider (WAN) man die besseren / schlechtesten
live Ergebnisse hat ..

und QoS richte ich mit sicherheit hier nicht ein ;)

JeGr

@noplan said in interner DNS für 1 client untersagen:

die vidConf zu testen bei welchem provider (WAN) man die besseren / schlechtesten
live Ergebnisse hat ..

Biegs ab und sag ihnen das macht keinen Sinn. So kannste das nicht testen. Wird einfach nichts. Wenn du nicht den Traffic abzweigen kannst und bspw. über nen Tunnel an ein komplett anderes Gateway ballern kannst, dann ist jede Messung über so einen Murks komplett nutzlos. Denn:

selbst wenn dein Server A via WAN 3 rausgeht
geht er bis zur pfS
will über WAN 3 raus
erkennt: Ziel ist WAN 1 IP (oder ein Alias davon) -> schaut in die Regeln
bei aktivem Forwarding und NAT Reflection die passt -> schreibt das Paket um
schickt das umgeschriebene Paket wieder in die DMZ zu Server B rein
gesetzt den Fall die beiden Server sind auf dem gleichen Interface: brauchst du dann noch eine der berühmten "pass any from xy_net to xy_net" Regeln
(wo mich die Leute immer fragen, dass das doch keinen Sinn macht weil das doch Traffic vom Interface ist das nie geroutet wird -> JA deswegen HASST man NAT [Reflection] auch so!)

Also außer dass es im dümmsten Fall im Ring rum rotiert, passiert da gar nichts, weil es keinen Grund gibt, das Paket überhaupt erst zum Gateway von WAN3 zu schicken -> NAT Reflection greift sich das und gut.

noplan

jop ham wir ihnen schon abgedreht ...
aber die neue idee war um nix besser .... das fällt mir ja sonst erst nach ner flasche Wein ein ;)

jede Internetleitung kriegt ne APU box mit pfs dann kann man das doch testen ODER ????

----> wir sind dann mal was essen gegangen und haben ihnen erklärt was da alles zu machen ist
und was der output / nutzen ist

0,00 NULL NADA

... langsam fang ich echt an on premise vid confs mit schmalen Leitungen zu hassen,
weil die ja wirklich glauben 20 remote leute passen durch die alpenLändische ADSL Leitung ;)

JeGr

@noplan said in interner DNS für 1 client untersagen [solved]:

jede Internetleitung kriegt ne APU box mit pfs dann kann man das doch testen ODER ????