Cisco VPN Einwahl ins Firmennetz

Ich möchte einen Außendienstmitarbeiter Zugriff auf einen Webserver im internen Netzwerk der Firma verschaffen. Einwahl über Cisco VPN Client direkt auf den Cisco VPN Router. Das ganze soll ein Projekt sein.

Hallo,

mein Ziel ist es, dass sich ein mobiler Benutzer über das Internet (z.B. über UMTS Stick im Laptop) per Cisco VPN Client auf den Router einwählen kann und dann Zugriff zum internen LAN hat. Das Surfen im Internet soll aber für diesen mobilen Benutzer weiter möglich sein. Dies soll ein Projekt werden.

Die Einwahl funktioniert. Der mobile Benutzer surft auch durch den VPN Tunnel über den Firmen Router dann im Internet (hat also als externe IP die WAN IP vom Firmen Router). So wie es sein soll. Aber der mobile Nutzer kann leider nicht auf den internen Webserver zugreifen.

Hier mal ein Bild des Netzwerkaufbaus:

WAN Router: DSL Einwahl mit DynDNS Adresse
LAN Router: 192.168.2.1/24
Webserver: 192.168.2.2/24
Mobiler Laptop: 192.168.2.151/24

Wo liegt der Fehler? Normal sind ja alle Geräte im gleichen Netz, wodurch ein Zugriff ja möglich sein sollte.

Vielen Dank schonmal an Euch alle.

Mfg

Hier mal die Konfiguration von dem Cisco 831 Router:

!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname VPN-DSL-Router
!
boot-start-marker
boot-end-marker
!
enable secret 5 XXXXXXXXXXXXXXXXXXXXXXXXX
!
aaa new-model
!
!
aaa authentication login userauthen local
aaa authorization network groupauthor local 
!
aaa session-id common
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.2.1 192.168.2.10
!
ip dhcp pool LAN
   network 192.168.2.0 255.255.255.0
   default-router 192.168.2.1 
   dns-server 194.25.2.129 
!
!
ip cef
ip ddns update method DynDNS
 HTTP
  add http://xxx:xxx@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a>
 interval maximum 0 1 0 0
!
vpdn enable
!
!
!
!
username CRWS_Santhosh privilege 15 password 7 XXXXXXXXXXXXXXXXXXXXXXXXXX
username user password 7 XXXXXXXXXXXXXXXXXXXXXXXX
!
! 
!
crypto isakmp policy 3
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp client configuration group vpnclient
 key XXXXXXXXXXXXXXXXXXXX
 dns 194.25.2.129
 pool ippool
!
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac 
!
crypto dynamic-map dynmap 10
 set transform-set myset 
 reverse-route
!
!
crypto map clientmap client authentication list userauthen
crypto map clientmap isakmp authorization list groupauthor
crypto map clientmap client configuration address respond
crypto map clientmap 10 ipsec-isakmp dynamic dynmap 
!
!
!
interface Loopback0
 ip address 10.11.0.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface Ethernet0
 description LAN-Schnittstelle
 ip address 192.168.2.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface Ethernet1
 description WAN-Schnittstelle
 no ip address
 ip virtual-reassembly
 duplex auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 no keepalive
!
interface Ethernet2
 no ip address
 shutdown
!
interface FastEthernet1
 duplex auto
 speed auto
!
interface FastEthernet2
 duplex auto
 speed auto
!
interface FastEthernet3
 duplex auto
 speed auto
!
interface FastEthernet4
 duplex auto
 speed auto
!
interface Dialer0
 description Internet
 ip ddns update hostname XXXXXXXXXXXXXXXX
 ip ddns update DynDNS
 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1452
 ip policy route-map VPN-Client
 dialer pool 1
 dialer-group 1
 ppp authentication pap callin
 ppp pap sent-username XXXXXXXXXXXXXXXXXXXXXXX@t-online.de password 7 XXXXXXXXXXXXXXXXXXX
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept
 crypto map clientmap
!
ip local pool ippool 192.168.2.150 192.168.2.170
ip route 0.0.0.0 0.0.0.0 Dialer0
ip http server
no ip http secure-server
!
ip nat inside source list 101 interface Dialer0 overload
!
access-list 101 permit ip any any
access-list 144 permit ip 192.168.2.0 0.0.0.255 any
dialer-list 1 protocol ip permit
route-map VPN-Client permit 10
 match ip address 144
 set interface Loopback0
!
!
control-plane
!
!
line con 0
 password 7 05080F1C2243
 no modem enable
line aux 0
 password 7 05080F1C2243
line vty 0 4
 exec-timeout 120 0
 password 7 05080F1C2243
 length 0
!
scheduler max-task-time 5000
end

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

Content-ID: 146473

Url: https://administrator.de/forum/cisco-vpn-einwahl-ins-firmennetz-146473.html

Ausgedruckt am: 28.04.2025 um 15:04 Uhr

