20
Cisco 2951 VPN Problem
Moin Moin,
ich habe folgendes Problem mit meinem Cisco:
Wir haben einen VPN-Tunnel via SVTI Config zu einem anderen Router (Bintec-elmeg) aufgebaut.
Der Tunnel steht auch siehe unten, ABER es geht keinerlei Traffic hindurch? Auf der Gegenseite wird auch alles normal ohne Fehler angezeigt aber wie gesagt keinerlei Traffic möglich?!
Für mich ist die SVTI-Konfig ziemliches Neuland und ich hoffe mir kann hier jemand den entscheidenden Tipp geben.
Hier erstmal die Router-Konfig:
Hier noch die ausgabe von sh interface tunnel0:
ich habe folgendes Problem mit meinem Cisco:
Wir haben einen VPN-Tunnel via SVTI Config zu einem anderen Router (Bintec-elmeg) aufgebaut.
Der Tunnel steht auch siehe unten, ABER es geht keinerlei Traffic hindurch? Auf der Gegenseite wird auch alles normal ohne Fehler angezeigt aber wie gesagt keinerlei Traffic möglich?!
Für mich ist die SVTI-Konfig ziemliches Neuland und ich hoffe mir kann hier jemand den entscheidenden Tipp geben.
Hier erstmal die Router-Konfig:
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname CISCO2951
!
boot-start-marker
boot-end-marker
!
!
enable secret 5 xyz
enable password 7 xyz
!
no aaa new-model
ethernet lmi ce
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
!
!
ip gratuitous-arps
!
!
!
!
!
!
!
!
!
!
!
ip dhcp binding cleanup interval 600
ip dhcp excluded-address 192.168.66.1
ip dhcp excluded-address 192.168.83.1
ip dhcp excluded-address 192.168.83.9
ip dhcp excluded-address 192.168.83.4
ip dhcp excluded-address 192.168.83.200
ip dhcp excluded-address 192.168.83.253
ip dhcp excluded-address 192.168.83.252
ip dhcp excluded-address 192.168.83.251
ip dhcp excluded-address 192.168.83.250
ip dhcp excluded-address 192.168.83.240
ip dhcp excluded-address 192.168.83.100
!
ip dhcp pool LAN-83.0
import all
network 192.168.83.0 255.255.255.0
default-router 192.168.83.254
dns-server 192.168.83.1
domain-name MK.com
!
!
!
ip domain name MK.com
ip inspect name myfw tcp
ip inspect name myfw udp
ip inspect name myfw sip
ip inspect name myfw rtsp
ip ddns update method dyndns
HTTP
add http://@members.dyndns.org/nic/update?system=dyndns&ho
interval maximum 0 0 15 0
!
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
voice-card 0
!
!
!
!
!
!
!
!
license udi pid CISCO2951/K9 sn FCZ15047E0Y
hw-module pvdm 0/0
!
!
!
username admin-mk password
!
redundancy
!
!
!
!
!
!
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 5
!
crypto isakmp policy 2
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco123 hostname Test.dyndns.org
crypto isakmp keepalive 10
!
crypto isakmp client configuration group VPNMK
key KEY
dns 192.168.83.1
domain media-kontor.com
pool VPNclients
save-password
max-users 5
banner ^C
Welcome to the VPN! ^C
crypto isakmp profile Chris
description Client-login for Chris
match identity group VPNMK
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 1
!
!
crypto ipsec transform-set iPhone esp-aes esp-sha-hmac
mode tunnel
crypto ipsec transform-set MKHof esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile MK
set security-association lifetime seconds 86400
set transform-set MKHof
set pfs group5
!
!
crypto ipsec profile iPhone
set transform-set iPhone
!
!
!
!
!
!
interface Tunnel0
ip unnumbered GigabitEthernet0/1
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 188.195.207.144
tunnel protection ipsec profile MK
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
ip ddns update hostname blbs1-media-kontor.dyndns.org
ip ddns update dyndns
ip address dhcp
ip access-group 111 in
ip nat outside
ip inspect myfw out
no ip virtual-reassembly in
no ip route-cache
duplex auto
speed auto
!
interface GigabitEthernet0/1
ip address 192.168.83.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
!
interface GigabitEthernet0/2
no ip address
shutdown
duplex auto
speed auto
!
interface Virtual-Template1 type tunnel
description Client-Login IPSEC
ip unnumbered GigabitEthernet0/1
no ip unreachables
ip flow ingress
ip nat inside
ip virtual-reassembly in
tunnel mode ipsec ipv4
tunnel protection ipsec profile iPhone
!
!
router ospf 1
!
ip local pool VPNclients 192.168.83.101 192.168.83.105
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
no ip nat service sip udp port 5060
ip nat inside source static tcp 192.168.83.9 22 interface GigabitEthernet0/0 22
ip nat inside source static tcp 192.168.83.9 50001 interface GigabitEthernet0/0 50001
ip nat inside source static tcp 192.168.83.9 50002 interface GigabitEthernet0/0 50002
ip nat inside source static tcp 192.168.83.9 50003 interface GigabitEthernet0/0 50003
ip nat inside source static tcp 192.168.83.9 50004 interface GigabitEthernet0/0 50004
ip nat inside source static tcp 192.168.83.9 50006 interface GigabitEthernet0/0 50006
ip nat inside source static tcp 192.168.83.9 50007 interface GigabitEthernet0/0 50007
ip nat inside source static tcp 192.168.83.9 50008 interface GigabitEthernet0/0 50008
ip nat inside source static tcp 192.168.83.9 50009 interface GigabitEthernet0/0 50009
ip nat inside source static tcp 192.168.83.9 21 interface GigabitEthernet0/0 21
ip nat inside source static tcp 192.168.83.9 50000 interface GigabitEthernet0/0 50000
ip nat inside source static tcp 192.168.83.200 554 interface GigabitEthernet0/0 554
ip nat inside source static udp 192.168.83.200 554 interface GigabitEthernet0/0 554
ip nat inside source static tcp 192.168.83.4 25 interface GigabitEthernet0/0 25
ip nat inside source static tcp 192.168.83.4 587 interface GigabitEthernet0/0 587
ip nat inside source static tcp 192.168.83.4 995 interface GigabitEthernet0/0 995
ip nat inside source static tcp 192.168.83.4 443 interface GigabitEthernet0/0 443
ip nat inside source static tcp 192.168.83.9 50005 interface GigabitEthernet0/0 50005
ip nat inside source route-map cable-nat interface GigabitEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 dhcp
!
!
nls resp-timeout 1
cpd cr-id 1
route-map cable-nat permit 10
match ip address 102
match interface GigabitEthernet0/0
!
!
access-list 102 permit ip 192.168.83.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
access-list 111 permit udp any eq ntp any
access-list 111 permit ip host 204.13.248.111 any log-input DynDNS_perm
access-list 111 permit udp any eq bootpc any
access-list 111 permit udp any eq bootps any
access-list 111 permit icmp any any echo
access-list 111 permit tcp any any eq ftp
access-list 111 permit udp any eq 5060 any
access-list 111 permit tcp any any eq 50000
access-list 111 permit tcp any any eq 50001
access-list 111 permit tcp any any eq 50002
access-list 111 permit tcp any any eq 50003
access-list 111 permit tcp any any eq 50004
access-list 111 permit tcp any any eq 50005
access-list 111 permit tcp any any eq 50006
access-list 111 permit tcp any any eq 50007
access-list 111 permit tcp any any eq 50008
access-list 111 permit tcp any any eq 50009
access-list 111 permit udp any eq 554 any
access-list 111 permit tcp any eq 554 any
access-list 111 permit tcp any any eq smtp
access-list 111 permit tcp any any eq 995
access-list 111 permit tcp any any eq 443
access-list 111 permit gre any any
!
control-plane
!
!
!
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
!
!
!
!
gatekeeper
shutdown
!
!
!
line con 0
line aux 0
line 2
no activation-character
no exec
transport preferred none
transport output lat pad telnet rlogin lapb-ta mop udptn v120 ssh
stopbits 1
line vty 0 4
access-class 23 in
privilege level 15
login local
transport input ssh
!
scheduler allocate 20000 1000
!
endHier noch die ausgabe von sh interface tunnel0:
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of GigabitEthernet0/1 (192.168.83.254)
MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 5/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel linestate evaluation up
Tunnel source 146.52.214.43 (GigabitEthernet0/0), destination 188.195.207.152
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with GigabitEthernet0/0
Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface <OK>
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1438 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "MK")
Last input never, output never, output hang never
Last clearing of "show interface" counters 05:40:16
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 2000 bits/sec, 2 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
43097 packets input, 6181699 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator Dani am 26.02.2017 um 18:17:48 Uhr
a) Password Hashes entfernt
b) Formatierung der Konfiguration hinzugefügt
b) Formatierung der Konfiguration hinzugefügt
Content-ID: 330604
Url: https://administrator.de/contentid/330604
Ausgedruckt am: 04.11.2024 um 22:11 Uhr
20 Kommentare
Neuester Kommentar
Die Frage die sich stellt ist warum du das mit einem Tunnel machst ? Das macht nur Sinn wenn du dynamische Routing Protokolle benutzt oder benutzen willst. Bei einer normalen statischen IPsec VPN Konfig ist das eigentlich überflüssiger Overhead.
Die Frage ist auch in heterogenen Umgebungen ob dein anderes Endgerät das versteht, was eher fraglich ist.
Besser ist da immer eine klassische, Standard basierte Site to Site IPsec Konfig, da die weniger proprietäre Gefahren birgt zu fremden VPN Systemen.
Das hiesige IPsec Tutorial hat eine kommentierte Cisco Beispielkonfig für sowas:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Da es da auch für 8 verschiedene IPsec Systeme rennt sollte das beim Bintec ebenfalls fehlerlos laufen.
Die Frage ist auch in heterogenen Umgebungen ob dein anderes Endgerät das versteht, was eher fraglich ist.
Besser ist da immer eine klassische, Standard basierte Site to Site IPsec Konfig, da die weniger proprietäre Gefahren birgt zu fremden VPN Systemen.
Das hiesige IPsec Tutorial hat eine kommentierte Cisco Beispielkonfig für sowas:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Da es da auch für 8 verschiedene IPsec Systeme rennt sollte das beim Bintec ebenfalls fehlerlos laufen.
OK.
Ich habe es nun nach dem Tutorial gemacht welches es hier im Forum gibt.
Leider gleiches Bild. Der Tunnel baut sich einwandfrei auf aber es geht kein Traffic durch.
Die Gegenseite meldet (also der Bintec) no Proposal choosen?! für Phase1 und Phase2. Allerdings zeigt er den Tunnel ebenfalls als hergestellt an?
Bin ratlos.
p.s. zu Cisco-Routern gehen mit diesem Router alle Tunnel bestens bis dato.
Hier nochmals die neue Crypto-map Konfig.:
Ich habe es nun nach dem Tutorial gemacht welches es hier im Forum gibt.
Leider gleiches Bild. Der Tunnel baut sich einwandfrei auf aber es geht kein Traffic durch.
Die Gegenseite meldet (also der Bintec) no Proposal choosen?! für Phase1 und Phase2. Allerdings zeigt er den Tunnel ebenfalls als hergestellt an?
Bin ratlos.
p.s. zu Cisco-Routern gehen mit diesem Router alle Tunnel bestens bis dato.
146.52.214.239 188.195.207.152 QM_IDLE 9007 ACTIVEHier nochmals die neue Crypto-map Konfig.:
crypto keyring MK
pre-shared-key hostname cohof.dyndns.org key
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
!
crypto isakmp policy 2
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp client configuration group VPNMK
key
dns 192.168.83.1
domain media-kontor.com
pool VPNclients
save-password
max-users 5
banner ^C
Welcome to the VPN of ! ^C
crypto isakmp profile Christoph
description Client-login for
match identity group VPNMK
client authentication list clientauth
isakmp authorization list groupauth
client configuration address respond
virtual-template 1
crypto isakmp profile DynAddress
description VPN for dyn.IP
keyring MK
match identity address 0.0.0.0
!
!
crypto ipsec transform-set iPhone esp-aes esp-sha-hmac
mode tunnel
crypto ipsec transform-set MK esp-aes esp-sha-hmac
mode tunnel
!
!
crypto ipsec profile iPhone
set transform-set iPhone
!
!
crypto dynamic-map dynmap 10
description Tunnel dyn.IP Bintec
set transform-set MK
set isakmp-profile DynAddress
match address VPNMK1
!
!
crypto map vpnmk 20 ipsec-isakmp dynamic dynmap
!
interface GigabitEthernet0/0
ip ddns update hostname
ip ddns update dyndns
ip address dhcp
ip access-group 111 in
ip nat outside
ip inspect myfw out
no ip virtual-reassembly in
no ip route-cache
duplex auto
speed auto
crypto map vpnmk
!
ip access-list extended VPNMK1
permit ip 192.168.83.0 0.0.0.255 192.168.36.0 0.0.0.255
!
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.36.0 0.0.0.255
access-list 102 permit ip 192.168.83.0 0.0.0.255 any
!no Proposal choosen?!
Das sieht nicht gut aus. Das bedeutet das die beiden Enden sich auf KEIN gemeinsames Schlüsselverfahren einigen konnten. Was wiederum bedeutet das die Verfahren an beiden Enden unterschiedlich konfiguriert sind.3DES und MD5 ist auch eher die Ausnahme. SHA ist da eher die Regel. Was verwendet denn der Bintec ??
Und WAS sagt der Cisco Debugger beim Verbindungsaufbau wenn du IPsec mal debuggst.
Im Cisco Debugger (debug isakmp usw.) kannst du haarklein sehen wo beim Verbindungsaufbau der Fehler liegt.
Genua dieser Output fehlt hier
Der Bintec verwendet AES128 und sha in beiden phasen.
Hier der fehlende Debug vom cisco:
Hier der fehlende Debug vom cisco:
*Feb 28 18:01:04.248: ISAKMP-PAK: (0):received packet from 188.195.207.152 dport 500 sport 869 Global (N) NEW SA
*Feb 28 18:01:04.248: ISAKMP: (0):Created a peer struct for 188.195.207.152, peer port 869
*Feb 28 18:01:04.248: ISAKMP: (0):New peer created peer = 0x17377940 peer_handle = 0x800011E2
*Feb 28 18:01:04.248: ISAKMP: (0):Locking peer struct 0x17377940, refcount 1 for crypto_isakmp_process_block
*Feb 28 18:01:04.248: ISAKMP: (0):local port 500, remote port 869
*Feb 28 18:01:04.248: ISAKMP: (0):insert sa successfully sa = 17263678
*Feb 28 18:01:04.248: ISAKMP: (0):processing SA payload. message ID = 0
*Feb 28 18:01:04.248: ISAKMP: (0):processing ID payload. message ID = 0
*Feb 28 18:01:04.248: ISAKMP: (0):ID payload
next-payload : 13
type : 2
*Feb 28 18:01:04.248: ISAKMP: (0): FQDN name : cohof.dyndns.org
*Feb 28 18:01:04.248: ISAKMP: (0): protocol : 0
port : 0
length : 24
*Feb 28 18:01:04.248: ISAKMP: (0):peer matches *none* of the profiles
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 160 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 176 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 114 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 157 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID is NAT-T v3
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 123 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID is NAT-T v2
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 164 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 221 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID seems Unity/DPD but major 215 mismatch
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID is XAUTH
*Feb 28 18:01:04.248: ISAKMP: (0):processing vendor id payload
*Feb 28 18:01:04.248: ISAKMP: (0):vendor ID is DPD
*Feb 28 18:01:04.248: ISAKMP: (0):Looking for a matching key for cohof.dyndns.org in default
*Feb 28 18:01:04.248: ISAKMP: (0):Looking for a matching key for cohof.dyndns.org in MK
*Feb 28 18:01:04.248: ISAKMP: (0):local preshared key found
*Feb 28 18:01:04.248: ISAKMP: (0):Scanning profiles for xauth ... Christoph
*Feb 28 18:01:04.248: ISAKMP: (0):Authentication by xauth preshared
*Feb 28 18:01:04.248: ISAKMP: (0):Checking ISAKMP transform 0 against priority 2 policy
*Feb 28 18:01:04.248: ISAKMP: (0): encryption AES-CBC
*Feb 28 18:01:04.248: ISAKMP: (0): keylength of 128
*Feb 28 18:01:04.248: ISAKMP: (0): hash SHA
*Feb 28 18:01:04.248: ISAKMP: (0): auth pre-share
*Feb 28 18:01:04.248: ISAKMP: (0): default group 2
*Feb 28 18:01:04.248: ISAKMP: (0): life type in seconds
*Feb 28 18:01:04.248: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Feb 28 18:01:04.248: ISAKMP-ERROR: (0):Encryption algorithm offered does not match policy!
*Feb 28 18:01:04.248: ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 0
*Feb 28 18:01:04.248: ISAKMP: (0):Checking ISAKMP transform 0 against priority 10 policy
*Feb 28 18:01:04.248: ISAKMP: (0): encryption AES-CBC
*Feb 28 18:01:04.248: ISAKMP: (0): keylength of 128
*Feb 28 18:01:04.248: ISAKMP: (0): hash SHA
*Feb 28 18:01:04.248: ISAKMP: (0): auth pre-share
*Feb 28 18:01:04.248: ISAKMP: (0): default group 2
*Feb 28 18:01:04.248: ISAKMP: (0): life type in seconds
*Feb 28 18:01:04.248: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Feb 28 18:01:04.248: ISAKMP: (0):atts are acceptable. Next payload is 0
*Feb 28 18:01:04.248: ISAKMP: (0):Acceptable atts:actual life: 86400
*Feb 28 18:01:04.248: ISAKMP: (0):Acceptable atts:life: 0
*Feb 28 18:01:04.248: ISAKMP: (0):Fill atts in sa vpi_length:4
*Feb 28 18:01:04.248: ISAKMP: (0):Fill atts in sa life_in_seconds:86400
*Feb 28 18:01:04.248: ISAKMP: (0):Returning Actual lifetime: 86400
*Feb 28 18:01:04.248: ISAKMP: (0):Started lifetime timer: 86400.
*Feb 28 18:01:04.248: ISAKMP: (0):processing KE payload. message ID = 0
*Feb 28 18:01:04.252: ISAKMP: (0):processing NONCE payload. message ID = 0
*Feb 28 18:01:04.252: ISAKMP: (0):Looking for a matching key for cohof.dyndns.org in default
*Feb 28 18:01:04.252: ISAKMP: (0):Looking for a matching key for cohof.dyndns.org in MK
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 160 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 176 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 114 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 157 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID is NAT-T v3
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 123 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID is NAT-T v2
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 164 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 221 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID seems Unity/DPD but major 215 mismatch
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID is XAUTH
*Feb 28 18:01:04.252: ISAKMP: (10960):processing vendor id payload
*Feb 28 18:01:04.252: ISAKMP: (10960):vendor ID is DPD
*Feb 28 18:01:04.252: ISAKMP: (10960):constructed NAT-T vendor-03 ID
*Feb 28 18:01:04.252: ISAKMP: (10960):SA is doing
*Feb 28 18:01:04.252: ISAKMP: (10960):pre-shared key authentication using id type ID_IPV4_ADDR
*Feb 28 18:01:04.252: ISAKMP: (10960):ID payload
next-payload : 10
type : 1
*Feb 28 18:01:04.252: ISAKMP: (10960): address : 146.52.214.239
*Feb 28 18:01:04.252: ISAKMP: (10960): protocol : 0
port : 0
length : 12
*Feb 28 18:01:04.252: ISAKMP: (10960):Total payload length: 12
*Feb 28 18:01:04.252: ISAKMP-PAK: (10960):sending packet to 188.195.207.152 my_port 500 peer_port 869 (R) AG_INIT_EXCH
*Feb 28 18:01:04.252: ISAKMP: (10960):Sending an IKE IPv4 Packet.
*Feb 28 18:01:04.252: ISAKMP: (10960):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
*Feb 28 18:01:04.252: ISAKMP: (10960):Old State = IKE_READY New State = IKE_R_AM2
*Feb 28 18:01:04.348: ISAKMP-PAK: (10960):received packet from 188.195.207.152 dport 4500 sport 44277 Global (R) AG_INIT_EXCH
*Feb 28 18:01:04.348: ISAKMP: (10960):processing HASH payload. message ID = 0
*Feb 28 18:01:04.348: ISAKMP: (10960):processing NOTIFY INITIAL_CONTACT protocol 1
spi 0, message ID = 0, sa = 0x17263678
*Feb 28 18:01:04.348: ISAKMP: (10960):received payload type 20
*Feb 28 18:01:04.348: ISAKMP: (10960):His hash no match - this node outside NAT
*Feb 28 18:01:04.348: ISAKMP: (10960):received payload type 20
*Feb 28 18:01:04.348: ISAKMP: (10960):His hash no match - this node outside NAT
*Feb 28 18:01:04.348: ISAKMP: (10960):SA authentication status:
authenticated
*Feb 28 18:01:04.348: ISAKMP: (10960):SA has been authenticated with 188.195.207.152
*Feb 28 18:01:04.348: ISAKMP: (10960):Detected port,floating to port = 44277
*Feb 28 18:01:04.352: ISAKMP: (10960):Trying to find existing peer 146.52.214.239/188.195.207.152/44277/
*Feb 28 18:01:04.352: ISAKMP: (10960):SA authentication status:
authenticated
*Feb 28 18:01:04.352: ISAKMP: (10960):Process initial contact,
bring down existing phase 1 and 2 SA's with local 146.52.214.239 remote 188.195.207.152 remote port 44277
*Feb 28 18:01:04.352: ISAKMP: (0):Trying to insert a peer 146.52.214.239/188.195.207.152/44277/,
*Feb 28 18:01:04.352: ISAKMP: (0): and inserted successfully 17377940.
*Feb 28 18:01:04.352: ISAKMP: (10960):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
*Feb 28 18:01:04.352: ISAKMP: (10960):Old State = IKE_R_AM2 New State = IKE_P1_COMPLETE
*Feb 28 18:01:04.352: ISAKMP: (10960):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
*Feb 28 18:01:04.352: ISAKMP: (10960):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
*Feb 28 18:01:14.252: ISAKMP-ERROR: (10960):no outgoing phase 1 packet to retransmit. QM_IDLE
Was sagt ein sh crypto isakmp sa ??
Da muss dann wenn der Tunnel steht sowas stehen:
So muss das aussehen wenn der Tunnel sauber aufgebaut ist !
Ist das bei dir der Fall ?
Da muss dann wenn der Tunnel steht sowas stehen:
CiscoRouter#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
123.11.137.190 123.11.14.170 QM_IDLE 2812 ACTIVE
IPv6 Crypto ISAKMP SA
CiscoRouter# Ist das bei dir der Fall ?
Ja genau so steht es bei mir da.
OK, dann steht der Tunnel, dann kann es nur noch eine ACL sein die da nicht spurt.
Dann die Frage ob der Bintec von einer dynamischen oder festen IP Adresse auf den Cisco kommt.
3 Parameter und ACLs musst du checken:
ip access-list extended vpnbintec
permit ip 172.16.7.0 0.0.0.255 192.168.188.0 0.0.0.255
Diese ACL bestimmt zu verschlüsselnden Traffic der beiden loakeln LANs Cisco Seite und Bintec Seite für VPN mit dem Bintec und referenziert auf die Crypto Map für den Bintec (Beispiel hier Einwahl von dyn. IP)
crypto dynamic-map dynmap 20
description Tunnel dyn.IP Bintec
set transform-set testset2
set isakmp-profile DynDialin
match address vpnbintec
!
Desweiteren MUSS der VPN Traffic zum Bintec vom NAT Prozess am Internet Port ausgenommen werden:
access-list 101 deny ip 172.16.7.0 0.0.0.255 192.168.188.0 0.0.0.255
!
ip nat inside source list 101 interface <InternetIF> overload
!
Passt das alles bei dir ?
Was sagt das Bintec Log auf der anderen Seite ??
Dann die Frage ob der Bintec von einer dynamischen oder festen IP Adresse auf den Cisco kommt.
3 Parameter und ACLs musst du checken:
ip access-list extended vpnbintec
permit ip 172.16.7.0 0.0.0.255 192.168.188.0 0.0.0.255
Diese ACL bestimmt zu verschlüsselnden Traffic der beiden loakeln LANs Cisco Seite und Bintec Seite für VPN mit dem Bintec und referenziert auf die Crypto Map für den Bintec (Beispiel hier Einwahl von dyn. IP)
crypto dynamic-map dynmap 20
description Tunnel dyn.IP Bintec
set transform-set testset2
set isakmp-profile DynDialin
match address vpnbintec
!
Desweiteren MUSS der VPN Traffic zum Bintec vom NAT Prozess am Internet Port ausgenommen werden:
access-list 101 deny ip 172.16.7.0 0.0.0.255 192.168.188.0 0.0.0.255
!
ip nat inside source list 101 interface <InternetIF> overload
!
Passt das alles bei dir ?
Was sagt das Bintec Log auf der anderen Seite ??
Ja im Cisco passt das alles bei mir. Es sieht aus als würde der Bintec nicht raffen das der Cisco mit Aes128 und sha läuft in Phase 1 und 2?! Obwohl es definitiv am Bintec so eingestellt ist in der Konfig.
Hier der Log vom Bintec RS353jw:
Hier der Log vom Bintec RS353jw:
17:22:45 INFO/IPSEC: Trigger Bundle -19 (Peer 1 Traffic -7) prot 6 192.168.36.81:63277->192.168.83.4:443
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -19 (I): created 192.168.36.81/32:0 < any > 192.168.83.0/24:0 rekeyed 0
17:22:45 DEBUG/IPSEC: P1: peer 1 (BLBS) sa 34 (I): Notify "No proposal chosen" from 146.52.62.195:4500 for protocol ESP spi[4]=134587AA
17:22:45 DEBUG/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -19 (I): No proposal chosen (size 12 bytes) from 146.52.62.195:4500 for protocol=3 spi(4)=134587AA
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -19 (I): deleted (Lifetime expired), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0
17:22:45 INFO/IPSEC: Destroy Bundle -19 (Peer 1 Traffic -7)
17:22:45 INFO/IPSEC: Trigger Bundle -20 (Peer 1 Traffic -7) prot 17 192.168.40.6:61775->192.168.83.3:53
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -20 (I): created 192.168.40.0/24:0 < any > 192.168.83.0/24:0 rekeyed 0
17:22:45 INFO/IPSEC: Trigger Bundle -21 (Peer 1 Traffic -8) prot 6 192.168.36.81:63273->192.168.83.4:443
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -21 (I): created 192.168.36.81/32:0 < any > 192.168.83.0/24:0 rekeyed 0
17:22:45 DEBUG/IPSEC: P1: peer 1 (BLBS) sa 34 (I): Notify "No proposal chosen" from 146.52.62.195:4500 for protocol ESP spi[4]=6756E720
17:22:45 DEBUG/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -20 (I): No proposal chosen (size 12 bytes) from 146.52.62.195:4500 for protocol=3 spi(4)=6756E720
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -20 (I): deleted (Lifetime expired), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0
17:22:45 INFO/IPSEC: Destroy Bundle -20 (Peer 1 Traffic -7)
17:22:45 DEBUG/IPSEC: P1: peer 1 (BLBS) sa 34 (I): Notify "No proposal chosen" from 146.52.62.195:4500 for protocol ESP spi[4]=1684E35C
17:22:45 DEBUG/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -21 (I): No proposal chosen (size 12 bytes) from 146.52.62.195:4500 for protocol=3 spi(4)=1684E35C
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -21 (I): deleted (Lifetime expired), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0
17:22:45 INFO/IPSEC: Destroy Bundle -21 (Peer 1 Traffic -8)
17:22:45 INFO/IPSEC: Trigger Bundle -22 (Peer 1 Traffic -7) prot 6 192.168.36.1:53131->192.168.83.99:3283
17:22:45 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -22 (I): created 192.168.36.0/24:0 < any > 192.168.83.0/24:0 rekeyed 0
17:22:46 DEBUG/IPSEC: P1: peer 1 (BLBS) sa 34 (I): Notify "No proposal chosen" from 146.52.62.195:4500 for protocol ESP spi[4]=23726A22
17:22:46 DEBUG/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -22 (I): No proposal chosen (size 12 bytes) from 146.52.62.195:4500 for protocol=3 spi(4)=23726A22
17:22:46 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -22 (I): deleted (Lifetime expired), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0
17:22:46 INFO/IPSEC: Destroy Bundle -22 (Peer 1 Traffic -7)
17:22:46 INFO/IPSEC: Trigger Bundle -23 (Peer 1 Traffic -7) prot 6 192.168.36.1:53132->192.168.83.101:3283
17:22:46 INFO/IPSEC: P2: peer 1 (BLBS) traf 0 bundle -23 (I): created 192.168.36.0/24:0 < any > 192.168.83.0/24:0 rekeyed 0
Wenn ich das ganze mit IP-Adressen mache dann Funktioniert es, was relativ unpraktisch ist bei zwei Dyn-ISPs an beiden Standorten.
Es hat also nur mit dem Dyn-Hostnamen zu tun denke ich ?
Es hat also nur mit dem Dyn-Hostnamen zu tun denke ich ?
Ich habe die Lösung gefunden um den Cisco erfolgreich mit dem Bintec zu verbinden und es läuft sogar sehr stabil.
Jetzt habe ich nur noch das Problem das wenn ich :
eingebe um von Extern auf unseren Exchange zu kommen, es zwar von Extern geht aber von keinerlei internem VPN mehr möglich ist?!
crypto isakmp profile DynAddress
description VPN for dyn.IP
keyring MK
match identity address 0.0.0.0
match identity host XYZ.org---------->Diese Zeile hatte ich vergessen die ganze Zeit über daher diese Fehler bei dyn-Names.Jetzt habe ich nur noch das Problem das wenn ich :
ip nat inside source static tcp 192.168.83.4 443 interface GigabitEthernet0/0 443eingebe um von Extern auf unseren Exchange zu kommen, es zwar von Extern geht aber von keinerlei internem VPN mehr möglich ist?!
Ich habe die Lösung gefunden um den Cisco erfolgreich mit dem Bintec zu verbinden
Stimmt ! Da war ich zu spät 
Mit der match identity kann man umschlaten ob IP Adressen oder Hostname verwendet werden. Das war sehr wahrscheinlich unterschiedlich.Aber klasse wenns nun klappt wie es soll.
von Extern geht aber von keinerlei internem VPN mehr möglich ist?!
Das liegt dann daran das du den Host nicht vom NAT ausgenommen hast.In die NAT Overload ACL muss dann rein:
!
access-list 101 deny ip host 192.168.83.4 any
access-list 101 deny ip 192.168.83.0 0.0.0.255 x.y.z.0 0.0.0.255
!
Wobei x.y.z.0 alle remoten VPN Netze sind. Ggf. mehr Einträge wenn du mehrere VPN Netze hast.
Danke aber dennoch für deine Hilfe!
Mir ist auch aufgefallen das sich gerade der Dyn-Name Tunnel verabschiedet hat mit der Meldung im Cisco 2951:
Der Tunnel ist auch nicht mehr im sh crypto iskamp sa zu sehen
Ist wohl doch besser einen Cisco anstelle von diesem Bintec einzusetzen.
Das mit dem Zugriff via Tunnel auf den Exchange will allerdings leider immer noch nicht!?
Kann man das irgendwie in einem Debug sehen wo er hängen bleibt wenn jemand aus dem z.b 36.0 Netz kommt?
ich habe es so gemacht jetzt:
Mir ist auch aufgefallen das sich gerade der Dyn-Name Tunnel verabschiedet hat mit der Meldung im Cisco 2951:
*Mar 4 17:47:39.779: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=146.52.62.195, prot=50, spi=0x3F873A53(1065826899), srcaddr=79.246.216.114, input interface=GigabitEthernet0/0 Der Tunnel ist auch nicht mehr im sh crypto iskamp sa zu sehen
Ist wohl doch besser einen Cisco anstelle von diesem Bintec einzusetzen.
Das mit dem Zugriff via Tunnel auf den Exchange will allerdings leider immer noch nicht!?
Kann man das irgendwie in einem Debug sehen wo er hängen bleibt wenn jemand aus dem z.b 36.0 Netz kommt?
ich habe es so gemacht jetzt:
access-list 102 deny ip host 192.168.83.4 any
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.55.0 0.0.0.255
access-list 102 deny ip 192.168.83.0 0.0.0.255 10.250.10.0 0.0.0.255
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.36.0 0.0.0.255
access-list 102 permit ip 192.168.83.0 0.0.0.255 any
Auf dem Exchange mal einen Wireshark starten und sehen mit welchen IPs die Endgeräte dort ankommen bzw. was der Exchange raussendet.
Vermutlich ein NAT Fehler oder interne Winblows Firewall.
Vermutlich ein NAT Fehler oder interne Winblows Firewall.
Die Trennung des Tunnels war schuld des Bintecs der hatte Firmwareprobleme ......laut Support ....
Also ich habe mal den Wireshark angeworfen und von einem VPN Rechner aus 10.250.10.21 versucht bei aktiver Freigabe auf den Exchange zu kommen als die OWA.
Die 192.168.83.9 natürlich vorher in die ACL aufgenommen ebenso wie die 83.4. Ich muss die 83.9 nehmen da die 4 Produktivbetrieb ist und zum testen etwas schlecht.
Das sieht dann im wireshark so aus:
Und im Firefox kommt ein Ladefehler.
Also ich habe mal den Wireshark angeworfen und von einem VPN Rechner aus 10.250.10.21 versucht bei aktiver Freigabe auf den Exchange zu kommen als die OWA.
Die 192.168.83.9 natürlich vorher in die ACL aufgenommen ebenso wie die 83.4. Ich muss die 83.9 nehmen da die 4 Produktivbetrieb ist und zum testen etwas schlecht.
Das sieht dann im wireshark so aus:
Und im Firefox kommt ein Ladefehler.
Der Trace ist ja eindeutig....
Die 10.250.10.21 versucht verzweifelt TCP Frames an die 192.168.83.9 zu senden aber es kommen niemals irgendwelche ACKs zurück.
Deshalb sendet sie immer und immer wieder Retransmissions und versucht den TCP Frame loszuwerden. So wie es eben sein soll bei TCP
Nun gilt es rauszufinden warum die 192.168.83.9 nicht mit ACKs antwortet...??
Fazit: Wireshark auf 192.168.83.9 anschmeissen und checken ob die TCP Retransmission Requests dort überhaupt ankommen
Die 10.250.10.21 versucht verzweifelt TCP Frames an die 192.168.83.9 zu senden aber es kommen niemals irgendwelche ACKs zurück.
Deshalb sendet sie immer und immer wieder Retransmissions und versucht den TCP Frame loszuwerden. So wie es eben sein soll bei TCP
Nun gilt es rauszufinden warum die 192.168.83.9 nicht mit ACKs antwortet...??
Fazit: Wireshark auf 192.168.83.9 anschmeissen und checken ob die TCP Retransmission Requests dort überhaupt ankommen
Sooo ich habe jetzt mal auf den Exchange geschaut und zusätzlich einen IIS auf nem win7 pro installiert zum testen.
Mir ist aufgefallen:
sobald ich den Eintrag:
setze hat der entsprechende Host kein WAN mehr?! Und ich komme weder von extern noch via VPN drauf?
Kann es sein das hier grundsätzlich was nicht passt mit dem NAT?
Mir ist aufgefallen:
sobald ich den Eintrag:
access-list 102 deny ip host 192.168.83.X anyKann es sein das hier grundsätzlich was nicht passt mit dem NAT?
und zusätzlich einen IIS auf nem win7 pro installiert zum testen.
Sinnfrei und mit Kanonen auf Spatzen !Viel sinnvoller wäre ein kleiner Webserver zum Testen den du vom USB Stick oder direkt aus dem Verzeichnis starten kannst wie der HFS Webserver:
http://www.rejetto.com/hfs/
Aber egal...warum einfach machen wenn es umständlich mit Riesenaufwand auch geht
Hier käme es jetzt auf das "x" an !!
Die Hosts .4, .9 und .200 musst du auf alle Fälle von der ACL 102 excluden, denn für die hast du ja ein dediziertes NAT konfiguriert. Da darfst du mit dem Overload NAT das nicht überbügeln.
Wenn es jetzt ein Host ist für den kein statische NAT definiert ist darfst du den nicht excluden, sonst kommt der nicht mehr ins Internet. Klar wenn du das machst macht der gar kein NAT und da 192.168er IP geht das dann ins Nirwana.
Oook.
Momentan sieht es mit dem Nat so aus:
Und die ACLs so:
Die Extended so:
So ist es doch richtig oder nicht? Nur so komme ich zwar von extern auf die 83.97 aber nicht via VPN und von der 83.97 nicht ins Internet?! stehe gerade auf dem Schlauch!?
Momentan sieht es mit dem Nat so aus:
no ip nat service sip udp port 5060
ip nat inside source static tcp 192.168.83.9 22 interface GigabitEthernet0/0 22
ip nat inside source static tcp 192.168.83.9 50001 interface GigabitEthernet0/0 50001
ip nat inside source static tcp 192.168.83.9 50002 interface GigabitEthernet0/0 50002
ip nat inside source static tcp 192.168.83.9 50003 interface GigabitEthernet0/0 50003
ip nat inside source static tcp 192.168.83.9 50004 interface GigabitEthernet0/0 50004
ip nat inside source static tcp 192.168.83.9 50006 interface GigabitEthernet0/0 50006
ip nat inside source static tcp 192.168.83.9 50007 interface GigabitEthernet0/0 50007
ip nat inside source static tcp 192.168.83.9 50008 interface GigabitEthernet0/0 50008
ip nat inside source static tcp 192.168.83.9 50009 interface GigabitEthernet0/0 50009
ip nat inside source static tcp 192.168.83.9 21 interface GigabitEthernet0/0 21
ip nat inside source static tcp 192.168.83.9 50000 interface GigabitEthernet0/0 50000
ip nat inside source static tcp 192.168.83.200 554 interface GigabitEthernet0/0 554
ip nat inside source static udp 192.168.83.200 554 interface GigabitEthernet0/0 554
ip nat inside source static tcp 192.168.83.4 25 interface GigabitEthernet0/0 25
ip nat inside source static tcp 192.168.83.4 587 interface GigabitEthernet0/0 587
ip nat inside source static tcp 192.168.83.4 995 interface GigabitEthernet0/0 995
ip nat inside source static tcp 192.168.83.9 50005 interface GigabitEthernet0/0 50005
ip nat inside source static tcp 192.168.83.97 443 interface GigabitEthernet0/0 443
ip nat inside source route-map cable-nat interface GigabitEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 dhcpUnd die ACLs so:
access-list 102 deny ip host 192.168.83.97 any
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.55.0 0.0.0.255
access-list 102 deny ip 192.168.83.0 0.0.0.255 10.250.10.0 0.0.0.255
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 102 deny ip 192.168.83.0 0.0.0.255 192.168.36.0 0.0.0.255
access-list 102 permit ip 192.168.83.0 0.0.0.255 any
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq non500-isakmp
access-list 111 permit esp any any
access-list 111 permit udp any eq ntp any
access-list 111 permit ip host 204.13.248.111 any log-input DynDNS_perm
access-list 111 permit udp any eq bootpc any
access-list 111 permit udp any eq bootps any
access-list 111 permit icmp any any echo
access-list 111 permit tcp any any eq ftp
access-list 111 permit udp any eq 5060 any
access-list 111 permit tcp any any eq 50000
access-list 111 permit tcp any any eq 50001
access-list 111 permit tcp any any eq 50002
access-list 111 permit tcp any any eq 50003
access-list 111 permit tcp any any eq 50004
access-list 111 permit tcp any any eq 50005
access-list 111 permit tcp any any eq 50006
access-list 111 permit tcp any any eq 50007
access-list 111 permit tcp any any eq 50008
access-list 111 permit tcp any any eq 50009
access-list 111 permit udp any eq 554 any
access-list 111 permit tcp any eq 554 any
access-list 111 permit tcp any any eq smtp
access-list 111 permit tcp any any eq 995
access-list 111 permit tcp any any eq 443
access-list 111 permit gre any anyDie Extended so:
ip access-list extended VPNMK1
permit ip 192.168.83.0 0.0.0.255 192.168.36.0 0.0.0.255
permit ip 192.168.83.0 0.0.0.255 192.168.40.0 0.0.0.255
ip access-list extended VPNMK2
permit ip 192.168.83.0 0.0.0.255 10.250.10.0 0.0.0.255
ip access-list extended VPNMK3
permit ip 192.168.83.0 0.0.0.255 192.168.55.0 0.0.0.255So ist es doch richtig oder nicht? Nur so komme ich zwar von extern auf die 83.97 aber nicht via VPN und von der 83.97 nicht ins Internet?! stehe gerade auf dem Schlauch!?
Keiner eine Idee?
Nur so komme ich zwar von extern auf die 83.97 aber nicht via VPN und von der 83.97 nicht
Das kann nicht ganz richtig sein !Die .83.97 ist durch die ACL 102 richtigerweise komplett vom NAT aus genommen, da es ja ein 1:1 NAT Statement gibt. Diese gilt aber nur für den Port TCP 443. Die .83.97 kommt also nur mit Port TCP 443 ins Internet. Alle anderen Ports werden durch die ACL 102 NICHT mehr geNATet. Soll sie mit weiteren Ports ins Internet, dann musst du diese logischerweise auch in deiner statischen NAT Definition eintragen, andernfalls ist es doch logisch das das nicht klappt.
Vermutlich liegt hier auch der Fehler das der VPN Zugang nicht möglich ist.
Diese NAT Fehler hast du übrigens auch mit den anderen NAT Sattements gemacht der Hosts. .4, .9 und .200 die allesamt auch statische 1:1 NAT Einträge haben und die du trotzdem nochmals mit einem PAT (Overload) Statement übermangelst. Auch das ist ein Konfig Fehler, denn auch diese Hosts müssten logischerweise vom PAT Translation ausgenommen sein über die ACL 102.
Du kannst ja logischerweise entweder nur 1:1 NAT oder PAT machen aber niemals beides zusammen. Das resultiert vermutlich alles in deinem Fehlerbild !
Dieses Cisco Dokument erklärt dein Szenario und das excluden der Encryption mit Route Maps realtiv genau:
http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiatio ...
