-
NCP / Win7 - Tunnel steht kein Ping
Hallo,
wir setzten auf einem Win7-Rechner den NCP Secure Entry Client in neuester Version ein. Der Tunnelaufbau funktioniert, bei einem Ping zählt der Client auch TX-Pakete (gesendet) nach oben, jedoch erhalte ich keine Antwort (RX-Pakete: 0)
Nach Telefonat mit dem NCP-Support habe ich eine Testverbindung zu NCP hergestellt, bei dieser Funktioniert der Ping, so das der NCP-Support das Problem auf der Gegenseite (Intranator) vermutet. (Rück-Routing-Problem oder NAT-Problem)
NAT-Traversal ist aktiviert, das Logfile gibt folgende Infos aus:
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: parsing ModeCfg request
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: unknown attribute type (20002)
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: unknown attribute type (20003)
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: unknown attribute type (20004)
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: unknown attribute type (20005)
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: peer requested virtual IP %any
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: assigning virtual IP xxx.xx.xx.xx to peer
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: sending ModeCfg reply
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: sent ModeCfg reply, established
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #455: responding to Quick Mode
Aug 5 11:39:11 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #455: IPsec SA established {ESP=>0x50c858f6 <0xc77971df NATOA=0.0.0.0}
...
Aug 5 11:39:15 intranator pluto[4545]: "C31"[8] xx.xx.xx.xx:35266 #453: received Delete SA(0x9e0b9f3e) payload: deleting IPSEC State #454
Ich habe auf dem Intranator zur Diagnose noch folgendes versucht:
tcpdump -vvv -i any -n 'src host <vpn-client-ip> and dst net <lokales netz>/24'
Keine Ausgabe
Wenn ich das selbe Kommando mit einer funktionierenden VPN-Verbindung und Ping mache, werden eine Menge Pakete angezeigt.
Ich bin etwas ratlos und weiss nicht mehr, wo ich den Fehler suchen könnte.
Viele Grüße
Jürgen Achberger
-
Hallo,
was haben Sie denn auf dem Client im Menü "Split Tunneling" eingestellt?
Was haben Sie auf dem Intranator im Menü Dienste > VPN > Verbindungen : Tunnel unter "Lokales Netz" ausgewählt?
Passen diese Netze zusammen?
Ist der Zielhost, den Sie vom Clientrechner aus pingen innerhalb dieses Netzes?
Was für eine Firewall-Regelliste haben Sie auf dem Intranator für den Client im Menü Dienste > VPN > Verbindungen : Rechte eingestellt?
Herzliche Grüße,
v. Egidy
-
Hallo Herr v. Egidy,
Die Netze unter [VPN-Client - Split Tunneling] und [Server - Lokales Netz] sind identisch, auch die Subnetzmasken passen. Der Zielhost ist im konfigurierten lokalen Netz.
Hier die FW-Regel-Liste:
01 Alle Intranator LAN IPs icmp-basis, ssh, dns Accept
02 Alle verwaltung 4d Accept Zugriff auf Verwaltung CREW
03 Alle janeway netbios, cifs Accept janeway fileserver
04 Alle eth0 (Lokales Netz) ping Accept
05 Alle Alle Alle Reject Log: REJECT local Limit gültig für Log: Durchschnitt 5 Pakete pro Sekunde. Spitzenwert 5 Pakete
Alle Alle Alle Deny Log: DENY Limit gültig für Log: Durchschnitt 5 Pakete pro Sekunde.
Dankeschön
Jürgen Achberger
-
Hallo,
also der Firewall-Regelliste nach sollten Sie auf jeden Fall den Ping durchkriegen.
Wie lautet das lokale Netz in dem sich der Client befindet?
Wenn das Netz zwischen Client und dem Router beim Client vor Ort einen IP-Konflikt mit dem Netz hinter dem Intranator bekommt, funktioniert das Routing nicht mehr.
Herzliche Grüße,
v. Egidy
-
Hallo Herr v. Egidy,
das Netz auf Client-Seite ist 192.168.200.0/24, Zielnetz bei der VPN Gegenstelle ist 172.20.0.0/24, der VPN Client erhält per mode-config die 172.20.7.104.
Was mich irritiert:
Obwohl der VPN-Clinent RX-Bytes hochzählt, zeigt die Status-Ansicht des NCP-Netzwerkadapters 0 gesendete und empfangene Bytes an.


Kann es sein, dass es schlicht daran liegt, dass der NCP-Adapter von Win7 als "öffentliches Netzwerk" geführt wird und deshalb Client-Seitig Sicherheitsrichtlinien greifen, die den Verkehr unterbinden?
Danke und Grüße
-
Gelöst!
Wir haben das Problem per Telefon-Ticket gelöst.
Intranator und NCP (Version Version 9.24 Build 84) verstehen sich bei SHA-2-Verschlüsselung nicht. Nach Wechsel auf SHA-1 als Hash-Algorithmus in der Phase 2 funktioniert der Datendurchsatz durch den Tunnel.
Vielen Dank.
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
Foren-Regeln