13 Kommentare

Neuester Kommentar

Moin,
das wird wohl daran liegen, dass du den gleichen IP-Bereich für das lokalen LAN als auch für VPN benutzen. Ändere den Bereich für VPN (ip local pool ippool ) ab und der Zugriff wird klappen.

Grüße,
Dani

Oder benutze "ip unnumbered eth 0" das funktioniert auch. Kannst du hier am Beispiel einer PPTP Client VPN Einwahl auf dem Cisco sehen:
Konfiguration Cisco 1841 Router
In der Tat ist aber die falsche IP Adressierung das grundlegende Problem. Das du dem Webserver den C831 als Gateway eingetragen haben solltest, sollte ebenfalls klar sein. Bedenke auch ggf. die lokale Firewall auf dem internen Webserver anzupassen, sollte die nur das lokale IP Netz zum Zugriff zulassen !!
Wenn dein VPN Client eine andere IP benutzt musst du auch dieses IP Netz logischerweise im Zugriff in der lokalen FW freischalten !!
Ansonsten findest du hier:
http://www.shrew.net/support/wiki/HowtoCiscoAsa
und hier
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
noch IPsec Beispiele für Cisco für den freien Shrew VPN Client.

Hallo,

vielen Dank schonmal.

Ich habe jetzt also ip local pool ippool 192.168.3.10 192.168.3.20 genommen. Dann kann ich bei dem mobilen Benutzer nicht mehr im Inetrnet surfen. Also habe ich noch in der ACL 144 das 192.168.3.0 Netz genommen. Somit funktioniert das surfen wieder.

Ich kann aber immernoch nicht auf den Webserver zugreifen... Ein Ping (192.168.2.2) funktioniert jetzt... Diesen habe ich 20 mal wiederholen müssen, bis eine Antwort kam und nicht mehr Zeitüberschreitung der Anforderung. Die 192.168.2.1 kann ich immernoch nicht pingen...

Firewall ist noch nicht vorhanden. Somit sollte man das ausschließen können. Die IP Einstellungen vom Webserver sind in Ordnung. Das Gate ist die 192.168.2.1.

Liegt das Problem vllt. an dem DSL 1000 Anschluss? Es ist ja nur eine Testumgebung, aber dennnoch sollte es funktionieren.

Das "ip unnumbered eth 0" müsste ich bei dem Dialer0 anwenden, wenn ich es anstatt des IP Pools nehmen will?

Vielen Dank.

Hallo,

ohne dass ich jetzt etwas geändert habe, kann ich nun die 192.168.2.2 nicht mehr pingen (Zeitüberschreitung der Anforderung), aber dafür die 192.168.2.1.

Mfg

