Estoy bastante seguro de que sé la respuesta a esto, pero no sé cómo implementarlo.
Intentando configurar un ipsec vpn desde un Cisco 2811 a una caja de Linux que ejecuta openswan. Hasta ahora puedo obtener la fase 1, pero la fase 2 tiene un problema. Es 100% un problema de configuración.
Lo que estoy tratando de hacer es empujar la web y algún otro tráfico fuera de la VPN usando la conexión a Internet en el otro extremo como su puerta de entrada a la red. Estoy recibiendo errores de cryptomap. Aquí está la configuración. 1.1.1.1 siendo el Cisco. La dirección 2.2.2.2 es el servidor Linux que solo tiene un solo nic.
192.168.xx / 24 ----- 1.1.1.1 - INTERNET 2.2.2.2 ---- >>> Internet
Entiendo por qué no puede formar el túnel de fase 2, no puede estar de acuerdo en el mapa. Pero no tengo idea de cuál debería ser el mapa en este caso.
Lo he estado probando solo con ICMP por ahora.
Excluí ICMP de NAT:
ip access-list extended NAT
deny icmp 192.168.30.0 0.0.0.255 any
Entonces el "tráfico interesante" para el vpn es:
access-list 153 permit icmp 192.168.30.0 0.0.0.255 any
En el lado de openswan estoy usando:
left=2.2.2.2
right=1.1.1.1
rightsubnet=192.168.30.3/24
Bueno, el Cisco inmediatamente comienza a tirar:
2d11h: map_db_find_best did not find matching map
2d11h: IPSEC(validate_transform_proposal): no IPSEC cryptomap exists for local address 1.1.1.1
2d11h: ISAKMP:(0:26:SW:1): IPSec policy invalidated proposal
2d11h: ISAKMP:(0:26:SW:1): phase 2 SA policy not acceptable! (local 1.1.1.1 remote 2.2.2.2)
Sé lo que quiero que haga, pero no sé cómo configurarlo. Si esto fuera solo una simple subred interna a subred interna vpn no habría problema.
Cualquier dirección aquí sería realmente útil.
Configuración del enrutador:
version 12.4
service timestamps debug uptime
service timestamps log datetime
service password-encryption
!
hostname Hex-2811
!
boot-start-marker
boot system flash c2800nm-advsecurityk9-mz.124-24.T5.bin
boot-end-marker
!
no logging buffered
aaa new-model
!
!
!
aaa session-id common
clock timezone EST -5
clock summer-time EDT recurring
no ip source-route
!
!
ip cef
!
!
no ip bootp server
ip domain name hexhome.int
ip name-server 192.168.30.8
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
ipv6 unicast-routing
crypto isakmp policy 1
encr aes 192
authentication pre-share
group 5
lifetime 43200
crypto isakmp key ********** address 2.2.2.2
!
!
crypto ipsec transform-set IOFSET2 esp-aes 192 esp-sha-hmac
!
!
crypto map IOFVPN 1 ipsec-isakmp
description Isle Of Man
set peer 2.2.2.2
set transform-set IOFSET2
match address 153
!
!
!
!
interface FastEthernet0/0
description Internal 192 Network
ip address 192.168.30.1 255.255.255.0
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ip route-cache flow
duplex full
speed 100
!
interface FastEthernet0/1
ip address dhcp
ip access-group 112 in
no ip redirects
no ip unreachables
ip accounting access-violations
ip nbar protocol-discovery
ip nat outside
ip virtual-reassembly
no ip route-cache cef
no ip mroute-cache
duplex auto
speed auto
no cdp enable
no mop enabled
crypto map IOFVPN
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 174.59.28.1
!
ip flow-export source FastEthernet0/0
ip flow-export version 5
ip flow-export destination 192.168.30.45 3001
no ip http server
ip http access-class 23
ip http authentication local
no ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source route-map POLICY-NAT interface FastEthernet0/1 overload
ip access-list extended NAT
deny icmp 192.168.30.0 0.0.0.255 any
permit ip any any
access-list 153 permit icmp 192.168.30.0 0.0.0.255 any
route-map POLICY-NAT permit 10
match ip address NAT
!
ACTUALIZACIÓN: Se corrigió la lista ACL: access-list 153 permit ip 192.168.30.0 0.0.0.255 host 2.2.2.2 y el túnel viene hacia arriba y puedo hacer ping como se esperaba.
Intentando obtener tráfico web ahora. El enrutamiento de políticas no funciona. yo añadí
route-map VPN_WEB permit 1
match ip address 155
set ip next-hop 2.2.2.2
access-list 155 permit tcp any any eq www
interface FastEthernet0/1
ip address dhcp
ip access-group 112 in
no ip redirects
no ip unreachables
ip accounting access-violations
ip nbar protocol-discovery
ip nat outside
ip virtual-reassembly
no ip route-cache cef
ip policy route-map VPN_WEB
no ip mroute-cache
duplex auto
speed auto
no cdp enable
no mop enabled
crypto map IOFVPN
Puedo ver la coincidencia del mapa de ruta en el tráfico de www pero no se pasa por el túnel.
Respuestas:
Cambié la acl original de:
A:
Tan pronto como se cambió, los mapas coincidieron en ambos extremos y aparecieron los túneles. Desde entonces he agregado un eth0: 0 en el lado de openswan con una dirección en el rango 192.168.10.0 cambiando el acl a
El túnel subió, esto solo hizo algunas cosas un poco más fáciles, ahora si sigue el modelo estándar "lan-to-lan".
fuente