ipsec falha de fase 1 do IKE

2

Eu tenho um gateway sem fio que suporta IPSec de site para site. Eu configurei o openswan no Ubuntu Server 12.04 (lado esquerdo do túnel) com o seguinte /etc/ipsec.conf :

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey

conn net-to-net
    authby=secret
    left=192.168.0.11
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    auto=add

Eu configurei o gateway sem fio (lado direito do túnel) da mesma forma. Estou usando o modo IKE no modo principal (modo não agressivo) IKE, mas parece que ele falha antes de chegar ao estágio 2. Alguma idéia do motivo?

Aqui está a saída de tcpdump :

# tcpdump -vv -i eth0 udp port 500 or udp port 4500
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:11:26.042928 IP (tos 0x0, ttl 235, id 39655, offset 0, flags [none], proto UDP (17), length 196)
    74.198.87.62.44248 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0100)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
00:11:26.044511 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 172)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x6361 -> 0x70a3!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0100)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (vid: len=12)
    (vid: len=16)
    (vid: len=16)
00:11:26.683227 IP (tos 0x0, ttl 235, id 39656, offset 0, flags [none], proto UDP (17), length 312)
    74.198.87.62.44248 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 I ident:
    (ke: key len=192)
    (nonce: n len=16  data=(7d88f683ff25b40ac37b...00000014471b8027b9d2d76240f4329456eb22db))
    (pay20)
    (pay20)
00:11:26.688968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)
00:11:36.704351 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)
00:11:56.165304 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 312)
    192.168.0.11.isakmp > 74.198.87.62.44248: [bad udp cksum 0x63ed -> 0x4fc7!] isakmp 1.0 msgid 00000000 cookie 7d88f683ff25b40a->6569330ef208fe4d: phase 1 R ident:
    (ke: key len=192)
    (nonce: n len=16  data=(aaeeb24d4daa1e07f949...00000014637d4a0b75f97e0f771664cd9ac0d818))
    (pay20)
    (pay20)

O lado direito do túnel está tentando iniciar o túnel usando a fase 1 do Modo Principal IKE. O Modo Principal envolve três trocas de 2 vias. O OpenSWAN responde às primeiras 2 trocas, mas por alguma razão o lado direito não inicia a terceira troca. O que poderia falhar nesse ponto do processo?

    
por Isaac Sutherland 13.07.2012 / 05:51

0 respostas