Ist die .2.2 dein interner Webserver ???
Wenn ja ist dort ICMP in der Firewall erlaubt ? (Haken in den erweiterten Eigenschaften der FW bei "Auf Echo Pakete antworten" ?
Am 1000er DSL liegt es defacto nicht, denn diese Einwahl funktioniert auch mit ISDN Geschwindigkeit bei 64 kBit/s einwandfrei und problemlos !
Ansonsten einfach immer mal den Debugger (debup ip icmp, debug vpn etc...) einschalten. Der sagt dann meistens sofort wo es kneift !!
Zum schluss nie vergessen den Debugger mit undebug all wieder auszuschalten !
Wenn du per Telnet/SSH auf dem Router bist term mon nicht vergessen sonst siehst du die Debug Konsol Meldungen nicht bzw. nur mit "show logg" im Syslog !
service timestamps debug datetime localtime
service timestamps log datetime localtime
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
ntp server de.pool.ntp.org
...ist noch ganz sinnvoll damit du immer den genauen zeitlichen Verlauf der Meldungen sehen kannst !

Hallo,

ja die 2.2 ist der Webserver. Dort ist keine Firewall an. Ich konnte ja die 2.2 schonmal pingen... Dafür die 2.1 dann nicht.

*Mar 4 03:42:42: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.3.12
*Mar 4 03:42:43: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.3.12
*Mar 4 03:42:44: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.3.12
*Mar 4 03:42:45: ICMP: echo reply sent, src 192.168.2.1, dst 192.168.3.12

Bei dem Ping auf die 192.168.2.2 kommt keine Debug Meldung.

Bei der VPN Einwahl kommt auch keine Debug Meldung.

Das komische ist ja, als ich die 2.2 pingen konnte, dann konnte ich aber nicht per HTTP auf den Webserver zugreifen (über den Browser). Ich habe ja aber auch keine ACLs auf dem Router, die etwas blocken könnten... Ich bin ziemlich ratlos. Im Browser steht immer nur "Verbinden mit 192.168.2.2"...

Mfg

//

jetzt kann ich gerade wieder die 2.2 pingen, aber dennnoch nicht im Browser auf die 2.2 zugreifen. Die 2.1 lässt sich jetzt gerade nicht mehr pingen. Sehr komisch.

Blöde Frage: Hast du deine ACL-List auch angepasst?!

access-list 144 permit ip 192.168.2.0 0.0.0.255 any

Grüße,
Dani

Hallo,

ich habe das 192.168.3.0 Quellnetz noch in die 144er ACL hinzugefügt. Das Surfen im Internet durch den VPN Tunnel über den Firmen Router funktioniert ja. Nur der Zugriff auf das Netz hinter dem Router ist nicht korrekt. Denn es kann ja nicht sein, dass man eine IP mal pingen kann und dann wieder nicht.

Mfg

Wenn der Cisco VPN Client aktiv ist was sagt ein ipconfig oder ipconfig -all ??
Welche Client IP bekommst du vom Cisco Client ??
Ala..

Ethernetadapter Cisco-VPN:

Verbindungsspezifisches DNS-Suffix: xorking.com
IP-Adresse. . . . . . . . . . . . : 172.16.22.1
Subnetzmaske. . . . . . . . . . . : 255.255.254.0
Standardgateway . . . . . . . . . : 172.16.22.254

C:\>

Hallo,

Ethernetadapter LAN-Verbindung 2:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Cisco Systems VPN Adapter
Physikalische Adresse . . . . . . : 00-05-9A-3C-78-00
DHCP aktiviert. . . . . . . . . . : Nein
IP-Adresse. . . . . . . . . . . . : 192.168.3.150
Subnetzmaske. . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.3.1
DNS-Server. . . . . . . . . . . . : 194.25.2.129

Das sollte alles stimmen.

Die 192.168.3.1 kann ich auch nicht anpingen, obwohl ich ja über sie in das 2er Netz gehe...

Ich habe mal den Cisco 831 gegen einen Cisco 836 getauscht. Konfiguration ist die gleiche. Weiterhin kein Zugriff auf den Webserver und das Problem mit dem Ping.

Vielen Dank.

Also ich habe gerade nochmal eine Netzwerkfreigabe auf dem Webserver erstellt. Auch diese kann ich nicht über den mobilen Laptop mit VPN Zugriff erreichen. Die Rechte sind richtig gesetzt.

Mfg

Äääähhh, das ist ja auch wohl klar. Wie soll denn einen andere HW eine Konfig Fehler korrigieren können ?? Das ist doch Unsinn.
OK weiter beim Problem....
Deine ACL 144 musst du logischerweise korrigieren:
access-list 144 permit ip 192.168.3.0 0.0.0.255 any
Das .2.0er Netz darf hier nicht mehr stehen !! Denn die PBR gilt ja nur für die VPN Clients die jetzt in einem eigenen Netz sind !

Nicht ganz klar ist was du mit der (eigentlich überflüssigen) PBR Routemap für die VPN Clients beabsichtigst ?? Auch das widerholte NAT am Loopback ist mehr als unsinnig aus normaler Sichtweise ohne dein Umfeld zu kennen.
Was bitte soll der tiefere Sinn sein die VPN Clients über das Loopback Interface zu routen mit der PBR ??

Nochwas: kannst du die 192.168.2.1 anpingen ??

Hallo,

ich hatte das 192.168.2.0 Netz natürlich aus der ACL gelöscht.

Wenn ich von dem mobilen Rechner auf den Webserver zugreifen will, dann sehe ich auch anhand der matches der ACL 144, dass da was passiert. Aber es geht eben nicht...

Wegen dem Loopback: Ich habe gelesen, dass ich das so konfigurieren muss, weil ich ja den Internet Traffic des VPN Clients über den VPN Tunnel leiten will, sodass er über den Cisco 831 läuft und nicht direkt über die UMTS Karte seinen Weg in das Internet findet.

Meine Testumgebung sieht genauso aus, wie oben auf dem Bild abgebildet.

Ich kann die 192.168.2.1 manchmal pingen. Wenn dies gerade möglich ist, dann funktioniert der Ping auf die 192.168.2.2 nicht mehr. Das ist genau das, was ich nicht verstehe. Wenn ich mich aber am Switch des LANs befinde, dann kann ich natürlich das komplette 192.168.2.0 Netz pingen.

Was könnte ich denn an der Konfiguration genau ändern/weglassen, weil Du sagst, dass es unnötig ist mit der PBR Routermap.

Vielen Dank.

Mfg

Hallo,

ich habe mich nach diesem Beispiel gerichtet:

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_configur ...

ich erhalte nun auch:

*Mar 1 03:36:06.975: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet ha
s invalid spi for
destaddr=84.184.xxx.xxx, prot=50, spi=0x94040000(2483290112), srcaddr=91.
40.117.126

Vielen Dank.

Mfg

Frage Netzwerke Router, Routing

Mehr von xorking

OpenVPN und CiscoVPN verbindenxorking - 3 Kommentare

Heiß diskutiert