18.12.2010, aktualisiert am 18.10.2012

12961

Lancom 1721, advanced VPN Client, sbs 2003

Hallo,

Habe in unserer Firma in meinem SBS2003 Server zwei
Netzwerkkarten. eine für die Verbidnung zu meinem
DSL-Router (lancom 1721), die andere als Verbindung
zu meinem lokalen Netz.
Lokales Netz: 192.168.16.0
Netz des lancom 1721: 192.168.0.0
Ip-Adresse lancom 1721: 192.168.0.1

Ich habe nun mittels des lanconfig Assistent ein Profil für
ein VPN-Einwahl erstellt. Hierbei habe ich als Adressbereich
für den VPN-Client 192.168.0.100-192.168.0.150 angegeben.

Die Einwahl von meinem Heimrechner funktionierte auf Anhieb.
Der Client bekommt hierbei eine IP aus dem gewählten Adressbereich zugewiesen.

Ich erreiche jedoch nicht das Netz des SBS-Server (192.168.16.0).
Habe dies mit einem Ping auf 192.168.16.2 (sbs-Server versucht).

Gruß

Jürgen

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 157224

Url: https://administrator.de/forum/lancom-1721-advanced-vpn-client-sbs-2003-157224.html

Ausgedruckt am: 23.12.2024 um 07:12 Uhr

30 Kommentare

Neuester Kommentar

Guten Morgen,

ich erinner mich schwach, es könnte mit der Funktion Routing ins VPN zu tun haben. Ich gehe mal davon aus das dein routing ansonsten perfekt läuft. Da gibt es bei LANCAM eine schöne Beschreibung unter dem Stichwort VPN zu VPN Routing, dort ist im QoS/Filter eine Regel zu definieren, irgendwie mit übertragen ins VPN (aus dem Kopf geschrieben)

gruss
ulti

Du benötigst zwingend eine statische Route auf dem Lancome ins .16er IP Netz ! Allerdings ist das in starkem Maße davon abhängig ob du auf dem Server NAT (Adress Translation) machst oder nicht ?!
Leider äußerst du dich dazu nicht in deiner o.a. Beschreibung so das ein qualifizierter Tip nicht wirklich möglich ist !
Das folgende Turorial beschreibt so ein Netzwerk und die zu machenden Einstellungen im Detail.
Wenn du dich daran hälst bekommst du das Netz im Handumdrehen zum Laufen !

Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Hallo Aqui,

habe das Tutorial gelesen. Das hier dargestellte Szenario entspricht
bis auf die Nummerierung der Netzwerke exakt meiner Konstellation.

Mein SBS-Server der beide
Netze verbindet hat folgende Ip-Adressen: 192.168.0.2 und 192.168.16.2.

Ein statische Route ist auf meinem Lancom (DSL-Router) nicht konfiguriert.
Habe nun ein Ping von einem Client aus dem Netz 192.168.16.0
an meinen Lancom DSL-Router gesendet 192.168.0.1.
Die Ping-Anfrag wurde bentwortet.
Ich gehe daher davon aus, dass NAT auf meinem SBS-Server konfiguriert ist.

Nun wieder zurück zu meinem VPN-Problem.
Ich habe von meinem Client (Zuhause) der über VPN an das Netz 192.168.0.0
angebunden ist einen Ping an meinen SBS-Server (192.168.0.2) gesendet.
Diese Anfrage wurde nicht beantwortet.
Dies müsste doch unabhänig davon funktionieren, ob mein SBS-Server
NAT macht oder nicht, da das Paket doch innerhalb des Netzes 192.168.0.0 bleibt.

Auf meinem Lancom ist Port-Forwarding konfiguriert. Für Exchange-Server etc.

Ja, in der Tat, denn du befindest dich im gleichen Netzwerk wie der Server.
Es ist aber möglich das der Server durch seine Firewall nicht auf ICMP Pakete antowrtet und diese blockt. Das solltest du in den erweiterten Eigenschaften der Firewall unter ICMP einmal genau checken für den Adapter.
Der Haken bei auf eingehende Echo Pakete antworten MUSS gesetzt sein !

Für ein VPN ist es Blödsinn auf dem Lancom Port Forwarding für ServerDienste zu konfigurieren. Damit konterkarierst du ja eine VPN Anwendung in sich, denn du bohrst in die Router Firewall damit Löcher von außen auf diese Anwendungen.
Lediglich einzig für die VPN Anwendung musst du ein Port Forwarding einrichten sonst nichts
Leider teilst du uns ja nicht mit WELCHES VPN Protokoll du benutzt aber wenn es PPTP ist dann musst du Port TCP 1723 und das GRE Protokoll (Eigenes IP Protokoll mit der Nummer 47, nicht TCP 47 !) auf die lokale IP des Servers forwarden. Siehe hier:
VPNs einrichten mit PPTP
L2TP benutzt andere Ports !!

