Windows 2008 R2 Firewall-IPSec - Der Zugriff per NAT auf den Server umgeht Firewall?
Guten Abend zusammen,
Habe einen 2008 R2 Server mit folgender Konfig:
2 Netzwerkkarten
1te Externes Netz, IP: 192.168.178.200
2te Internes Netz, IP:192.168.0.1
Per Ras-Routing macht der Server NAT vom zweiten zum ersten netz.
Geht auch alles soweit ohne Probleme.
Jetzt habe ich aber mir die Sicherheit vom Server einmal angeschaut.
Habe zum test einfach einen FTP Server installiert.
Ohne Firewall Konfig ist der aus dem 178.x per 192.168.178.200 nicht zu erreichen.
Und auch aus dem 0.x ist er per 192.168.0.1 nicht zu erreichen.
Firewall eingehende Regel für port 21 erlauben und es geht.
Alles ist mir soweit klar.
Nun Kommt das NAT ins spiel.
OHNE das der Port in der Firewall freigeschaltet ist, ist der FTP Server vom 192.168.0.x per 192.168.178.200 erreichbar!
Hier das Bild dazu:
Und ich kriege es nicht hin das der Server NAT nach aussen erlaubt, aber nicht zu sich selber routet, und dadurch die Firewall umgeht.
Nach dem bild wäre die richtige IPsec Regel alles von 192.168.178.200 nach 192.168.178.200 zu blocken, (geht nicht Ipsec meckert, Ziel und Quell IP darf nicht gleich sein...)
oder in Firewall alles von ALG.exe nach 178.200 blocken, aber NAT umgeht die Regel.
Kann mir einer helfen ?
EDIT/Nachtrag:
Habe den ALG Dienst(Windows Gatewaydienst auf Anwedungsebene) beendet, bleibt alles beim alten, in der Portüberwachung sieht es dann so aus:
Habe einen 2008 R2 Server mit folgender Konfig:
2 Netzwerkkarten
1te Externes Netz, IP: 192.168.178.200
2te Internes Netz, IP:192.168.0.1
Per Ras-Routing macht der Server NAT vom zweiten zum ersten netz.
Geht auch alles soweit ohne Probleme.
Jetzt habe ich aber mir die Sicherheit vom Server einmal angeschaut.
Habe zum test einfach einen FTP Server installiert.
Ohne Firewall Konfig ist der aus dem 178.x per 192.168.178.200 nicht zu erreichen.
Und auch aus dem 0.x ist er per 192.168.0.1 nicht zu erreichen.
Firewall eingehende Regel für port 21 erlauben und es geht.
Alles ist mir soweit klar.
Nun Kommt das NAT ins spiel.
OHNE das der Port in der Firewall freigeschaltet ist, ist der FTP Server vom 192.168.0.x per 192.168.178.200 erreichbar!
Hier das Bild dazu:
Und ich kriege es nicht hin das der Server NAT nach aussen erlaubt, aber nicht zu sich selber routet, und dadurch die Firewall umgeht.
Nach dem bild wäre die richtige IPsec Regel alles von 192.168.178.200 nach 192.168.178.200 zu blocken, (geht nicht Ipsec meckert, Ziel und Quell IP darf nicht gleich sein...)
oder in Firewall alles von ALG.exe nach 178.200 blocken, aber NAT umgeht die Regel.
Kann mir einer helfen ?
EDIT/Nachtrag:
Habe den ALG Dienst(Windows Gatewaydienst auf Anwedungsebene) beendet, bleibt alles beim alten, in der Portüberwachung sieht es dann so aus:
Kommentieren
Teilen
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: 266081
Url: https://administrator.de/forum/windows-2008-r2-firewall-ipsec-der-zugriff-per-nat-auf-den-server-umgeht-firewall-266081.html
Ausgedruckt am: 01.05.2025 um 22:05 Uhr
6 Kommentare
Neuester Kommentar
Hallo CrimsonED,
das liegt an der Art und weise wie Windows mit geforwardeten Paketen umgeht. Um zu verhindern das dies möglich ist musst du mit den statischen Paketfiltern im RRAS unter Allgemein arbeiten. Also dort das externe Interface wählen und dann unter Allgemein > Eingehende Filter eine Regel definieren die als Ziel die externe Adresse des Servers hat.
Siehe dazu auch folgenden Artikel:
http://blogs.technet.com/b/rrasblog/archive/2007/03/30/rras-server-in-l ...
Grüße Uwe
das liegt an der Art und weise wie Windows mit geforwardeten Paketen umgeht. Um zu verhindern das dies möglich ist musst du mit den statischen Paketfiltern im RRAS unter Allgemein arbeiten. Also dort das externe Interface wählen und dann unter Allgemein > Eingehende Filter eine Regel definieren die als Ziel die externe Adresse des Servers hat.
Siehe dazu auch folgenden Artikel:
http://blogs.technet.com/b/rrasblog/archive/2007/03/30/rras-server-in-l ...
Grüße Uwe
Hallo Uwe,
Danke für deine Antwort,
Das gleiche hab ich gestern Nacht um 3 Uhr oder so, auch herausbekommen ;). Jedoch durch herumspielen, Interessanterweise findet man dazu fast nix im Internet.
Habe deine Antwort getestet Uwe, so komme ich aber auf den Server!
Hier meine Lösung:
Bei der Internen Karte eine Eingehende Regel das alles was zur IP vom Externen Netz soll garnicht erst behandelt wird, sondern verworfen.
http://image-upload.de/image/RcjXfh/f7f69344f9.jpg
EDIT:
Ich finde das von MS da auf jedenfall Warnhinweise hingehören wenn man den Routing/Ras aktiviert.
Schöne Grüße
Karsten
Danke für deine Antwort,
Das gleiche hab ich gestern Nacht um 3 Uhr oder so, auch herausbekommen ;). Jedoch durch herumspielen, Interessanterweise findet man dazu fast nix im Internet.
Habe deine Antwort getestet Uwe, so komme ich aber auf den Server!
Hier meine Lösung:
Bei der Internen Karte eine Eingehende Regel das alles was zur IP vom Externen Netz soll garnicht erst behandelt wird, sondern verworfen.
http://image-upload.de/image/RcjXfh/f7f69344f9.jpg
EDIT:
Ich finde das von MS da auf jedenfall Warnhinweise hingehören wenn man den Routing/Ras aktiviert.
Schöne Grüße
Karsten
Bei der Internen Karte eine Eingehende Regel das alles was zur IP vom Externen Netz soll garnicht erst behandelt wird, sondern verworfen.
so meinte ich das ja 
Aber das .254 am Ende der Subnetzmaske auf deinem Bild war sicherlich ein Tippfehler das akzeptiert der Dialog nicht
Grüße Uwe
doch ;)
.254 steht ja nur für den Server
.254 steht ja nur für den Server
Also hier akzeptiert der Dialog eine Maske von .254 nicht. Aber eine Maske von 255 am Ende führt ja ebenfalls zum gewünschten Effekt.
also 254, nimmt er bei mir, aber du hast auch recht, 255 ist nur der Host. 254 wäre ja host +1 XD
kp wie ich auf 254 gekommen bin
kp wie ich auf 254 gekommen bin
