25
Windows Firewall - Kerberosauth. über Gateways hinweg möglich?
Moin Kollegen!
Nutzt jemand hier Firewallregeln mit Authentifizierung?
Ich nutze das und frage mich, ob die darin eingebaute optionale Kerberosauthentifizierung auch über Gateways/Firewalls hinweg funktioniert.
Also:
PC_Netz1->Linuxrechner mit mehreren Netzwerkkarten und Firewall als Gateway->PC_Netz2
Ich stelle fest, dass hier die Verbindungen fehlschlagen, sobald ich die Firewallregeln mit Kerberosauthentifizierung kombiniere, während sie bei Endpunkten im selben Subnetz funktionieren.
Frage: kann das überhaupt funktionieren oder ist das bei dieser Konstellation schlicht nicht möglich?
Ich sehe, dass es auch Regeln vom Typ "Tunnel" gibt, wo von Gateways die Rede ist, aber wollte da nicht mit Try-and-Error einsteigen.
Nutzt jemand hier Firewallregeln mit Authentifizierung?
Ich nutze das und frage mich, ob die darin eingebaute optionale Kerberosauthentifizierung auch über Gateways/Firewalls hinweg funktioniert.
Also:
PC_Netz1->Linuxrechner mit mehreren Netzwerkkarten und Firewall als Gateway->PC_Netz2
Ich stelle fest, dass hier die Verbindungen fehlschlagen, sobald ich die Firewallregeln mit Kerberosauthentifizierung kombiniere, während sie bei Endpunkten im selben Subnetz funktionieren.
Frage: kann das überhaupt funktionieren oder ist das bei dieser Konstellation schlicht nicht möglich?
Ich sehe, dass es auch Regeln vom Typ "Tunnel" gibt, wo von Gateways die Rede ist, aber wollte da nicht mit Try-and-Error einsteigen.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1436248689
Url: https://administrator.de/forum/windows-firewall-kerberosauth-ueber-gateways-hinweg-moeglich-1436248689.html
Ausgedruckt am: 06.04.2025 um 09:04 Uhr
25 Kommentare
Neuester Kommentar
Aus Netzwerksicht ist die Frage WIE die beiden Rechner dann kommunizieren um ihr Regelwerk abzustimmen.
In einem gemeinsamen Netzwerk gibt es ja per se keinen dazwischen der Regeln definiert. Die PCs "sehen" sich also direkt und sind rein abhängig von ihrem lokalen Windows Firewall Regelwerk.
Versteht man den zitierten Artikel oben richtig, etablieren sie einen IPsec Tunnel um ihre, rein Windows Firewall bezogenen Regeln zu definieren bzw. zu etablieren.
Wenn nun, wie oben, eine externe Firewall dazwischen ins Spiel kommt, stellt sich die Frage WAS diese dann als Regeln zur Kommunikation der beiden PCs untereinander aktiv hat ?
Ist es IPsec muss sie zwischen den beiden Netzen der PCs dann zumindestens UDP 500, UDP 4500 und das ESP Protokoll erlauben damit die PC wenigstens ihren Tunnel etablieren können um ihrerseits ihr lokales Windows Regelwerk überhaupt abstimmen zu können.
Es ist zugegeben etwas schwer zu verstehen von der Logik her, weil hier einmal rein nur Windows interne Firewall Settings relevant sind, deren Kommunikation dazu netzübergreifend aber von externen Regelwerken bestimmt sind.
Möglich auch das das jetzt gänzlich falsch verstanden ist...
In einem gemeinsamen Netzwerk gibt es ja per se keinen dazwischen der Regeln definiert. Die PCs "sehen" sich also direkt und sind rein abhängig von ihrem lokalen Windows Firewall Regelwerk.
Versteht man den zitierten Artikel oben richtig, etablieren sie einen IPsec Tunnel um ihre, rein Windows Firewall bezogenen Regeln zu definieren bzw. zu etablieren.
Wenn nun, wie oben, eine externe Firewall dazwischen ins Spiel kommt, stellt sich die Frage WAS diese dann als Regeln zur Kommunikation der beiden PCs untereinander aktiv hat ?
Ist es IPsec muss sie zwischen den beiden Netzen der PCs dann zumindestens UDP 500, UDP 4500 und das ESP Protokoll erlauben damit die PC wenigstens ihren Tunnel etablieren können um ihrerseits ihr lokales Windows Regelwerk überhaupt abstimmen zu können.
Es ist zugegeben etwas schwer zu verstehen von der Logik her, weil hier einmal rein nur Windows interne Firewall Settings relevant sind, deren Kommunikation dazu netzübergreifend aber von externen Regelwerken bestimmt sind.
Möglich auch das das jetzt gänzlich falsch verstanden ist...
Hi @aqui und danke für die Anregungen.
Ja, bei dem was derzeit an Ports zwischen den Netzen offen ist (TCP/UDP) werden wir auch ansetzen, vielleicht ist das zu wenig dafür.
Ich hoffe noch, dass ich Personen finde, die das einsetzen über Gateways hinweg und sagen können, was dafür nötig war, bevor ich selber mit Portöffnungen und "atomarem" Logging beginne.
Ja, bei dem was derzeit an Ports zwischen den Netzen offen ist (TCP/UDP) werden wir auch ansetzen, vielleicht ist das zu wenig dafür.
Ich hoffe noch, dass ich Personen finde, die das einsetzen über Gateways hinweg und sagen können, was dafür nötig war, bevor ich selber mit Portöffnungen und "atomarem" Logging beginne.
Moin,
selbst habe ich die KerbAuth noch nicht über stark reglementierte Firewall-Policies umgesetzt, aber womöglich helfen dir diese Links:
https://docs.microsoft.com/de-de/troubleshoot/windows-server/identity/co ...
https://uit.stanford.edu/service/kerberos/firewalls
Dem zur Folge benötigst eingehend am Server den
Edit: hier noch ein weiterer Link: https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Configur ...
Gruß
em-pie
selbst habe ich die KerbAuth noch nicht über stark reglementierte Firewall-Policies umgesetzt, aber womöglich helfen dir diese Links:
https://docs.microsoft.com/de-de/troubleshoot/windows-server/identity/co ...
https://uit.stanford.edu/service/kerberos/firewalls
Dem zur Folge benötigst eingehend am Server den
TCP/ UDP-Port 88 bzw. TCP/ UDP-Port 464 und Clientseitig TCP/ UDP 49152 - 65535Edit: hier noch ein weiterer Link: https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Configur ...
Gruß
em-pie
die das einsetzen über Gateways hinweg und sagen können, was dafür nötig war, bevor ich selber mit Portöffnungen
Zur Not ist ja der Wireshark immer dein bester Freund ! 
Man muss die Session dann nur mal mitsniffern und weiss es danach genau.Die o.a. Ports bestimmen ja nur die eigentlichen Kerberos Ports. Der Author des oben zitierten Artikels redet aber (wenn man es denn richtig versteht) von IPsec, so das diese Kommunikation komplett in einem verschlüsselten IPsec Tunnel liegt, also von einer externen Firewall gar nicht sichtbar ist.
Diese würde dann nur den IPsec Tunnel zu Gesicht bekommen. Trifft das zu, dreht es sich dann nur um die o.a. IPsec Ports und Protokolle.
Hallo,
ich habe so die RDP Verbindungen für die DCs abgesichert. Das funktioniert über Standorte hinweg mit mehreren Routern und OpenVPN ist dazwischen.
wichtig ist, dass die Endpunkte in den Verbingssicherheitsregeln passen.
Grüße
lcer
PS: OpenVPN läuft im tun-Modus. Das dürfte IPSec mit echtem ESP eigentlich nicht übertragen. Testweise hatte ich zwar IPSec eingehend erlaubt (das Windows-Firewall-IPSec UDP 500 auf den beiden beteiligten Rechnen) , glaube aber eigentlich nicht, ob das nötig war.
In der Verbindungssicherheitsregel habe ich folgendes eingestellt:
- IPsec Tunneling wird nicht verwendet (es erfolgt dadurch lediglich die Authentifizierung)
- Authentifizierungsmodus eingehend und ausgehend anfordern; Computer und Benutzer
- Protokolle und Ports: TCP 3389 (RDP)
- Endpunkt 1: beliebig
- Endpunkt 2: beliebig
Die Endpunkte einzugrenzen, würde aus Performance-Gründen wohl Sinn machen. (Es wird dann nicht versucht, jeden zu Authentifizieren), da es aber bei mir um wenige administrative RDP-Verbindungen geht, habe ich das nicht getan (Hatte ich am Anfang, aber nach der Migration auf 2016er DCs hatte ich ständig irgendeine IP vergessen .... ).
ich habe so die RDP Verbindungen für die DCs abgesichert. Das funktioniert über Standorte hinweg mit mehreren Routern und OpenVPN ist dazwischen.
wichtig ist, dass die Endpunkte in den Verbingssicherheitsregeln passen.
Grüße
lcer
PS: OpenVPN läuft im tun-Modus. Das dürfte IPSec mit echtem ESP eigentlich nicht übertragen. Testweise hatte ich zwar IPSec eingehend erlaubt (das Windows-Firewall-IPSec UDP 500 auf den beiden beteiligten Rechnen) , glaube aber eigentlich nicht, ob das nötig war.
In der Verbindungssicherheitsregel habe ich folgendes eingestellt:
- IPsec Tunneling wird nicht verwendet (es erfolgt dadurch lediglich die Authentifizierung)
- Authentifizierungsmodus eingehend und ausgehend anfordern; Computer und Benutzer
- Protokolle und Ports: TCP 3389 (RDP)
- Endpunkt 1: beliebig
- Endpunkt 2: beliebig
Die Endpunkte einzugrenzen, würde aus Performance-Gründen wohl Sinn machen. (Es wird dann nicht versucht, jeden zu Authentifizieren), da es aber bei mir um wenige administrative RDP-Verbindungen geht, habe ich das nicht getan (Hatte ich am Anfang, aber nach der Migration auf 2016er DCs hatte ich ständig irgendeine IP vergessen .... ).
Also hier läuft weiterhin nichts zwischen zwei Subnetzen. Protokolle und Ports sind alle erlaubt zum Test.
@icer00 Bekommen die Kommunikationspartner nicht Adressen aus dem selben Netzwerk? Arbeitet der Tun-Modus nicht so?
Werde unseren Linux-Firewall-Admin nächste Woche erst dazu befragen können. Vorher steige ich auch mit Sniffing nicht ein, denn es ist nicht dringend.
@icer00 Bekommen die Kommunikationspartner nicht Adressen aus dem selben Netzwerk? Arbeitet der Tun-Modus nicht so?
Werde unseren Linux-Firewall-Admin nächste Woche erst dazu befragen können. Vorher steige ich auch mit Sniffing nicht ein, denn es ist nicht dringend.
Protokolle und Ports sind alle erlaubt zum Test.
Wirklich ?! Bedenke das ESP kein IP Protokoll oder Port ist sondern ein eigenständiges Protokoll mit der Nummer 50. Es muss in FWs immer explizit erlaubt werden als separates Protokoll. Das sollte der FW Admin auf dem Radar haben.
Ja, das hat er bestimmt. Vermutlich übersehe ich genau das in der Konfig... mache es ja nur vertretungshalber [und gaanz vorsichtig] 
Ich werde berichten.
Ich werde berichten.
Hallo nochmal,
die Endpunkte sind in unterschiedlichen Subnetzen. Und ESP geht nicht durch den Tunnel durch.
Grüße
lcer
die Endpunkte sind in unterschiedlichen Subnetzen.
Grüße
lcer
Hallo nochmal,
habe das Problem jetzt mal an der firewall (OPNSense) mit Hilfe der Protokolle nachgeschaut:
Ich war vorher davon ausgegangen, dass ESP nicht über das OpenVPN durchgeht wenn es im TUN Modus läuft. Das ist aber falsch, hab da etwas durcheinandergebracht ... sorry. ESP ist natürlich ein Layer3 Protokoll wie IP oder ICMP, und Layer3 geht durch das OpenVPN TUN durch.
Grüße
lcer
habe das Problem jetzt mal an der firewall (OPNSense) mit Hilfe der Protokolle nachgeschaut:
- zuerst wird ein IPSec UDP Port 500 vom Client an den Server gesendet
- dann ein ESP Paket vom Client an den Server
Ich war vorher davon ausgegangen, dass ESP nicht über das OpenVPN durchgeht wenn es im TUN Modus läuft. Das ist aber falsch, hab da etwas durcheinandergebracht ... sorry. ESP ist natürlich ein Layer3 Protokoll wie IP oder ICMP, und Layer3 geht durch das OpenVPN TUN durch.
Grüße
lcer
1
Danke.
Ich gehe davon aus, dass es laufen wird, wenn wir nächste Woche ESP durchlassen.
Ich gehe davon aus, dass es laufen wird, wenn wir nächste Woche ESP durchlassen.
mit Hilfe der Protokolle nachgeschaut:
Ist dann klassisches IPsec mit IKE (UDP 500) und ESPdass ESP nicht über das OpenVPN durchgeht wenn es im TUN Modus läuft.
Wäre auch doppelt gemoppelt denn das wäre dann ja Tunnel im Tunnel. Ist auch die Frage ob OpenVPN ein nicht IP Protokoll wie ESP in den Tunnel sendet. Das müsste man mal mitsniffern. Vermutlich aber wohl schon wenn es bei dir über einen OVPN Tunnel fehlerfrei rennt.Auf alle Fälle wird es mit doppeltem Tunneling dann immer kritisch was MTU und MSS anbetrifft.
und Layer3 geht durch das OpenVPN TUN durch.
Novell IPX/SPX, AppleTalk und Banyan Vines sind auch Layer 3 Protokolle die aber definitiv nicht durch einen OpenVPN Tunnel gehen...Sorry, der musste sein an einem Freitag... 🤣
Zitat von @aqui:
Novell IPX/SPX, AppleTalk und Banyan Vines sind auch Layer 3 Protokolle die aber definitiv nicht durch einen OpenVPN Tunnel gehen...
Novell IPX/SPX, AppleTalk und Banyan Vines sind auch Layer 3 Protokolle die aber definitiv nicht durch einen OpenVPN Tunnel gehen...
Vines habe ich aber schon lange nicht mehr gesehen.
AppleTalk und IPX/SPX stolpert man schon eher mal darüber.
lks
hier noch ein netter Link: https://medium.com/@cryps1s/endpoint-isolation-with-the-windows-firewall ...
Grüße
lcer
You will need to ensure that UDP Port 500 (IKE) and ESP are not filtered by any network firewalls. Using IPSEC to protect protocols will initiate the tunnel via IPSEC (UDP 500) and then tunnel traffic over ESP, which could be filtered by firewalls inside your network. Use wireshark and validate all the connections look sane and reasonable.Grüße
lcer
Das macht die Sache dann klar ! 👍
So, nun läuft es.
Wie vermutet: ESP zulassen, UDP 500 zulassen. UDP 4500 war nicht nötig.
Ich danke Euch sehr für die Hilfe!
Wie vermutet: ESP zulassen, UDP 500 zulassen. UDP 4500 war nicht nötig.
Ich danke Euch sehr für die Hilfe!
👍 OK, dann arbeitet Windows hier ohne NAT Traversal.
Hallo,
Muss eigentlich UDP 500 an den Endpunkten (den Windows-Maschinen) explizit freigegeben werden? Oder ist das „offen“ wenn die Verbindungssicherheitsregen angewendet werden? Ich habe es auf den Geräten per eingehende Regel erlaubt, bin mir aber nicht sicher, ob das erforderlich ist (gleiches gilt für ESP - das habe ich nicht explizit freigegeben).
Ich werde das jedenfalls nochmal testen.
Grüße
lcer
Muss eigentlich UDP 500 an den Endpunkten (den Windows-Maschinen) explizit freigegeben werden? Oder ist das „offen“ wenn die Verbindungssicherheitsregen angewendet werden? Ich habe es auf den Geräten per eingehende Regel erlaubt, bin mir aber nicht sicher, ob das erforderlich ist (gleiches gilt für ESP - das habe ich nicht explizit freigegeben).
Ich werde das jedenfalls nochmal testen.
Grüße
lcer
Musste nicht extra freigegeben werden.
Hallo,
falls das hier mal zu einem Tutorial umgearbeitet wird ... - noch ein paar Hinweise:
Wenn man das ganze mittels GPO umsetzt, ist es empfehlenswert, zuerst die Verbindungssicherheitsregeln an alle Beteiligten (Client-PC und Server-PC) auszurollen und dies zu überprüfen - bevor man serverseitig eine Firewallregel auf "Verbindung zulassen, wenn sie sicher ist" umstellt. Fehlt die Verbindungssicherheitsregel am Client, Kommt die Verbindung nicht zustande. In diesem Zusammenhang muss man dann natürlich auch darauf achten, dass Client und Server immer kompatible Authentifizierungs- und Verschlüsselungsregeln in der Verbindungssicherheitsregel konfiguriert haben.
In der Firewallregel kann man Remotebenutzer und Remotecomputer angeben. Remotecomputer ist der PC, von dem aus die Verbindung initiert wird (logisch). Remotebenutzer ist der Benutzer, unter dessen Benutzeraccount das Programm ausgeführt wird, das die Verbindung initiiert (auch logisch) - nicht die bei der Verbindung verwendeten Benutzercredentials! Dazu als Beispiel RDP:
Benutzer-A will sich per RDP von PC-1 auf den Server unter Verwendung des Benutzers Serveradministrator-A verbinden. Dazu startet er die RDP-Verbindung mit dem Parameter /admin. Damit das funktioniert muss folgendes in der Firewallregel des Servers eingestellt sein:
Grüße
lcer
falls das hier mal zu einem Tutorial umgearbeitet wird ... - noch ein paar Hinweise:
Wenn man das ganze mittels GPO umsetzt, ist es empfehlenswert, zuerst die Verbindungssicherheitsregeln an alle Beteiligten (Client-PC und Server-PC) auszurollen und dies zu überprüfen - bevor man serverseitig eine Firewallregel auf "Verbindung zulassen, wenn sie sicher ist" umstellt. Fehlt die Verbindungssicherheitsregel am Client, Kommt die Verbindung nicht zustande. In diesem Zusammenhang muss man dann natürlich auch darauf achten, dass Client und Server immer kompatible Authentifizierungs- und Verschlüsselungsregeln in der Verbindungssicherheitsregel konfiguriert haben.
In der Firewallregel kann man Remotebenutzer und Remotecomputer angeben. Remotecomputer ist der PC, von dem aus die Verbindung initiert wird (logisch). Remotebenutzer ist der Benutzer, unter dessen Benutzeraccount das Programm ausgeführt wird, das die Verbindung initiiert (auch logisch) - nicht die bei der Verbindung verwendeten Benutzercredentials! Dazu als Beispiel RDP:
Benutzer-A will sich per RDP von PC-1 auf den Server unter Verwendung des Benutzers Serveradministrator-A verbinden. Dazu startet er die RDP-Verbindung mit dem Parameter /admin. Damit das funktioniert muss folgendes in der Firewallregel des Servers eingestellt sein:
- Remotecomputer: PC-1
- Remotebenutzer: Benutzer-A - und nicht Serveradministrator-A
Grüße
lcer
1
Sollte ein Admin zwar von sich aus wissen, aber wer damit rumspielen möchte, sollte auch mit bedenken das Zielport und Quellport in der Regel nicht identisch sind. Heißt man stellt für solche Verbindungen den Port nur auf einer Seite fest ein, auf der anderen beliebig. Ob bei Endpunkt 1 oder 2 ist aber scheinbar egal.
Gilt aber nur für das IKE Protokoll UDP 500. ESP kennt bekanntlich keine Ports.
Hallo,
Nee aqui, er meinte die Konfiguration für die „Nutzlast“ z.B. SMB oder RDP. Source-Port und Dest.Port
Grüße
lcer
Nee aqui, er meinte die Konfiguration für die „Nutzlast“ z.B. SMB oder RDP. Source-Port und Dest.Port
Grüße
lcer
1
Hallo,
ein kleiner Nachtrag. Auf unseren Windows 10 Clients verwenden wir eine Drittanbieter-Firewall (ESET endpoint). Dabei übernimmt ESET die definierten Windows Firewallregeln (und ergänzt das um diverse Features). Das "automatisch Annehmen" von IPSec und ESP scheint dabei von ESET nicht verarbeitet zu werden. Die Sicherheitszuordnungen konnten erst erfolgreich erstellt werden, nachdem ich in der Windows Firewall IPSec und ESP explizit freigegeben haben.
Grüße
lcer
ein kleiner Nachtrag. Auf unseren Windows 10 Clients verwenden wir eine Drittanbieter-Firewall (ESET endpoint). Dabei übernimmt ESET die definierten Windows Firewallregeln (und ergänzt das um diverse Features). Das "automatisch Annehmen" von IPSec und ESP scheint dabei von ESET nicht verarbeitet zu werden. Die Sicherheitszuordnungen konnten erst erfolgreich erstellt werden, nachdem ich in der Windows Firewall IPSec und ESP explizit freigegeben haben.
Grüße
lcer