Viel fraglicher ist auch die Tatsache warum du nicht viel sinnvoller auf dem Lancom Router selber das VPN terminierst, dann hättest du diese Frickelei mit dem NAT gar nicht erst. Wenn man schon so einen qualitativ guten Router hat liegt das ja auf der Hand und wäre der richtige Weg:
http://www.shrew.net/support/wiki/HowtoLancom
Wozu hast du sonst soviel in den Router investiert ??

Hallo Aqui,

ich habe die VPN-Verbindung mittels dem Setup-Assistent des Lancom-Routers erstellen lassen .
(Einwahl-Zugang bereitstellen). Dieser Assistent erstellt eine Konfigurationsdatei mit
der ich dann einfach meinen VPN-Client konfigurieren kann.
Laut Router-Beschreibung werden die Daten mittels IP-Sec übertragen und mit den Verfahren 3-DES,
AES oder Blowfish verschlüsselt.

Eine Ping-Anfrage an meinen SBS-Server über einen Client des Netzes 192.168.16.0 funktioniert. Das bedeutet
doch, dass der Server auf eingehende Echo-Pakete antwortet, oder macht es einen Unterschied, ob ich
diese Anfrage aus meinem lokalen Netz oder von einem Client aus Starte der über die VPN-Verbindung angebunden ist?

Der Exchange-Server ist im SBS-Server enthalten.
Um meinen Exchange-Server von aussen für den Empfang von Emai erreichbar zu machen benötige ich doch Port-Fowarding?!

Das kommt drauf an....
Als VPN Client benötigst du kein Port Forwarding für den Exchange. Wäre ja auch völliger Unsinn, denn der VPN Client verhält sich ja wie ein im lokalen Netzwerk angeschlossener Client völlig transparent ! Das ist ja auch der tiefere Sinn eines VPNs !!
Wenn du also nur mit VPN Clients auf dem Exchange rauf willst benötigst du also folglich keinerlei Port Forwarding.
Port Forwarding benötigst du lediglich wenn externe Mail Hosts auf den Exchange Mails zustellen sollen (SMTP, TCP 25) sonst niemals.

Du sagst du kannst di remote einwählen und bekommst auch eine korrekte IP, richtig
Output von ipconfig -all am VPN Adapter und route print am remoten VPN Client wäre mal hilfreich !!

Wenn dem so ist kannst du deinen Server mit der lokalen LAN IP 192.168.16.x pingen, richtig ?
Kannst du auch das LAN Interface 192.168.16.y des Lancom Routers anpingen ?

Hallo aqui,

vielen Dank für Deine Hilfe.

Port-Forwarding ist für die eingehenden Mails über Port 25 zuständig. Eingehende Mails
werden direkt an meinen Exchange Email-Server über DNS (MX-Eintrag) übermittelt.

Hier ipconfig -all an meinem VPN-Client bei bestehender VPN-Verbindung:

Windows-IP-Konfiguration

Hostname. . . . . . . . . . . . . : juergenhome
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Unbekannt
IP-Routing aktiviert. . . . . . . : Nein
WINS-Proxy aktiviert. . . . . . . : Nein

Ethernetadapter LAN-Verbindung 2:

Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung
Beschreibung. . . . . . . . . . . : NVIDIA nForce Networking Controller
Physikalische Adresse . . . . . . : 00-13-D3-E3-8B-37

Ethernetadapter LAN-Verbindung:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Realtek RTL8139/810x Family Fast Eth
ernet NIC
Physikalische Adresse . . . . . . : 00-E0-7D-02-36-C2
DHCP aktiviert. . . . . . . . . . : Nein
IP-Adresse. . . . . . . . . . . . : 10.0.0.11
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DNS-Server. . . . . . . . . . . . : 10.0.0.1

Ethernetadapter LAN-Verbindung 4:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : NCP Secure Client Virtual Adapter
Physikalische Adresse . . . . . . : 02-00-4E-43-50-49
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse. . . . . . . . . . . . : 192.168.0.112
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.0.113
DHCP-Server . . . . . . . . . . . : 192.168.0.113
DNS-Server. . . . . . . . . . . . : 192.168.0.1
Lease erhalten. . . . . . . . . . : Freitag, 24. Dezember 2010 10:04:16
Lease läuft ab. . . . . . . . . . : Donnerstag, 10. Februar 2011 23:09:4
1

C:\Dokumente und Einstellungen\juergen>

Hier route print am VPN Client:

C:\Dokumente und Einstellungen\juergen>route print

Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 13 d3 e3 8b 37 ...... NVIDIA nForce Networking Controller - Paketplane
r-Miniport
0x3 ...00 e0 7d 02 36 c2 ...... Realtek RTL8139-Familie-PCI-Fast Ethernet-NIC -
Paketplaner-Miniport
0x4 ...02 00 4e 43 50 49 ...... NCP Secure Client Virtual Adapter - Paketplaner-
Miniport

Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.0.113 192.168.0.112 1
10.0.0.0 255.255.255.0 10.0.0.11 10.0.0.11 20
10.0.0.11 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.0.0.11 10.0.0.11 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.112 192.168.0.112 1
192.168.0.112 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.0.255 255.255.255.255 192.168.0.112 192.168.0.112 1
217.224.12.181 255.255.255.255 10.0.0.1 10.0.0.11 1
224.0.0.0 240.0.0.0 10.0.0.11 10.0.0.11 20
255.255.255.255 255.255.255.255 10.0.0.11 10.0.0.11 1
255.255.255.255 255.255.255.255 192.168.0.112 2 1
255.255.255.255 255.255.255.255 192.168.0.112 192.168.0.112 1
Standardgateway: 192.168.0.113

Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Anzahl
217.224.12.181 255.255.255.255 10.0.0.1 1

C:\Dokumente und Einstellungen\juergen>

Was meinst Du mit ipconfig -all am VPN-Adapter. Der VPN-Adapter ist doch mein dsl-Router ?

Ja, das LAN Interface des Lancom Routers kann ich auch anpingen.
Diese ist nicht 192.168.16.y sondern 192.168.0.1.

Hier noch einmal mein System in der Firma:

Internet
|
Lancom DSL router (192.168.0.1)
|
SBS-Server (192.168.0.2 + 192.168.16.2)
|
lokales Netz (192.168.16.0)

Zuhause verwende ich eine Fritzbox 7170 als DSL-Router.
Von meinem Heimrechner stelle ich die Verbindung zum Lancom VPN-Router in
der Firma mittels dem Advanced VPN-Client her.

Frohe Weihnachten

Du kannst oben sehen, das dein NCP VPN Client dir komplett alles auf den VPN Tunnel umbiegt: "Standardgateway: 192.168.0.113" Wenn er aktiv ist. Damit ist dann keinerlei lokaler Traffic im 10er Netz mehr möglich, das sollte dir bewusst sein !!
Was meinst du mit "Der VPN-Adapter ist doch mein dsl-Router ?" ???
Das stimmt ja nicht, denn du gehst ja vermutlich über die 10.0.0.0 /24er LAN Verbindung vom Client ins Internet auf den Lancom als VPN Server, oder ?? D.h. dein Tunnel arbeitet über die 10er LAN Verbindung und innerhalb im Tunnel nutzt du die 192.168.0.0 /24

Du kannst am Route output aber ganz klar sehen, das KEINE Route ins 192.168.16.0er Netz via 192.168.0.112 (also dem VPN Tunnel) aktiv ist am Client !!
Folglich können also auch niemals Pakete ans 192.168.16.0er Netz ihr Ziel erreichen,... normalerweise.
Da der NCP VPN Client dir aber das Default Gateway auf den Lancom 192.168.0.113 "umbiegt" bei aktivem Client müsste es wieder funktionieren.
Das Problem liegt hier vermutlich am Lancom, denn der Hat wahrscheinlich keine statische Route ins .16.0er Netzwerk konfiguriert wie hier beschrieben:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Kann das sein ??
Oder du machst kein Routing am SBS Server sondern nur NAT (ICS) was dann das gleiche Problem erzeugt ?
Es ist auch möglich das der NCP Client im Gegensatz zu deinen anderen Rechner die propagierte Route nicht annimmt. Benutzt du bei beiden Clients die gleichen VPN Client ??
Hast du ggf. mal einen anderen wie den freien Shrew Client probiert (Anderen VPN Client dafür zuerst deinstallieren !)
http://www.shrew.net/support/wiki/HowtoLancom
Was sagt ein Pathping oder Traceroute wenn du das 192.168.16er Server Interface ansprichst ?

Zitat von @aqui:

Du kannst oben sehen, das dein NCP VPN Client dir komplett alles auf den VPN Tunnel umbiegt: "Standardgateway:
192.168.0.113" Wenn er aktiv ist. Damit ist dann keinerlei lokaler Traffic im 10er Netz mehr möglich, das sollte dir
bewusst sein !!

Es gibt in meinem System kein NIC mit 192.168.0.113.
Wenn ich die VPN-Verbindung unterbreche und dann erneut herstelle, erhält mein VPN-Client eine neue
IP aus dem Netz 192.168.0.0. Die IP des Standargateway (ipconfig /all) ist immer ein Nummer höher als die IP meines
VPN-Clients. (Z.B.: IP VPN-Client: 192.168.0.101, Standartgateway: 192.168.0.102)

