A troca do Modo Agressivo da Fase I do IKE não é concluída

3

Configurei um gateway IP 3G para conectar usando o Modo Agressivo IKE Phase 1 com PSK à minha instalação do openswan no servidor Ubuntu 12.04. Eu configurei o openswan da seguinte forma:

/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
    [email protected]
    leftsubnet=10.1.0.0/16
    leftsourceip=10.1.0.1
    right=%any
    [email protected]
    rightsubnet=192.168.127.0/24
    rightsourceip=192.168.127.254
    aggrmode=yes
    ike=aes128-md5;modp1536
    auto=add

/etc/ipsec.secrets:

@left.paxcoda.com @right.paxcoda.com: PSK "testpassword"

Note que tanto a esquerda quanto a direita são NAT, com IPs públicos dinâmicos. O meu ISP da esquerda dá ao meu router um IP público, mas o meu ISP da direita dá-me um IP público dinâmico dinâmico e IP privado dinâmico. Eu tenho dns dinâmicos para o ip público no lado esquerdo. Aqui está o que eu vejo quando eu cheirar o protocolo ISAKMP:

21:17:31.228715 IP (tos 0x0, ttl 235, id 43639, offset 0, flags [none], proto UDP (17), length 437)
    74.198.87.93.49604 > 192.168.0.11.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->0000000000000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(da31a7896e2a19582b33...0000001462b01880674b3739630ca7558cec8a89))
    (id: idtype=FQDN protoid=0 port=0 len=17 right.paxcoda.com)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
21:17:31.236720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 456)
    192.168.0.11.isakmp > 74.198.87.93.49604: [bad udp cksum 0x649c -> 0xcd2f!] isakmp 1.0 msgid 00000000 cookie da31a7896e2a1958->5b9776d4ea8b61b7: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1536)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180))))
    (ke: key len=192)
    (nonce: n len=16  data=(32ccefcb793afb368975...000000144a131c81070358455c5728f20e95452f))
    (id: idtype=FQDN protoid=0 port=0 len=16 left.paxcoda.com)
    (hash: len=16)
    (vid: len=16)
    (pay20)
    (pay20)
    (vid: len=16)

No entanto, o meu 3G Gateway (à direita) não responde e não sei porquê. Eu acho que a resposta da esquerda está realmente chegando ao meu gateway, porque em outra pergunta , eu estava tentando configurar um cenário semelhante com o modo principal IKE e, nesse caso, parece que pelo menos uma das três trocas de modo principal de duas vias foi bem-sucedida.

Que outra explicação para o fracasso está aí?

(O gateway 3G que estou usando à direita é um Moxa G3150, a propósito.)

    
por Isaac Sutherland 13.07.2012 / 23:30

1 resposta

0

Verifique os registros do sistema do Moxa OnCell - ele pode estar insatisfeito com a resposta do OpenSWAN e apenas abortar a troca sem aviso prévio. Mexer com o CLI também pode valer a pena - a maioria dos fabricantes permite algum tipo de depuração / rastreio de pacotes através do CLI.

Além disso, se possível, tente verificar se o pacote de resposta deixa seu roteador NAT @left em sua interface pública e o endereço está sendo reescrito para o IP público para descartar um possível problema de filtragem de roteamento / pacote na sua infraestrutura. / p>     

por 16.07.2012 / 13:45