NAT und Remoterouter-Problem
Hallo liebes Forum,
leider wurde ich über Google&Co nicht fündig:
Folgende Situation:
Ich betreibe ein Netzwerk zwischen 2 Standorten über ein VPN. Nun möchte ich eine zusätzliche ISDN-Einwahlverbindung, die physikalisch in Standort 1 lokalisiert ist auch in Standort 2 nutzen. Leider klappt das nicht. Mein Netzwerk sieht wie folgt aus:
Standort 1:
Windows 2003 R2 PDC (multi-homed)
Adapter 1: 192.168.0.10/24 für internes Netzwerk
Adapter 2: 192.168.12.254/24 für externes Netzwerk inkl. Standartgateway/Router ins Internet.
Standort 2:
Windows 2003 R2 DC (multi-homed)
Adapter 1: 192.168.1.10/24 für internes Netzwerk
Adapter 2: 192.168.9.10/24 für externes Netzwerk inkl. Standartgateway/Router ins Internet.
Die zwei Internetrouter stellen eine LAN-LAN PPTP Verbindung zwischen 192.168.12.0 und 192.168.9.0 her.
Die 2 DCs stellen eine bidirektionale VPN-Verbindung über Remoterouter zwischen 192.168.12.254 und 192.168.9.10 her. Über diesen Remoterouter wird der Zugriff von 192.168.0.0 <-> 192.168.1.0 geroutet. NAT ist für diese Verbindung aus.
An Standort 1 existiert eine ISDN-Karte, die eine Einwählverbinung über Remoterouter in ein fremdes Netz (192.168.104.0) herstellt. NAT ist aktiviert.
Von allen Rechnern an Standort 1 (192.168.0.0) kann ich auf das Netz 192.168.104.0 zugreifen.
Auf DC2 (192.168.1.10) habe ich eine statische Route auf 192.168.104.0 auf den Zwischenstandort-Remoutouter gesetzt.
Vom DC2 an Standort2 kann ich auf das Netzwerk 192.168.104.0 zugreifen (Ping + Https).
Von den anderen Rechnern in 192.168.1.0 kommt Ping und Tracert fehlerfrei an, nicht jedoch der https-Zugriff.
Woran könnte das liegen? Ich vermute ein Problem mit dem NAT.
Grüße
lcer
leider wurde ich über Google&Co nicht fündig:
Folgende Situation:
Ich betreibe ein Netzwerk zwischen 2 Standorten über ein VPN. Nun möchte ich eine zusätzliche ISDN-Einwahlverbindung, die physikalisch in Standort 1 lokalisiert ist auch in Standort 2 nutzen. Leider klappt das nicht. Mein Netzwerk sieht wie folgt aus:
Standort 1:
Windows 2003 R2 PDC (multi-homed)
Adapter 1: 192.168.0.10/24 für internes Netzwerk
Adapter 2: 192.168.12.254/24 für externes Netzwerk inkl. Standartgateway/Router ins Internet.
Standort 2:
Windows 2003 R2 DC (multi-homed)
Adapter 1: 192.168.1.10/24 für internes Netzwerk
Adapter 2: 192.168.9.10/24 für externes Netzwerk inkl. Standartgateway/Router ins Internet.
Die zwei Internetrouter stellen eine LAN-LAN PPTP Verbindung zwischen 192.168.12.0 und 192.168.9.0 her.
Die 2 DCs stellen eine bidirektionale VPN-Verbindung über Remoterouter zwischen 192.168.12.254 und 192.168.9.10 her. Über diesen Remoterouter wird der Zugriff von 192.168.0.0 <-> 192.168.1.0 geroutet. NAT ist für diese Verbindung aus.
An Standort 1 existiert eine ISDN-Karte, die eine Einwählverbinung über Remoterouter in ein fremdes Netz (192.168.104.0) herstellt. NAT ist aktiviert.
Von allen Rechnern an Standort 1 (192.168.0.0) kann ich auf das Netz 192.168.104.0 zugreifen.
Auf DC2 (192.168.1.10) habe ich eine statische Route auf 192.168.104.0 auf den Zwischenstandort-Remoutouter gesetzt.
Vom DC2 an Standort2 kann ich auf das Netzwerk 192.168.104.0 zugreifen (Ping + Https).
Von den anderen Rechnern in 192.168.1.0 kommt Ping und Tracert fehlerfrei an, nicht jedoch der https-Zugriff.
Woran könnte das liegen? Ich vermute ein Problem mit dem NAT.
Grüße
lcer
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 155754
Url: https://administrator.de/forum/nat-und-remoterouter-problem-155754.html
Ausgedruckt am: 07.04.2025 um 21:04 Uhr
5 Kommentare
Neuester Kommentar
Router in diese Netze sind immer die Server. Da du das PPTP VPN nicht auf den Routern selber terminierst sondern auf die Server per Port Forwarding sind die beiden Server die zentralen Router für alle internen Netze.
DC-1 benötigt keinerlei statische Routen, DC-2 hingegen schon, denn der kennt ja das .104.0 /24 er Netz nicht. In sofern ist deine statische Route auch korrekt was der erfolgreiche Ping und Traceroute ja auch zeigen.
Hilfreich wäre mal eine Traceroute oder Pathping Output um zu sehen das auch die Wegewahl korrekt verläuft.
Die zentrale Frage ist jetzt WO genau das NAT aktiviert ist. Ob es direkt am ISDN Dialin Interface gemacht wird, vermutlich ja.
Mit NAT kann das aber niemals was zu tun haben, denn HTTPS nutzt nur einen Port TCP 443 und keinerlei dynamische Ports. Ein HTTPS Paket also was von einem Host im 192.168.1.0er Netz abgesendet wird z.B. 192.168.1.100 wird dann ja am ISDN Interface geNATet, erhält also z.B. die 192.168.104.254 (angenommen das ISDN Interface hat die .104.254) als neue Absender IP Adresse ebenfalls mit dem Port TCP 443.
Endgeräte im 192.168.104er Netz oder in IP Netzen dahinter sehen als Absender IP also immer 192.168.104.254 mit dem Port TCP 443 und antworten dann entsprechend auch auf diese IP und den TCP Quellport.
Was natürlich ganz klar sein sollte ist das sich keine .0.0 /24, 1.0 /24, .9.0 /24 und .12.0 /24er Netze hinter dem .104er netz befinden dürfen ! Tun sie vermutlich auch nicht, denn sonst wäre auch schon Ping oder Traceroute aufs Ziel gescheitert !
Fazit: Es kann sich logisch gesehen nur um ein Firewall Problem handeln ! ICMP rennt ja fehlerfrei durch nur eben TCP 443 nicht was in irgendeiner der Firewalls sei es auf dem Server oder dem Endgerät hängenbleibt.
Sinnvoll wäre hier mal ein Wireshark Trace im .104.0er Netz mit einem HTTPS Paket bei Verbindungsaufbau.
Da sieht man dann sofort anhand der Source und Destination IP wo der Hase im Pfeffer liegt und kann entsprechend reagieren !
DC-1 benötigt keinerlei statische Routen, DC-2 hingegen schon, denn der kennt ja das .104.0 /24 er Netz nicht. In sofern ist deine statische Route auch korrekt was der erfolgreiche Ping und Traceroute ja auch zeigen.
Hilfreich wäre mal eine Traceroute oder Pathping Output um zu sehen das auch die Wegewahl korrekt verläuft.
Die zentrale Frage ist jetzt WO genau das NAT aktiviert ist. Ob es direkt am ISDN Dialin Interface gemacht wird, vermutlich ja.
Mit NAT kann das aber niemals was zu tun haben, denn HTTPS nutzt nur einen Port TCP 443 und keinerlei dynamische Ports. Ein HTTPS Paket also was von einem Host im 192.168.1.0er Netz abgesendet wird z.B. 192.168.1.100 wird dann ja am ISDN Interface geNATet, erhält also z.B. die 192.168.104.254 (angenommen das ISDN Interface hat die .104.254) als neue Absender IP Adresse ebenfalls mit dem Port TCP 443.
Endgeräte im 192.168.104er Netz oder in IP Netzen dahinter sehen als Absender IP also immer 192.168.104.254 mit dem Port TCP 443 und antworten dann entsprechend auch auf diese IP und den TCP Quellport.
Was natürlich ganz klar sein sollte ist das sich keine .0.0 /24, 1.0 /24, .9.0 /24 und .12.0 /24er Netze hinter dem .104er netz befinden dürfen ! Tun sie vermutlich auch nicht, denn sonst wäre auch schon Ping oder Traceroute aufs Ziel gescheitert !
Fazit: Es kann sich logisch gesehen nur um ein Firewall Problem handeln ! ICMP rennt ja fehlerfrei durch nur eben TCP 443 nicht was in irgendeiner der Firewalls sei es auf dem Server oder dem Endgerät hängenbleibt.
Sinnvoll wäre hier mal ein Wireshark Trace im .104.0er Netz mit einem HTTPS Paket bei Verbindungsaufbau.
Da sieht man dann sofort anhand der Source und Destination IP wo der Hase im Pfeffer liegt und kann entsprechend reagieren !