Mir ist noch etwas aufefallen:
Wenn ich mir auf meinem Heimrechner bei aktiver VPN-Verbindung die TCP/IP Einstellungen der Lan-Verbindung
meiner physischen Realtek-Netzwerkkarte anschaue (Systemsteuerung - Netzwerkverbindungen ...), dann ist hier weiterhin
meine Fritzbox als Standartgateway eingetragen (10.0.0.1). Warum ist über die Abfrage mit ipconfig hier kein Eintrag zu sehen?

Wie kann ich feststellen, ob an meinem VPN-Client tatsächlich alles über den VPN-Tunnel läuft.
Alles was sich ausserhalb meines 10er Netzes befindet läuft über den VPN-Tunnel, das verstehe ich.
Weshalb ist keinerlei Traffic im 10er Netz mehr möglich? Wenn ich eine Anfrage an ein Gerät innerhalb des 10er Netzes
starte (z.B. ping an meine Netzwerkfestplatte 10.0.0.2) dann wird dieses Paket doch nicht über den VPN-Tunnel geschickt?
Es sollte eigentlich so sein, dass nur Anfragen in das Netz meiner Firma( 192.168.0.0 und 192.168.0.16)
über den VPN-Tunnel laufen. Ist das normalerweise machbar?

Was meinst du mit "Der VPN-Adapter ist doch mein dsl-Router ?" ???
Das stimmt ja nicht, denn du gehst ja vermutlich über die 10.0.0.0 /24er LAN Verbindung vom Client ins Internet auf den
Lancom als VPN Server, oder ?? D.h. dein Tunnel arbeitet über die 10er LAN Verbindung und innerhalb im Tunnel nutzt du die
192.168.0.0 /24

Ja, Ich gehe über meine Fritzbox (10.0.0.1) ins Internet. Diese ist an meinem Client (Zuhause) als Standargateway eingerichtet.
Diese Einstellung des Standartgateways wird wohl bei aktiver VPN-Verbindung ausser Kraft gesetzt.

Du kannst am Route output aber ganz klar sehen, das KEINE Route ins 192.168.16.0er Netz via 192.168.0.112 (also dem VPN
Tunnel) aktiv ist am Client !!

Aber eine Ping auf die 192.168.0.2 des SBS sollte bei aktiver VPN-Verbindung dennoch möglich sein, denn der Lancom (192.168.0.1) ist doch auch erreichbar?!

Folglich können also auch niemals Pakete ans 192.168.16.0er Netz ihr Ziel erreichen,... normalerweise.
Da der NCP VPN Client dir aber das Default Gateway auf den Lancom 192.168.0.113 "umbiegt" bei aktivem Client müsste
es wieder funktionieren.

Der Lancom hat die 192.168.0.1 und ist über diese bei aktiver VPN-Verbindung auch erreichbar! 192.168.0.113 gibt es nicht!

Das Problem liegt hier vermutlich am Lancom, denn der Hat wahrscheinlich keine statische Route ins .16.0er Netzwerk konfiguriert
wie hier beschrieben:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Kann das sein ??
Oder du machst kein Routing am SBS Server sondern nur NAT (ICS) was dann das gleiche Problem erzeugt ?
Es ist auch möglich das der NCP Client im Gegensatz zu deinen anderen Rechner die propagierte Route nicht annimmt. Benutzt du
bei beiden Clients die gleichen VPN Client ??
Hast du ggf. mal einen anderen wie den freien Shrew Client probiert (Anderen VPN Client dafür zuerst deinstallieren !)
http://www.shrew.net/support/wiki/HowtoLancom
Was sagt ein Pathping oder Traceroute wenn du das 192.168.16er Server Interface ansprichst ?

Pathping von VPN-Client (Johann) auf SBS-Server (192.168.16.2).
( Habe mittlerweile den VPN-Client auf einem anderen Rechner (Johann) im Heimnetzwerk getestet, deshalb nicht über geänderten Namen wurndern):

C:\Dokumente und Einstellungen\Johann Winczy>pathping 192.168.16.2

Routenverfolgung zu 192.168.16.2 über maximal 30 Abschnitte

0 johann [192.168.0.117]
1 lancom.intern [192.168.0.1] meldet: Zielnetz nicht erreichbar.

Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 johann [192.168.0.117]
100/ 100 =100% |
1 --- 100/ 100 =100% 0/ 100 = 0% johann [0.0.0.0]

Ablaufverfolgung beendet.

