Tenho certeza de que sei a resposta para isso, mas não sei como implementá-lo.
Tentando configurar um ipsec vpn de um Cisco 2811 para uma caixa Linux executando o openswan. Até agora, posso começar a fase 1, mas a fase 2 está tendo um problema. É 100% um problema de configuração.
O que estou tentando fazer é empurrar a web e algum outro tráfego para fora da VPN, usando a conexão com a Internet do outro lado como porta de entrada para a rede. Estou recebendo erros de criptografia. Aqui está a configuração. 1.1.1.1 sendo o Cisco. O endereço 2.2.2.2 é o servidor linux que possui apenas um único nic.
192.168.xx / 24 ----- 1.1.1.1 - INTERNET 2.2.2.2 ---- >>> Internet
Entendo por que ele não pode formar o túnel da fase 2, não pode concordar com o mapa. Mas não tenho idéia de qual deve ser o mapa nesse caso.
Eu tenho testado com apenas ICMP por enquanto.
Excluí o ICMP do NAT:
ip access-list extended NAT
deny icmp 192.168.30.0 0.0.0.255 any
Então o "tráfego interessante" para o vpn é:
access-list 153 permit icmp 192.168.30.0 0.0.0.255 any
No lado openswan eu estou usando:
left=2.2.2.2
right=1.1.1.1
rightsubnet=192.168.30.3/24
Bem, o cisco imediatamente começa a jogar fora:
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)
Sei o que quero que faça, mas não sei como configurá-lo. Se isso fosse apenas uma simples sub-rede interna para sub-rede interna vpn, não há problema.
Qualquer direção aqui seria realmente útil.
Configuração do roteador:
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
!
UPDATE: Corrigida a ACL: lista de acesso 153 permite IP 192.168.30.0 0.0.0.255 host 2.2.2.2 e o túnel é ativado e eu posso executar o ping conforme o esperado.
Tentando obter tráfego da Web agora. O roteamento de políticas não está funcionando. Eu adicionei
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
Posso ver a correspondência do mapa de rotas no tráfego www, mas não está sendo passada pelo túnel.
Respostas:
Alterei o ACL original de:
Para:
Assim que isso foi alterado, os mapas correspondiam nas duas extremidades e os túneis surgiram. Desde então, adicionei um eth0: 0 no lado openswan com um endereço no intervalo 192.168.10.0 alterando o acl para
O túnel surgiu, isso apenas facilitou um pouco as coisas, agora se segue o modelo "lan-to-lan" padrão.
fonte