Ipsec vpn, fase 2 incapaz de aparecer


7

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.


Podemos ayudarlo más si publica la configuración de su enrutador.
Ron Trunk

@Ron actualicé con la configuración. Lo siento por eso.
TheEditor

Openswan está intentando construir un túnel para 1.1.1.1, pero no hay una dirección de interfaz correspondiente en su enrutador.
Ron Trunk

@Ron Sí, esa interfaz es fa0 / 1 (es dhcp pero el contrato de arrendamiento nunca cambia, es una conexión por cable).
TheEditor

Creo que entiendo lo que estoy haciendo mal. Puedo construir el túnel de 1.1.1.1 a 2.2.2.2. Es mi acl lo que me está matando. Una vez que construyo ese túnel, necesito asegurarme de que todo el tráfico del puerto 80 pase por ese túnel. Es eso correcto. Creo que estaba tratando de hacer que todo sucediera al mismo tiempo, lo que no funciona, que yo sepa. ¿Eso suena bien?
TheEditor

Respuestas:


1

Cambié la acl original de:

access-list 153 permit icmp 192.168.30.0 0.0.0.255 any

A:

access-list 153 permit icmp 192.168.30.0 0.0.0.255 2.2.2.2 0.0.0.0

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

access-list 153 permit 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

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".

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.