Pathping von VPN-Client auf SBS-Server (192.168.0.2):

C:\Dokumente und Einstellungen\Johann Winczy>pathping 192.168.0.2

Routenverfolgung zu 192.168.0.2 über maximal 30 Abschnitte

0 johann [192.168.0.117]
1 lancom.intern [192.168.0.1] meldet: Zielhost nicht erreichbar.

Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 johann [192.168.0.117]
100/ 100 =100% |
1 --- 100/ 100 =100% 0/ 100 = 0% johann [0.0.0.0]

Ablaufverfolgung beendet.

C:\Dokumente und Einstellungen\Johann Winczy>

Pathping von VPN-Client auf lancom (192.168.0.1):

C:\Dokumente und Einstellungen\Johann Winczy>pathping 192.168.0.1

Routenverfolgung zu lancom.intern [192.168.0.1]
über maximal 30 Abschnitte:
0 johann [192.168.0.117]
1 lancom.intern [192.168.0.1]

Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 johann [192.168.0.117]
0/ 100 = 0% |
1 52ms 0/ 100 = 0% 0/ 100 = 0% lancom.intern [192.168.0.1]

Ablaufverfolgung beendet.

C:\Dokumente und Einstellungen\Johann Winczy>

Es gibt in meinem System kein NIC mit 192.168.0.113..."
Nein, das ist auch die IP Adresse des Lancom im VPN Tunnel !! Siehe Output von route print oben :"Standardgateway: 192.168.0.113" (letzte Zeile)
Der Lancom vergibt diese dynamisch an alle sich einwählenden PPTP Clients. PPTP heisst ja "Point to Point" meint also immer nur 2 Teilnehmer mit eine 32 Bit Hostmaske !

..."dann ist hier weiterhin meine Fritzbox als Standartgateway eingetragen (10.0.0.1). Warum ist über die Abfrage mit ipconfig hier kein Eintrag zu sehen? "
Nun das ist ganz klar, weil der NCP VPN Client dynamisch das Standardgateway ersetzt, damit verschwindet es aus der Konfig sobald das VPN aktiv ist.
Das ist ein Standard VPN Verhalten und kann an den meisten Clients einfach eingestellt werden indem es per Haken aktiviert oder deaktiviert wird.
Siehe #comment-toc3 HIER am PPTP Client ! Thema: Standardgateway für das Remotenetzwerk verwenden!!!
Vermutlich hat dein NVP Client diesen Haken auch im Setup und damit kann man das abschalten.
Einige VPN Clients wie z.B. der Cisco VPN Client erlauben das aber aus Sicherheitsgründen gar nicht, damit niemals eine Verbindung zw. lokalem Netzwerk und Firmennetzwerk bei remoten Mitarbeitern zustande kommt.
Wenn du Pech hast ist das auch bei dir der Fall ?! Check also die NCP Client Settings dafür !!

"...Wie kann ich feststellen, ob an meinem VPN-Client tatsächlich alles über den VPN-Tunnel läuft. "
Indem du Traceroute (tracert bei Winblows) oder Pathping verwendest auf die Ziel IP Adresse !! Das zeigt dir alle Einzelhops an die ein Paket auf seinem Weg zum Ziel nimmt !
10er Pakete bleiben bei dir im lokalen Netz (LAN) alles was nicht 10.0.0.0 /24 ist geht bei deiner Konstellation mit aktivem VPN Client dann über den Tunnel !
Ist der Client nicht aktiv rennt alles andere dann über die FB mit der 10.0.0.1...so einfach ist das !

"...Aber eine Ping auf die 192.168.0.2 des SBS sollte bei aktiver VPN-Verbindung dennoch möglich sein"
Ja, sicher sofern der Server sein Standartgateway auf den Lancom 192.168.0.1 eingestellt hat um am 192.168.16.0 /24 Segment kein Gateway konfiguriert ist.
Hier MUSS der Gateway eintrag leer bleiben ! (Siehe Tutorial hier !)

"...192.168.0.113 gibt es nicht! "
Falsch ! Doch... diese IP gibt es die vergibt der Lancom dynamisch bei aktiver PPTP Verbindung !! Siehe Erklärung zu PPTP oben !!

