Doubleslash

Scheint hier ja nicht viele zu geben, die auf ein solches Problem gestossen sind. Wahrscheinlich benutzt niemand ein Windows als Router sondern solche mit einem Router-Betriebssystem :D Die Loesung war die default route mit dem Public NIC als Gateway manuell unter 'Static Routes' einzutragen UND die Metrik niedriger zu setzen als den Standardwert. Der wird mit 256 angeben, jedoch steht in der Routing-Tabelle anschliessend 266. Weiss der Geier warum. Die Metrik ist die selbe, die Windows fuer die Default-Route benutzt und es funktioniert nicht. Gibt man aber einen geringeren Wert, bspw. 255, als Metrik an so zeigt die Routing-Tabelle spaeter 265, ansonsten sind sie exakt gleich. So funktioniert es nun dauerhaft und zuverlaessig. Btw: das zeitkritische Verhalten kam dadurch zu Stande, dass das Routing ins oeffentliche Netz immer dann funktioniert, wenn vorher aus dem internen Netz ein NAT-Mapping angestossen wird. Es ist also restricted-cone NAT, wobei egal ist ob man mit einem Client hinter dem NAT-Router oder mit dem NAT-Router selbst kommunizieren will. Ich nehme an, dass eine manuell eingetragene Route mit niedrigerer Metrik dieses Verhalten ueberschreibt.

Nachtrag 2: Mittlerweile habe ich basierend auf dem Technet-Artikel zusaetzlich eine statische default Route 0.0.0.0/0.0.0.0 mit dem oeffentlich NIC ls Gateway eingetragen. Trotzdem das selbe Verhalten: fuer einige Zeit nach dem dem Einrichten funktioniert es: NAT-Translation, Routing und Port-Forwarding... alles wunderbar. Am naechsten Morgen kann ich den Public NIC nicht mehr anpingen und komme somit nicht mehr auf den Server.

Nachtrag: Was ich mir in der Zwischenzeit so ueberlegt hab: kann es sein, dass NAT bei 2k8R2 nur von innen heraus angestossen werden kann? Also Restricted-cone NAT? Kann es dadurch sein, dass eine Route vom NAT-Gateway hinaus zum oeffentlich Netz ueber den NAT-Adapter nur temporaer erzeugt wird, solange ein Mapping zwischen internen und oeffentlich Netz besteht? Das wuerde zumindest das zeitkritische Verhalten erklaeren... In dem Fall wuerde der Ping aus dem oeffentlichen Netz auf den oeffentlichen NIC zwar ankommen, aber aufgrund der fehlende Route nicht zurueck ins oeffentliche Netz beantwortet werden koennen. Kann man irgendwo die ankommenden ICMP Echo requests sehen?

Hallo Community, ich moechte einen 2K8R2 Server (Enterprise Edition) als NAT-Router verwenden. Darueberhinaus ist der Server fuer das Hosting von TS-Sessions zustaendig. Der Server ist kein VPN Gateway! Ich habe RRAS manuell eingerichtet, sprich NAT nachtraeglich als Protokoll hinzugefuegt und nicht im RRAS Wizard. Macht aber keinen Unterschied. Setup ist klassisch: 2 NICs fuer private Subnetze (192.168.x.x) und ein 1 NIC fuer das oeffentliche Netz. Clients in den privaten Subnetzen sollen ueber den Server per NAT ins oeffentlich Netz kommen und ueber das Routing auch untereinander kommunizieren. Routing funktioniert, NAT ebenfalls, wenn es durch die internen Subnetze getriggered wird. Was nicht funktioniert ist vom oeffentlichen Netz auf den Server selbst zu kommen. Und zwar sobald ich NAT als Rolle hinzufuege. Auf den NICs sind keine Inbound/Outbound-Filter aktiviert und VPN wurde gar nicht erst eingerichtet. Es gibt den bekannten Fall, dass wenn man ein VPN zwischen 2 Servern einrichtet, man seit 2K8 manuell eine Route zur Gegenseite eintragen muss, siehe hier. Da ich aber kein VPN aktiviert habe, trifft das hier nicht zu. Das kuriose dabei ist, dass das Problem manchmal auch erst nach einiger Zeit auftritt. Sprich: NAT/Routing funktioniert und ich kann mich auf den Server per RDP aufschalten. Ich kann sogar Port-Forwarding zu den Clients in den privaten Subnetzen machen. Stunden spaeter geht nicht mal mehr ein Ping.