5
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
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: 155754
Url: https://administrator.de/forum/nat-und-remoterouter-problem-155754.html
Ausgedruckt am: 28.04.2025 um 13:04 Uhr
5 Kommentare
Neuester Kommentar
Hi,
Bekommst du eine Fehlermeldung zurück wennst mit dem Browser zugreifen willst?
hast du eventuell schon einen Portscan versucht?
Ich gehe davon aus das die Namensauflösung passt.
Mich schaut das so an als ob ein Problem beim Portforwarding von https ist.
Hast du ein DNAT gesetzt ?
LG
Bekommst du eine Fehlermeldung zurück wennst mit dem Browser zugreifen willst?
hast du eventuell schon einen Portscan versucht?
Ich gehe davon aus das die Namensauflösung passt.
Mich schaut das so an als ob ein Problem beim Portforwarding von https ist.
Hast du ein DNAT gesetzt ?
LG
Hallo,
nein einfach einen Timeout. Die BasicFirewall auf der ISDN-Schnittstelle ist übrigends nicht aktiviert.
nicht erforderlich, Zugriff erfolgt über IP-Addressen. Funktioniert aber im übrigen.
Grüße
lcer
Bekommst du eine Fehlermeldung zurück wennst mit dem Browser zugreifen willst?
nein einfach einen Timeout. Die BasicFirewall auf der ISDN-Schnittstelle ist übrigends nicht aktiviert.
Ich gehe davon aus das die Namensauflösung passt.
nicht erforderlich, Zugriff erfolgt über IP-Addressen. Funktioniert aber im übrigen.
Mich schaut das so an als ob ein Problem beim Portforwarding von https ist.
Aber wie stelle ich das denn ein?Hast du ein DNAT gesetzt ?
Ich habe einfach das Häkchen "NAT aktivieren" gesetzt. Ein IP-Adresspool ist nicht eingestellt.Grüße
lcer
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 !
Hm,
Grüße
lcer
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.
Vom 192.168.1.0 Clients komme ich aber gut über den Standartgateway auf HTTPS-Seiten im Internet. Das Routing ist bis auf die Standartroute 192.168.104.0 -> Remoterouter das gleich.... und da ist eine Firewall nicht aktiv - soweit ich das erkennewas in irgendeiner der Firewalls sei es auf dem Server oder dem Endgerät hängenbleibt.
Grüße
lcer
Da hilft dann nur den Wireshark mal rauszuholen und mal zu sehen was genau da ankommt. Am NAT selber kann es eigentlich niemals liegen !