"...1 lancom.intern [192.168.0.1] meldet: Zielnetz nicht erreichbar."
Klar...., vermutlich hast du die statische Route auf dem Lancom
ip route 192.168.16.0 maske 255.255.255.0 <ip_sbs_server>
vergessen !! Kann das sein ?? Damit "kennt" der Lancom dann logischerweise das IP Netz "hinter" dem Server nicht (woher auch, denn raten kann er nicht !!) und das Ergebnis ist dann logischerweise Zielnetz nicht erreichbar!!
Lies dir bitte nochmal genau das Tutorial dazu durch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Ganz speziell was die Punkte ICS bzw. NAT anbetrifft:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Was machst DU auf deinem Server ??? ICS/NAT ja oder nein ?? Wenn du ICS/NAT aktiviert hast dann ist hier auf dem Server selber wiederum eine Firewall aktiv die den Zugang zum 192.168.16.0er Netz blockt und ein Port Forwarding erzwingt für den Zugang zu deinem 192.168.16.0er Netz.
Stelle also absolut sicher das du kein ICS NAT auf deinem Server machst und trage dann die statische Route auf dem Lancom ein !!
und was die statische Route auf dem Router anbetrifft:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Wenn du diese Fragen beantwortet hast dann machen wir hier weiter im Text....

Hallo aqui,

192.168.0.113 ist nicht erreichbar. Wenn dies die IP des Lancom
im VPN Tunnel ist, dann müsste eine Ping-Anfrage des VPN-Client
auf diese IP doch erfolgreich sein.
Über 192.168.0.1 ist der Lancom bei aktiver VPN-Verbindung vom VPN-Client
aus erreichbar. ich gelange über diese IP vom VPN-Client aus auch auf das
Webinterface des Lancom.
Weshalb vergibt der Lancom diese IP. Er hat doch eine IP aus dem
192.168.0.0 /24 Segment, nämlich die 192.168.0.1?

Ich habe mir das Tutorial noch einmal angeschaut und die Konfguration unseres
SBS-Servers überprüft.
Das Standartgateway des Servers ist auf den Lancom 192.168.0.1 eingestellt.
Am 192.168.16.0 /24 Segment ist kein Gateway konfiguriert.
Dies müsste also soweit in Ordnung sein.
NAT ist jedoch aktiviert.
Da ich mich zurzeit im Urlaub befinde und lediglich über den WEB-Arbeitsplatz
an den Server komme, werde ich diese Einstellung erst ändern und testen,
wenn ich wieder zurück bin.

Ich verstehe jedoch immer noch nicht, dass ein Ping vom VPN-Client an die NIC
192.168.0.2 des SBS-Server nicht erfolgreich ist. Dies müsste doch funktionieren

Gruß
Jürgen

"müsste eine Ping-Anfrage des VPN-Client auf diese IP doch erfolgreich sein..."
A.: Eigentlich ja, denn es ist eine gültige IP wie die Routing Tabelle ja zeigt. Vermutlich blockt aber der Lancom Pings auf WAN IP Adressen was durchaus üblich ist aus Sicherheitsgründen bei Routern !
..."Weshalb vergibt der Lancom diese IP ?"
A.: Das muss er denn es ist ein Protokollstandard von PPP. Lies dir die PPP Definition durch, dann weisst du warum !
"Dies müsste also soweit in Ordnung sein."
A.: Ja, absolut das ist korrekt !
..."NAT ist jedoch aktiviert. !"
A.: Böses Faul !!.... damit ist der Fehler dann klar, denn du bleibst in der NAT Firewall des Servers hängen ! Hier kommst du dann nur mit Port Forwarding weiter für vereinzelnde Ports und Hosts. Ein transparentes Routing zwischen den Segmenten erlaubt dies NICHT.
Das warum und die Nachteile sind ja hinreichend im Tutorial erklärt ! Stelle das unsinnige NAT ab und alles wird gut !
..."an die NIC 192.168.0.2 des SBS-Server nicht erfolgreich ist. "
A.: Ja, in der Tat das sollte immer klappen. Vermutlich ist aber ICMP in der Server Firewall blockiert oder abgeschaltet so das kein ICMP echo Reply (Ping) vom Server kommt. Das solltest du dringend in den FW Settings überprüfen.
Hilfreich ist dabei ein Wireshark oder ein MS Netmonitor
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&F ...
auf dem Server. Damit kannst du sofort sehen ob überhaupt ICMP Echo Pakete (und auch alles andere ais dem VPN) beim Server ankommen.
Dieser Check bringt dir dann das finale OK !

Hallo aqui,

möchte nun NAT am SBS-Server für 192.168.0.2 deaktivieren.

Hier steht unter dem Reiter "NAT/Basisfirewall" folgendes zur Auswahl:

Schnittstellentyp:

1. An eien privates Netzwerk angeschlossene, private Schnittstelle

2. An das Internet angeschlossene, öffentliche Schnittstelle (zurzeit aktiviert !!)

Hier 2 gibt es noch die folgenden Optionen :
2.1 NAT auf dieser Schnittstelle aktiverien (zurzeit aktivert !!)
2.2 Basisfirewall auf dieser Schnittstelle aktivieren (zurzeit aktiviert !!)

