25
Ordnerfreigabe aus anderen Netzen nicht erreichbar
Moin Moin
Leider habe ich das Problem das bei mir eine Ordnerfreigabe wo unsere Userhomes drin liegen, aus anderen VLANs nicht erreichnbar sind.
Die Userhomes werden per GPO gemounted und das funktioniert auch, aber leider nur im selben Netz wo der Fileserver und DC steht.
Wenn ich mich mit dem selben User am Rechner im anderen VLAN anmelde steht im Log der GPO das der Netzwerkpfad nicht gefunden wurde.
Firewalltechnisch wird pfSense eingesetzt und laut den Logs wird zwischen dem Fileserver und dem Testrechner nichts blockiert.
der Pfad lautet: \\firmenname-fi\userhomes$ wenn ich diese aus dem Netz des Fileservers aufrufe erhalte ich die Meldung das ich keine berechtigung habe, so solls auch sein.
Wenn ich den selben Pfad aus dem anderen VLAN aufrufe erhalte ich die Meldung das es den Pfad nicht gibt.
Der Fileserver ist aus dem VLAN wo es nicht geht anpingbar und auflösbar. Alle Rechner befinden sind in der selben Domäne, Betriebssystem ist überall Windows Server 2022.
Hat irgendjemand ne Idee woran das liegen kann?
Danke
Leider habe ich das Problem das bei mir eine Ordnerfreigabe wo unsere Userhomes drin liegen, aus anderen VLANs nicht erreichnbar sind.
Die Userhomes werden per GPO gemounted und das funktioniert auch, aber leider nur im selben Netz wo der Fileserver und DC steht.
Wenn ich mich mit dem selben User am Rechner im anderen VLAN anmelde steht im Log der GPO das der Netzwerkpfad nicht gefunden wurde.
Firewalltechnisch wird pfSense eingesetzt und laut den Logs wird zwischen dem Fileserver und dem Testrechner nichts blockiert.
der Pfad lautet: \\firmenname-fi\userhomes$ wenn ich diese aus dem Netz des Fileservers aufrufe erhalte ich die Meldung das ich keine berechtigung habe, so solls auch sein.
Wenn ich den selben Pfad aus dem anderen VLAN aufrufe erhalte ich die Meldung das es den Pfad nicht gibt.
Der Fileserver ist aus dem VLAN wo es nicht geht anpingbar und auflösbar. Alle Rechner befinden sind in der selben Domäne, Betriebssystem ist überall Windows Server 2022.
Hat irgendjemand ne Idee woran das liegen kann?
Danke
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 5184921297
Url: https://administrator.de/contentid/5184921297
Printed on: April 28, 2024 at 17:04 o'clock
25 Comments
Latest comment
Moin,
so ganz spontan: Windows-Firewall auf dem Fileserver "kennt" das andere Netz/VLAN nicht [SMB nur für lokales Subnetz freigegeben]?
Gruß
cykes
so ganz spontan: Windows-Firewall auf dem Fileserver "kennt" das andere Netz/VLAN nicht [SMB nur für lokales Subnetz freigegeben]?
Gruß
cykes
Zitat von @cykes:
Moin,
so ganz spontan: Windows-Firewall auf dem Fileserver "kennt" das andere Netz/VLAN nicht [SMB nur für lokales Subnetz freigegeben]?
Gruß
cykes
Moin,
so ganz spontan: Windows-Firewall auf dem Fileserver "kennt" das andere Netz/VLAN nicht [SMB nur für lokales Subnetz freigegeben]?
Gruß
cykes
Was müsste ich da in der Firewall konfigurieren? Testweise habe ich Eingehend, UDP Port 445,139 versucht. Blieb beim gleichen Fehler.
In der vordefinierten Regel "Datei- und Druckerfreigabe (SMB ..." sowohl ein- als auch ausgehend unter Bereich "Lokales Subnetz" ersetzen mit den Server- und Client Netz.
Am Beispiel der eigehenden Regel:
Am Beispiel der eigehenden Regel:
1
Hallo @Bencaso
es gibt da so eine tolle Forenseite, wo sich IT Leute gegenseitig helfen. Vielleicht ist das ja ein Beitrag, der etwas weiter hilft.
PfSense routing zwischen zwei Netzwerken
Kreuzberger
es gibt da so eine tolle Forenseite, wo sich IT Leute gegenseitig helfen. Vielleicht ist das ja ein Beitrag, der etwas weiter hilft.
PfSense routing zwischen zwei Netzwerken
Kreuzberger
1Zitat von @cykes:
In der vordefinierten Regel "Datei- und Druckerfreigabe (SMB ..." sowohl ein- als auch ausgehend unter Bereich "Lokales Subnetz" ersetzen mit den Server- und Client Netz.
Am Beispiel der eigehenden Regel:
In der vordefinierten Regel "Datei- und Druckerfreigabe (SMB ..." sowohl ein- als auch ausgehend unter Bereich "Lokales Subnetz" ersetzen mit den Server- und Client Netz.
Am Beispiel der eigehenden Regel:
Funktioniert leider auch nicht, auch am Client habe ich eingehende Verbindungen vom Server Netz aus an der Regel erlaubt. Die ICMPv4 Regel auf beiden seiten habe ich ebensfalls angepasst.
Zitat von @kreuzberger:
Hallo @Bencaso
es gibt da so eine tolle Forenseite, wo sich IT Leute gegenseitig helfen. Vielleicht ist das ja ein Beitrag, der etwas weiter hilft.
PfSense routing zwischen zwei Netzwerken
Kreuzberger
Hallo @Bencaso
es gibt da so eine tolle Forenseite, wo sich IT Leute gegenseitig helfen. Vielleicht ist das ja ein Beitrag, der etwas weiter hilft.
PfSense routing zwischen zwei Netzwerken
Kreuzberger
Es geht nicht ums Routing auf der pfSense. Die entsprechenden Firewallregeln sind natürlich gesetzt.
Knackpunkt beim TO ist, wie immer, die lokale Winblows Firewall die generell eingehenden Traffic aus fremden IP Netzen für alle ihre Dienste blockiert. Kollege @cykes hat es ob schon richtig gesagt.
Aber leider nicht nur...
Der TO hat, vermutlich aus Protokoll Unkenntniss, zusätzlich zur Winblows FW Thematik auch einen fatalen Fehler im Firewall Regelwerk gemacht, denn SMB/CIFS nutzt bekanntlich TCP 445 und kein UDP.
https://de.wikipedia.org/wiki/Server_Message_Block
Als Winblows Administrator sollte man solche Banalitäten eigentlich kennen.
Aber leider nicht nur...
Der TO hat, vermutlich aus Protokoll Unkenntniss, zusätzlich zur Winblows FW Thematik auch einen fatalen Fehler im Firewall Regelwerk gemacht, denn SMB/CIFS nutzt bekanntlich TCP 445 und kein UDP.
https://de.wikipedia.org/wiki/Server_Message_Block
Als Winblows Administrator sollte man solche Banalitäten eigentlich kennen.
also .. mal so zum Verständnis auch für mich, da ich nun kein Netzwerk-Mega-Super-Schlaumeier bin.
Wenn ich zwischen zwei Ländern (Netzen) eine Schranke (Firewall) auf mache, woher sollen denn die Menschen (Clients) wissen, dass es diese Schranke gibt und wo diese ist?
Kreuzberger
Wenn ich zwischen zwei Ländern (Netzen) eine Schranke (Firewall) auf mache, woher sollen denn die Menschen (Clients) wissen, dass es diese Schranke gibt und wo diese ist?
Kreuzberger
Die Menschen wissen das natürlich nicht sondern einzig nur der Wachposten an der Schranke wenn sie diese sehen!!
Da heisst es dann den richtigen Pass (Regelwerk) zu haben um durchzukommen... 😉
Der TO hatte, wie man sieht, den falschen Pass und sich auch vorher nicht über die Reisemodalitäten informiert (Firewall Log!)... 😎
Da heisst es dann den richtigen Pass (Regelwerk) zu haben um durchzukommen... 😉
Der TO hatte, wie man sieht, den falschen Pass und sich auch vorher nicht über die Reisemodalitäten informiert (Firewall Log!)... 😎
@aqui
Naja, ich finde nicht, dass man als IT Mensch ALLES wissen MUSS. Das ist schlicht unmöglich.
aber .. noch mal so zum Verständnis auch für mich, da ich nun kein Netzwerk-Mega-Super-Schlaumeier bin.
Muss man dann nicht in der pfSense die Schranke für genau die Verkehrsmittel (Eisenbahn, LKW, Fußgänger / SMB) öffnen, die man da braucht? Ist der Mensch (Client) da nicht in seiner Konfiguration aussen vor und es muss generell auf der Schranke (Firewall) eingestellt sein, wer oder was durch darf? Und muss man dann nicht per DHCP zum Beispiel allem Menschen (Clients) mitteilen, dass es da diese Schranke gibt?
Kreuzberger
Naja, ich finde nicht, dass man als IT Mensch ALLES wissen MUSS. Das ist schlicht unmöglich.
aber .. noch mal so zum Verständnis auch für mich, da ich nun kein Netzwerk-Mega-Super-Schlaumeier bin.
Muss man dann nicht in der pfSense die Schranke für genau die Verkehrsmittel (Eisenbahn, LKW, Fußgänger / SMB) öffnen, die man da braucht? Ist der Mensch (Client) da nicht in seiner Konfiguration aussen vor und es muss generell auf der Schranke (Firewall) eingestellt sein, wer oder was durch darf? Und muss man dann nicht per DHCP zum Beispiel allem Menschen (Clients) mitteilen, dass es da diese Schranke gibt?
Kreuzberger
Muss man dann nicht in der pfSense die Schranke für genau die Verkehrsmittel (Eisenbahn, LKW, Fußgänger / SMB) öffnen, die man da braucht?
Jepp, genau richtig.Der TO hatte ja den falschen (UDP) Pass dabei und ohne ein TCP 445 Visum durfte er natürlich nicht einreisen. Da ist es dann klar das er nicht an den TCP 445 Strand durfte und wieder frustriert nach Hause musste.
Und muss man dann nicht per DHCP zum Beispiel allem Menschen (Clients) mitteilen, dass es da diese Schranke gibt?
Müssen muss man es nicht. Man kann es machen zumindestens bei TCP und die FW aktiv ein RST schicken lassen was dem Menschen dann klar macht das da eine Schranke ist.https://www.geeksforgeeks.org/what-is-tcp-ack-scanning/
Allerings zeigt es dann auch Schmugglern oder anderen Menschen mit bösen Absichten die Schranke auf um sie dann zu umgehen. Das will keiner der Wachposten und lässt es deshalb ohne Nachricht das die Greifertruppen von seiner Zollabteilung derer dann doch wieder habhaft werden können.
Fazit: Immer den richtigen und gültigen Pass dabei haben und die Reisebestimmungen (Log) genau lesen!
@aqui
ok, aber wie mache ich es dann dem Client verständlich, dass es innerorts (in einem lokalen Netz) eben ein weiteres lokales Netz gibt, dass ich betreten darf?
Oder noch eins drauf: Nur ausgesuchte Clients dürfen das andere Netz betreten!??!
(Bestimmte Computer oder Bestimmte Teilnehmer (Admins))
ok, aber wie mache ich es dann dem Client verständlich, dass es innerorts (in einem lokalen Netz) eben ein weiteres lokales Netz gibt, dass ich betreten darf?
Oder noch eins drauf: Nur ausgesuchte Clients dürfen das andere Netz betreten!??!
(Bestimmte Computer oder Bestimmte Teilnehmer (Admins))
Moin..
Frank
Zitat von @kreuzberger:
Hallo @Bencaso
es gibt da so eine tolle Forenseite, wo sich IT Leute gegenseitig helfen. Vielleicht ist das ja ein Beitrag, der etwas weiter hilft.
wo?Hallo @Bencaso
es gibt da so eine tolle Forenseite, wo sich IT Leute gegenseitig helfen. Vielleicht ist das ja ein Beitrag, der etwas weiter hilft.
Frank
moin...
Active-Directory-Standorte und -Subnetze verstehen
Lesen und Verstehen!
Oder noch eins drauf: Nur ausgesuchte Clients dürfen das andere Netz betreten!??!
(Bestimmte Computer oder Bestimmte Teilnehmer (Admins))
Lokale Firewall und Rechte Verwaltung!
Frank
Zitat von @kreuzberger:
@aqui
ok, aber wie mache ich es dann dem Client verständlich, dass es innerorts (in einem lokalen Netz) eben ein weiteres lokales Netz gibt, dass ich betreten darf?
da wird dir geholfen!@aqui
ok, aber wie mache ich es dann dem Client verständlich, dass es innerorts (in einem lokalen Netz) eben ein weiteres lokales Netz gibt, dass ich betreten darf?
Active-Directory-Standorte und -Subnetze verstehen
Lesen und Verstehen!
Oder noch eins drauf: Nur ausgesuchte Clients dürfen das andere Netz betreten!??!
(Bestimmte Computer oder Bestimmte Teilnehmer (Admins))
Frank
1
Einem Client kann man das grundsätzlich nicht mitteilen. Das sieht TCP/IP so auch gar nicht vor. Das was man ihm mitteilt ist das default Gateway. Also der Wegweiser der im sagt...da geht es lang in den Rest der Welt. Was auf dem Transport dann mit den Client Daten passiert weiss der Client nicht denn es gibt an jeder Schranke andere Briefträger die seine Daten übernehmen. Guckst du hier:
https://www.youtube.com/watch?v=fpqhjEtznVk
https://www.youtube.com/watch?v=fpqhjEtznVk
3
Moin...
wie Geil ist das den Bitte
Frank
Zitat von @aqui:
Einem Client kann man das grundsätzlich nicht mitteilen. Das sieht TCP/IP so auch gar nicht vor. Das was man ihm mitteilt ist das default Gateway. Also der Wegweiser der im sagt...da geht es lang in den Rest der Welt. Was auf dem Transport dann mit den Client Daten passiert weiss der Client nicht denn es gibt an jeder Schranke andere Briefträger die seine Daten übernehmen. Guckst du hier:
https://www.youtube.com/watch?v=fpqhjEtznVk
Einem Client kann man das grundsätzlich nicht mitteilen. Das sieht TCP/IP so auch gar nicht vor. Das was man ihm mitteilt ist das default Gateway. Also der Wegweiser der im sagt...da geht es lang in den Rest der Welt. Was auf dem Transport dann mit den Client Daten passiert weiss der Client nicht denn es gibt an jeder Schranke andere Briefträger die seine Daten übernehmen. Guckst du hier:
https://www.youtube.com/watch?v=fpqhjEtznVk
wie Geil ist das den Bitte
Frank
1
ok, also ich Dummerchen hatte das immer so verstanden am Beispiel meines alten aussortierten Draytec Vigor MultiLanRouter, dass ich da in einer „Routing-Tabelle“ dann festlege, welches Netz (WLan) mit welchen Lokalen Netz oder Internet verbunden wird.
An der stelle bei gescheiten Routen könnte man dann die „Schranken“ so bauen, dass eben nur bestimmtes durch kann/darf.
Dass das mit Active Directory zu tun haben soll dachte ich eigentlich nicht.
Seufz.
An der stelle bei gescheiten Routen könnte man dann die „Schranken“ so bauen, dass eben nur bestimmtes durch kann/darf.
Dass das mit Active Directory zu tun haben soll dachte ich eigentlich nicht.
Seufz.
Zitat von @aqui:
Knackpunkt beim TO ist, wie immer, die lokale Winblows Firewall die generell eingehenden Traffic aus fremden IP Netzen für alle ihre Dienste blockiert. Kollege @cykes hat es ob schon richtig gesagt.
Aber leider nicht nur...
Der TO hat, vermutlich aus Protokoll Unkenntniss, zusätzlich zur Winblows FW Thematik auch einen fatalen Fehler im Firewall Regelwerk gemacht, denn SMB/CIFS nutzt bekanntlich TCP 445 und kein UDP.
https://de.wikipedia.org/wiki/Server_Message_Block
Als Winblows Administrator sollte man solche Banalitäten eigentlich kennen.
Knackpunkt beim TO ist, wie immer, die lokale Winblows Firewall die generell eingehenden Traffic aus fremden IP Netzen für alle ihre Dienste blockiert. Kollege @cykes hat es ob schon richtig gesagt.
Aber leider nicht nur...
Der TO hat, vermutlich aus Protokoll Unkenntniss, zusätzlich zur Winblows FW Thematik auch einen fatalen Fehler im Firewall Regelwerk gemacht, denn SMB/CIFS nutzt bekanntlich TCP 445 und kein UDP.
https://de.wikipedia.org/wiki/Server_Message_Block
Als Winblows Administrator sollte man solche Banalitäten eigentlich kennen.
Das SMB TCP nutzt weiß ich, die Regel bei pfSense ist auf TCP/UDP gestellt also sollte das kein problem sein.
Freigegeben ein sowie ausgehend auf die entsprechenden Netze ist jetzt:
SMB
ICMPv4
NB Session
NB Name
Alles auf Client sowie Server Firewall.
Share weiterhin nicht auffindbar.
Normale SMB Freigaben die per GPO gemounted werden funktionieren ohne probleme.
In den Logs der pfSense sehe ich nichts was von dem Rechner richtung Fileserver blockiert wird.
Die Windows Firewall logs, die man über den reiter Überwachung im Firewall Center aufrufen kann, sind bei mir leer.
@kreuzberger
Gut, wir kennen auch dein Regelwerk leider nicht. Möglich auch das du an einer Reihenfolge im Regelwerk scheiterst (First match wins) o.ä. Ohne das Regelwerk zu kennen kann man da natürlich nur im freien Fall kristallkugeln.
Aktiviere doch testweise temporär einfach eine Any zu Any Regel um so wasserdicht rauszubekommen obs an deinem Firewall Regelwerk, an der lokalen Winblows Firewall oder beidem liegt. Oder vielleicht an ganz etwas anderem?! 🤔
Das ist ja in 5 Minuten erledigt und du weisst danach dann ganz genau WER der böse Buhmann ist.
Den Firewalls selber sind GPOs bekanntlich ziemlich egal und ob die Shares mounten oder man das manuell macht.
An der stelle bei gescheiten Routen könnte man dann die „Schranken“ so bauen, dass eben nur bestimmtes durch kann/darf.
IP Routing hat mit Firewall Regeln oder ACLs überhaupt gar nichts zu tun. 2 völlig unterschiedliche und völlig getrennte Baustellen. Das wird leider immer und immer wieder verwechselt und ist auch bei Draytek nicht anders. Die Regel bei pfSense ist auf TCP/UDP gestellt also sollte das kein problem sein.
Ist aber Blödsinn, denn UDP 445 gibt es nicht und unnötig Ports öffnen konterkariert ja eine Firewall, aber egal.Gut, wir kennen auch dein Regelwerk leider nicht. Möglich auch das du an einer Reihenfolge im Regelwerk scheiterst (First match wins) o.ä. Ohne das Regelwerk zu kennen kann man da natürlich nur im freien Fall kristallkugeln.
Aktiviere doch testweise temporär einfach eine Any zu Any Regel um so wasserdicht rauszubekommen obs an deinem Firewall Regelwerk, an der lokalen Winblows Firewall oder beidem liegt. Oder vielleicht an ganz etwas anderem?! 🤔
Das ist ja in 5 Minuten erledigt und du weisst danach dann ganz genau WER der böse Buhmann ist.
Den Firewalls selber sind GPOs bekanntlich ziemlich egal und ob die Shares mounten oder man das manuell macht.
Okay, Any Any löst das problem nicht.
Ich habs mal testweise das Share über die IP aufgerufen und das hat funktioniert, hat es wahrscheinlich auch davor aber hab ich total verschlafen zu Testen.
Aktuell gibts neben Internet und co. nur eine Regel die die verbindung zum DC zulässt, in dem Alias sind alle Ports für AD+SMB drin.
Ein zweiter PC der im selben Netz wie der Domäne-PC ist, der aber nicht In der Domäne ist findet das Share weder per IP noch per Name. Das wird aber an den Lokalen Firewall regeln liegen.
Jetzt bin ich irgendwie verwirrt, findet der zugang zum Share per AD statt? (Außer dem Login zum Share) Also fließen Daten die man da reinzieht über den AD?
Der Fileserver ist eine seperate VM (im selben Netz wie der DC) und es gibt keine Firewall Regel bei pfSense die da irgendwelchen zugriff vom Client Netz zulässt.
Ich habs mal testweise das Share über die IP aufgerufen und das hat funktioniert, hat es wahrscheinlich auch davor aber hab ich total verschlafen zu Testen.
Aktuell gibts neben Internet und co. nur eine Regel die die verbindung zum DC zulässt, in dem Alias sind alle Ports für AD+SMB drin.
Ein zweiter PC der im selben Netz wie der Domäne-PC ist, der aber nicht In der Domäne ist findet das Share weder per IP noch per Name. Das wird aber an den Lokalen Firewall regeln liegen.
Jetzt bin ich irgendwie verwirrt, findet der zugang zum Share per AD statt? (Außer dem Login zum Share) Also fließen Daten die man da reinzieht über den AD?
Der Fileserver ist eine seperate VM (im selben Netz wie der DC) und es gibt keine Firewall Regel bei pfSense die da irgendwelchen zugriff vom Client Netz zulässt.
Moin...
dann hast du ein DNS Problem!
wo zeigt der DNS in dem subnetz hin?
kannst du irgendwas aus dem AD Auflösen?
hast du die Netze im AD eingetragen?
Frank
dann hast du ein DNS Problem!
wo zeigt der DNS in dem subnetz hin?
kannst du irgendwas aus dem AD Auflösen?
hast du die Netze im AD eingetragen?
Frank
Zitat von @Vision2015:
Moin...
dann hast du ein DNS Problem!
wo zeigt der DNS in dem subnetz hin?
kannst du irgendwas aus dem AD Auflösen?
hast du die Netze im AD eingetragen?
Frank
Moin...
dann hast du ein DNS Problem!
wo zeigt der DNS in dem subnetz hin?
kannst du irgendwas aus dem AD Auflösen?
hast du die Netze im AD eingetragen?
Frank
Hey, was meinst du mit "Netze im AD eingetragen"?
Der DNS zeigt bei mir immer auf den DC.
Bei nslookup von Clients usw. kommen die richtigen IPs, also ja ich kann auflösen.
Der Hostname vom Fileserver ist recht lang, kann es sein das es daran liegt?
Der Hostname darf max. 15 Zeichen enthalten. Das sollte aber nicht dein Problem sein, auch wenn es überschritten wäre. Mehr als 15 Zeichen lassen sich nicht als Hostname im Windows vergeben.
Zitat von @Bencaso:
Hey, was meinst du mit "Netze im AD eingetragen"?
hast du meinen Linke weiter oben nicht gelesen?Zitat von @Vision2015:
Moin...
dann hast du ein DNS Problem!
wo zeigt der DNS in dem subnetz hin?
kannst du irgendwas aus dem AD Auflösen?
hast du die Netze im AD eingetragen?
Frank
Moin...
dann hast du ein DNS Problem!
wo zeigt der DNS in dem subnetz hin?
kannst du irgendwas aus dem AD Auflösen?
hast du die Netze im AD eingetragen?
Frank
Hey, was meinst du mit "Netze im AD eingetragen"?
Der DNS zeigt bei mir immer auf den DC.
Bei nslookup von Clients usw. kommen die richtigen IPs, also ja ich kann auflösen.
Der Hostname vom Fileserver ist recht lang, kann es sein das es daran liegt?
Bei nslookup von Clients usw. kommen die richtigen IPs, also ja ich kann auflösen.
Der Hostname vom Fileserver ist recht lang, kann es sein das es daran liegt?
was ist recht lang für dich, und warum ist der so Lang?
Frank
1
Das Video sollte verpflichtend bei der Anmeldung gezeigt werden, das würde einen Haufen Fragen ersparen
1
