vevie 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Hi Ich habe eine manual IP Sec Verbindung zwischen einer watchguard firebox x700 und einer watchguard x15 edge. Die vpn-Verbindung steht auch, zumindest kann ich die internen Interfaces der Fireboxen pingen. Sobald ich aber irgendein Gerät hinter der Firebox pingen möchte, erhalte ich keine Antwort mehr. ich habe bereits den Watchguard Support kontaktiert, doch die sagen, es handle sich nicht um ein Firebox, sondern um ein Netzwerkproblem. Hinter jeder firebox existiert ein LAN mit Domaincontroller. Die Domainnamen und IP-Netze sind unterschiedlich. Um den Benutzern des Netzwerkes A Zugriff auf das Netzwerk B und dessen Filesystem zu gewähren, wollte ich eigentlich eine Vertrauensstellung zwischen den beiden Domänen einrichten. Das funktioniert aber nicht, da der Domaincontroller nicht erreicht werden kann, man kann ihn ja nicht mal pingen. Hat jemand eine Idee, wo ich ansetzen könnte? kann es an unterschiedlichen Subnetmasks liegen? Danke für Eure Hilfe! Zitieren Link zu diesem Kommentar
weg5st0 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Hi vevie, Wenn die Maske überall richtig eingetragen ist - eher nicht. was sagt ein tracert server zum entfernten Standort? Zitieren Link zu diesem Kommentar
Hr_Rossi 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 hi das ist definitv ein routing problem ! hast du die routen angepasst ?? lg Zitieren Link zu diesem Kommentar
vevie 10 Geschrieben 3. Januar 2006 Autor Melden Teilen Geschrieben 3. Januar 2006 Hallo Götz, ein tracert zur public IP: Routenverfolgung zu 62-167-236-113.adslpremium.ch [62.167.236.113] über maximal 30 Abschnitte: 1 <1 ms <1 ms <1 ms 192.168.0.5 2 6 ms 9 ms 9 ms 208.169.static-adsl.customer.ch.easynet.net [217 .8.208.169] 3 22 ms 24 ms 24 ms dr3.htzrh.ch.easynet.net [217.8.195.25] 4 15 ms 21 ms 21 ms fe3-0.br0.htzrh.ch.easynet.net [217.8.193.65] 5 25 ms 19 ms 23 ms ge1-0.br0.thzrh.ch.easynet.net [217.8.192.8] 6 22 ms 19 ms 22 ms zur14s03.sunrise.ch [194.42.48.29] 7 23 ms 22 ms 25 ms g5-1.zur01b03.sunrise.ch [193.192.234.197] 8 21 ms 25 ms 25 ms 212.161.164.37 9 * * Das tracert zum internen Interface der Firebox: Routenverfolgung zu 192.168.1.5 über maximal 30 Abschnitte 1 <1 ms <1 ms <1 ms 192.168.0.5 2 37 ms 30 ms 41 ms 192.168.1.5 Ablaufverfolgung beendet. Das tracert zu einem Gerät im remote LAN: Routenverfolgung zu 192.168.1.10 über maximal 30 Abschnitte 1 <1 ms <1 ms <1 ms 192.168.0.5 2 40 ms 40 ms 38 ms 192.168.1.5 3 * * * Zeitüberschreitung der Anforderung. 4 * Ich kann damit leider nicht viel anfangen. Zitieren Link zu diesem Kommentar
weg5st0 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Hm, was passiert denn, wenn du auf der 192.168.1.10 einen ping auf 192.168.1.5 machst? kannst du mal von beiden enden (192.168.1.10 und der rechner von dem du pingst) die ipconfig /all posten? Zitieren Link zu diesem Kommentar
vevie 10 Geschrieben 3. Januar 2006 Autor Melden Teilen Geschrieben 3. Januar 2006 Hallo Herr Rossi, mit "Routen angepasst" meinst Du sicherlich die Routing Policies auf den Fireboxen, oder? Die sind meiner Ansicht nach korrekt eingetragen: bei uns: from 192.168.0.0/24 to 192.168.1.0/24 remote: from 192.168.1.0/24 to 192.168.0.0/24 Hier habe ich allerdings eine 255.255.255.0 Subnetmask wie innerhalb jedes Netzwerkes auch. Für den ADSL-Zugang habe ich eine 255.255.255.248 Subnetmask. Gruss Vevie Zitieren Link zu diesem Kommentar
dippas 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 hi das ist definitv ein routing problem ! hast du die routen angepasst ?? lg Das scheint mir in der Tat das Problem zu sein. Tunnel steht, Endpunkte können sich gegenseitig anpingen, aber die anderen Netzteilnehmer wissen nicht, so das GW zum anderen Netz ist. Daher kommt auch keine Rückantwort. Also bitte mal auf den jeweiligen Firewalls kontrollieren, ob bei den Netzwerkrouten ein Eintrag des gegenüberliegenden Netzwerks vorhanden ist und ob dieser Eintrag korrekt auf den Tunnel zeigt. Wenn das geklärt ist und es immer noch nicht funzt, kann man weiter nachdenken. Es ist aber Grundvoraussetzung, dass diese Einträge richtig konfiguriert sind. grüße dippas Zitieren Link zu diesem Kommentar
dippas 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Hallo Herr Rossi, mit "Routen angepasst" meinst Du sicherlich die Routing Policies auf den Fireboxen, oder? Die sind meiner Ansicht nach korrekt eingetragen: bei uns: from 192.168.0.0/24 to 192.168.1.0/24 remote: from 192.168.1.0/24 to 192.168.0.0/24 Hier habe ich allerdings eine 255.255.255.0 Subnetmask wie innerhalb jedes Netzwerkes auch. Für den ADSL-Zugang habe ich eine 255.255.255.248 Subnetmask. Gruss Vevie Nein, dass sind die Einträge, welche in der Policy eingetragen werden, damit der Tunnel zum jeweils gewünschten Netzwerk aufgebaut werden kann. Ander ausgedrückt: Hiermit legst Du fest, für welches Zielnetz dieser Tunnel verantwortlich ist. Andere Tunnel haben andere Verbindungen. grüße dippas Zitieren Link zu diesem Kommentar
weg5st0 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Unter Umständen ist auch einfach nur das falsche DefaultGateway eingetragen, bzw. das Default Gateway kennt die anderen Netze nicht (Sollte das DefGW nicht der VPN Router sein). Zitieren Link zu diesem Kommentar
Hr_Rossi 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 hi hast du mehrere gateways im einsatz oder nur jeweils das eine !? lg edit1: oder musst du acuh vielleicht noch filterregeln erstellen oder access-lists (die den trafiic regeln) leider kenn ich das produkt nicht.... edit2: sind sies 2k3 DC wie siehts mit der Firewall aus !? Zitieren Link zu diesem Kommentar
vevie 10 Geschrieben 3. Januar 2006 Autor Melden Teilen Geschrieben 3. Januar 2006 Hallo Götz, der ping vom LAN 192.168.1.17 zu 192.168.1.5 funktioniert: H:\>ping 192.168.1.5 Ping wird ausgeführt für 192.168.1.5 mit 32 Bytes Daten: Antwort von 192.168.1.5: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.1.5: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.1.5: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.1.5: Bytes=32 Zeit<1ms TTL=64 Ping-Statistik für 192.168.1.5: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms H:\>ipconfig /all Windows-IP-Konfiguration Hostname. . . . . . . . . . . . . : UNTERIBERG Primäres DNS-Suffix . . . . . . . : arnika.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert. . . . . . . : Nein WINS-Proxy aktiviert. . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : arnika.local Ethernetadapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Intel® PRO/1000 MT Network Connect ion Physikalische Adresse . . . . . . : 00-06-5B-BF-EF-22 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 192.168.1.17 Subnetzmaske. . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.5 DHCP-Server . . . . . . . . . . . : 192.168.1.1 DNS-Server. . . . . . . . . . . . : 192.168.1.1 217.8.192.51 Lease erhalten. . . . . . . . . . : Dienstag, 3. Januar 2006 08:19:48 Lease läuft ab. . . . . . . . . . : Mittwoch, 11. Januar 2006 08:19:48 ipconfig vom anderen Ende: Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. K:\>ipconfig /all Windows-IP-Konfiguration Hostname. . . . . . . . . . . . . : coq04 Primäres DNS-Suffix . . . . . . . : Vermag.local Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert. . . . . . . : Nein WINS-Proxy aktiviert. . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : Vermag.local Ethernetadapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : 3Com 3C920 integrierter Fast Etherne t-Controller (3C905C-TX kompatibel) Physikalische Adresse . . . . . . : 00-06-5B-26-C0-C5 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 192.168.0.76 Subnetzmaske. . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.0.5 DHCP-Server . . . . . . . . . . . : 192.168.0.1 DNS-Server. . . . . . . . . . . . : 192.168.0.1 217.8.192.51 217.8.192.52 Lease erhalten. . . . . . . . . . : Dienstag, 3. Januar 2006 09:19:25 Lease läuft ab. . . . . . . . . . : Freitag, 13. Januar 2006 12:19:25 Zitieren Link zu diesem Kommentar
weg5st0 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Hm, das sieht eigentlich ganz gut aus... Wenn der Ping nicht durch den Tunnel geht, sind denn da irgendwelche Policies drauf? Wenn ja: musst du die ICMP Policy ändern. Sonst jemand eine Idee? Zitieren Link zu diesem Kommentar
Overon 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 Schau mal ob Du NAT Traversal aktivieren kannst, ich kenn dieses Problem in Verbindung mit NAT. Zitieren Link zu diesem Kommentar
Hr_Rossi 10 Geschrieben 3. Januar 2006 Melden Teilen Geschrieben 3. Januar 2006 NAT wird in diesem Fall galub ich nicht schuld sein, da dies eine klassisches Site-to-Site IPSec VPN ist ! Meine Vermutung: Client Firewall, oder irgendeine Sicheheitseinstellung auf den DC wo verhindert wird, dass Domainfremde den DC pingen, oder in der Firewall policys die noch fehlen wo man vielleicht explizit sagen muss wer mit wem wohin darf ..... lg Zitieren Link zu diesem Kommentar
vevie 10 Geschrieben 3. Januar 2006 Autor Melden Teilen Geschrieben 3. Januar 2006 NAT Traversal hatte ich auch schon mal aktiviert. Hat nix gebracht. Zum Gateway-Thema: Ich habe jeweils einen adsl-Router vor jeweils nur einer firebox stehen. Ja, beides sind W2k3 DCs mit SP1. Um die Firewall habe ich mich noch nie gekümmert. Muss ich dort den udp Port 500 für IPSEC erst noch eintragen? Die ICMP settings erlauben den ping request. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.