3. Nur den Basisfirewall aktivieren

Es gibt dann nich den Punkt "Statische Paketfilter" - "Eingehende Filter" - "Ausgehende Filter"
Hier ist unter "Eingehende Filter" folgendes konfiguriert:
"Alle Pakte empfangen ausser den Paketen, die die unten aufegeführten kriterien erfüllen"
Quelladresse : 192.168.16.0, Zieladresse: beliebig

Soll ich nun nur die Option NAT (2.1) deaktivieren oder sind noch weitere Eintellungen erforderlich ?

Den Schnittstellentyp musst du auch umstellen, denn es ist ja gelogen das du am öffentlichen Internet bist...das ist ja erst der Router davor.
Dann NAT abschalten, die Basisfirewall kannst du lassen. Allerdings musst du diese dann immer customizen für Zugriffe die aus dem Routernetz kommen !

Hallo aqui,

habe NAT deaktiviert und die Schnittstelle geändert.
VPN konnte ich noch nicht testen.

Seltsamerweise funktionert ein Ping vom Client aus den Netz 192.168.16.0
auf den LANCOM-Router 192.168.0.1 auch ohne eine statische Route vom
Lancom-Router auf 192.168.0.2. Das kann doch eigentlich nicht sein, denn
der Router kennt doch für die Rückantwort ohne diese Einstellung den Weg
zum Netz 192.168.16.0 nicht ?

Ohne die statische Route konnten die Cliente aus dem Netz 192.168.16.0
allerdings keine öffentlichen Internetseiten aufrufen. Dies funktionierte erst nachdem
ich die statische Route im Lancom eingestellte hatte.

Für die Clients in im Netz 192.168.16.0 ist folgendes konfiguriert:
DHCP-Server: 192.168.16.2
DNS-Server: 192.168.16.2
Standart-Gateway: 192.168.16.2

Nein, der Ping kann ohne statische Route niemals funktionieren.
Das ist ein sicheres Indiz dafür das weiterhin NAT aktiv ist auf dem Server !!!
Nimm dir einen Wireshark Sniffer
http://www.wireshark.org/
und sieh dir das in Echtzeit an...dann siehst du sofort den Beweis !!

Damit ist dann auch klar warum ohne statische Route die Clients logischerweise keine Internetseite aufmachen können, denn wenn der lancom das .16.0er Netz nicht kennt routet der das an seine default Route und die geht zum Internet Provider und damit in den Mülleimer da es ein RFC 1918 IP Netz ist !

Weshalb funktionert bei fehlender statischen Route Ping
aber die Internetseiten nicht.?

Beides wird doch vom selben Client über die selbe Schnittstelle
angefordert.

Es müsste doch beides oder nichts funtkionieren.

Kann es evtl. sein, dass wenn ich als Schnittstellentyp "An ein privates Netzwerk angeschlossene, private Schnittstelle"
aktiviere NAT zwar weiterhin ausgeführt wird, jedoch nur für nicht öffentlichen Verkehr?
Wenn ich diesen Schnittstellentyap aktiviert habe, kann ich keine weiteren Einstellungen für NAT vornehmen.

Das darf nicht sein das der Client Ping aus dem .16.0er Netz funktioniert ohne statische Route ! Was sagt denn ein Traceroute oder Pathping dann ??
Entweder hast du noch einen Backdoor Router oder NAT wird protokollspezifisch (Ping ist ICMP) doch noch ausgeführt.
Wie bereits gesagt: Ein Wireshak Trace schafft da in Sekunden absolute Gewissheit !

Habe nun wireshark auf meinem Client installiert.

Nach dem Start der Aufzeichnung habe ich einen Ping
an 192.168.0.2 ausgeführt und hierbei icmp gefiltert.

Habe hier mal die ersten beiden Zeilen des oberen Abschnittes im Wireshark-Fenster reinkopiert:
8 13.583596 192.168.16.21 192.168.0.2 ICMP Echo (ping) request (id=0x0200, seq(be/le)=38917/1432, ttl=128)
9 13.583698 192.168.0.2 192.168.16.21 ICMP Echo (ping) reply (id=0x0200, seq(be/le)=38917/1432, ttl=128)

Dies wiedeholt sich insgesamt viermal.
Zu jeder der oberen Zeilen gibt es im Mittleren Bereich des Fensters jeweils 4 Abschnitte:
Frame 8:
Ethernet II
Internet Protocol
Internet Control Massage

Das Programm scheint sehr komplex zu sein und für mich auf die Schnelle leider
nicht sehr hilfreich.

Tracert und pathping liefern folgendes Ergebnis:

C:\Dokumente und Einstellungen\j.winczy>tracert 192.168.0.2

Routenverfolgung zu 192.168.0.2 über maximal 30 Abschnitte

1 <1 ms <1 ms <1 ms 192.168.0.2

Ablaufverfolgung beendet.

C:\Dokumente und Einstellungen\j.winczy>pathping 192.168.0.2

Routenverfolgung zu 192.168.0.2 über maximal 30 Abschnitte

0 LAGER.winczy.local [192.168.16.21]
1 192.168.0.2

Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 LAGER.winczy.local [192.168.16.21]

0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.0.2

Ablaufverfolgung beendet.

C:\Dokumente und Einstellungen\j.winczy>

Hallo aqui

ping vom VPN-Client auf SBS-Server 192.168.0.2 und 192.168.16.2
funktioniert nun.

Mich beunruhigt jedoch immer noch der mögliche Ping ohne statische
Route vom Client aus dem 16.0er Netz auf den Lancom (192.168.0.1).
Ping auf z..B. www.google.de funktioniert nur mit statischer Route, demnach
kann es nichts protokollspezifisches sein.

Wie bereits gesagt mit dem Wireshark wäre es ein leichtes das zu sehen. Leider hast du oben nur den Ping zw. .16.21 und .0.2.
Besser wäre hier mal den Ping auf den Lancom mitzusniffern um zu sehen welche Source und Destination IPs im Paket stehen...
Das Programm ist schon sehr hilfreich !! Man muss nur wissen was man macht !!

Habe den Ping nun von .16.21 auf .0.1 (Lancom) ausgeführt.
Beim request steht als Src die 192.168.16.21 und als Dst die 192.168.0.1
Beim reply Src: 192.168.0.1 Dst: 192.168.16.21

Das sieht doch gut aus ! So soll es ja sein und damit funktioniert dann dieser Ping sauber !

Mein Problem ist nur, dass dies genauso funktioniert wenn ich die statische route im Lancom lösche.

Hast du dann auch die gleichen IP Adressen wieder in der Source und Destination beim Ping Trace ??
Es ist möglich das per default ein dynamisches Routing Protokoll z.B. RIP zwischen Server und Lancom aktiv ist oder du das durch Unwissenheit oder Zufall aktiviert hast.
Damit werden die Routen dann dynmaisch ausgetauscht und für Laien sieht es so aus als ob alles "mit Geisterhand" funktioniert.
Das ist die einzige sinnvolle Erklärung die noch übrigbleibt.
Ohne dynmaisches Routing und ohne statische Route könntne die Packete niemals ans Ziel gelangen...logisch !
Check also mal ob du im Setup irgendwo ein dynamisches Routing aktiviert hast... Zu 99% ist das der Fall ! Der Sniffer zeigt dir das auch an denn beide Komponenten senden zyklisch Routing Updates ins Netzwerk !

ja die P-Adressen sind die gleichen.
Weder an meinem SBS ist das RIP-Protokoll konfiguriert noch am Lancom.

Das wäre dann ein Wunder und sowas gibt es bekanntlich in der Netzwerkwelt nicht !!
Da müsste man dann mal genauer analysieren im Netz...kann natürlich sein das du irgendwo noch eine Backdoor Route oder Router hast...oder inkonsitente Subnetzmasken oder...das du Proxy ARP irgendwo benutzt. Irgendwas aus diesem "Strauß" wird es sein... !
Sowas kann man nur lokal identifizieren mit genauerer Analyse, nicht aber über ein Forum ! Sicher ist aber das es eins dieser Mechanismen ist in deinem Netz !!
Fakt ist aber auch das es mit einer sauberen IP Adressierung so nicht klappen kann. Ist ja auch logisch wenn man sich die Funktion von IP Routing vor Augen führt.

Hallo aqui,

in der Routerkonfiguration des Lancom ist der Punkt
"Entfernte Stationen mit Prox-ARP einbinden" aktiviert.

Könnte dies der Grund für die Ping-Antwort sein?

Ha !! Da haben wir den Übeltäter wie vermutet !! Was Proxy ARP macht kannst du hier nachlesen:
http://de.wikipedia.org/wiki/Address_Resolution_Protocol#Proxy_ARP

Ist die Frage ob du damit leben willst. Kann ein Sicherheitsloch werden durch die inkonsistenten masken die Proxy ARP erzwingt aber das musst du selber entscheiden. Das klappt auch nur weil du gleichlautenden Subnetze hast. Hättest du 10er oder 172er RFC 1918 Adressen verwendet hätte auch Proxy ARP nicht gegriffen

Na ja jedenfalls wissen wir nun wer der böse Buhmann ist !!
Wenn du das abschaltest, dann wirst du sehen das das Verhalten genau so wie oben beschrieben ist...! Was zu erwarten war...