StrongSwan ipsec ubuntu “ignorando a carga informativa, digite NO_PROPOSAL_CHOSEN”

Question

Eu tenho o StrongSwan rodando em um servidor Ubuntu e estou tentando criar um túnel VPN criptografado em ipsec com um roteador Cisco 2821. A conexão não está funcionando e não consigo entender por quê. Parece completar a fase 1, mas falha na fase 2. Alguém pode dar sugestões? Estou perplexo. BTW, meu servidor está na nuvem amazon.

Aqui está minha configuração:

conn my-conn
        type=tunnel
        authby=secret
        auth=esp
        ikelifetime=86400s
        keylife=3600s
        esp=3des-sha1
        ike=3des-sha1-modp1024
        keyexchange=ike
        pfs=no
        forceencaps=yes
        # Left security gateway, subnet behind it, nexthop toward right.
        left=10.0.0.4
        leftsubnet=10.0.0.4/32
        leftnexthop=%defaultroute
        # Right security gateway, subnet behind it, nexthop toward left.
        right=1.2.3.4   
        rightsubnet=1.2.3.5/32
        rightnexthop=%defaultroute
        # To authorize this connection, but not actually start it,
        # at startup, uncomment this.
        auto=start

Aqui está a saída dos registros:

Dec 28 18:02:19 myserver pluto[15753]: "my-conn" #330: initiating Main Mode
Dec 28 18:02:19 myserver pluto[15753]: "my-conn" #330: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Dec 28 18:02:19 myserver pluto[15753]: "my-conn" #330: enabling possible NAT-traversal with method RFC 3947
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: ignoring Vendor ID payload [Cisco-Unity]
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: received Vendor ID payload [Dead Peer Detection]
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: ignoring Vendor ID payload [883f3a4fb4782a3ae88bf05cdfe38ae0]
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: received Vendor ID payload [XAUTH]
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
Dec 28 18:02:20 myserver pluto[15753]: | protocol/port in Phase 1 ID Payload is 17/0. accepted with port_floating NAT-T
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: Peer ID is ID_IPV4_ADDR: '1.2.3.4'
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: ISAKMP SA established
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #331: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#330}
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Dec 28 18:02:20 myserver pluto[15753]: "my-conn" #330: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME

A configuração que me foi dada para conectar ao roteador cisco foi:

Key Management: IKE 
Diffie-Hellman Group:   Group 2 
Encryption Algorithm:   3DES (rec)  
Hash Algorithm: SHA-1 (rec.)    
Authentication Method:  Preshared   
Pre-Shared Secret Key:  TBC 
Life Time:  86400s (24h)    

Encryption Phase 2 (IPSec):     

Encapsulation:  ESP 
Encryption Algorithm used:  3DES (rec)  
Hash Algorithm: SHA-1 (rec.)    
Perfect Forward Secrecy:    Groupe 2    
Aggressive Mode:    NO  
Life Time:  3600s (1h)  

    

Answer 1

Se bem me lembro, o Amazon EC2 usa algum NAT para tornar sua instância acessível pela Internet.

Embora os aplicativos compatíveis com NAT funcionem perfeitamente (pense em http ou ssh), alguns protocolos foram projetados em um momento em que a comunicação de ponta a ponta era a regra, e o NAT quebraria esses protocolos.

FTP ou SIP (o rtp na verdade) usa portas escolhidas dinamicamente, mas os ajudantes foram criados. STUN para VoIP por exemplo.

No caso do IPSec, a fase 1 é bem-sucedida. Esta é a detecção de NAT. Então o seu servidor diz nos logs i am NATed .

No entanto, a fase 2, que é a decisão transversal NAT, falha. Você pode ter que habilitar o que a Cisco chama de 'transparência IPSec NAT' em ambos os lados. A carga útil ipsec, portanto, não está no nível da camada 3 (IP), mas na camada 4, no UDP.

Isso é um pouco semelhante ao que o openvpn faz, mas com ssl em vez de IPSec.

Dê uma olhada no site da Cisco sobre o NAT traversal . Embora seja ciscocêntrico, ajudará você a configurar seu túnel.

    

Answer 2

Recebi este erro com StrongSwan 5.6.1 no Centos 7 durante a conexão a um servidor Windows. O erro é devido ao servidor remoto usando cifras fracas que são consideradas reprovadas pelo StrongSwan .

• A ativação das seguintes cifras fracas permite que a conexão ipsec para complete:

  • Algoritmos da fase 1: aes128-sha1-modp2048,3des-sha1-modp1536,3des-sha1-modp1024
  • Algoritmos da fase 2: aes128-sha1,3des-sha1

vejaos problemas conhecidos para o network-manager-l2tp

Eu encontrei o wiki do Arch Linux L2TP útil & as instruções embora para OpenSwan também funcionam em StrongSwan :

• Execute ipsec verify primeiro para configurar seu ambiente.

• Executar xl2tpd -D (modo de depuração) - para confirmar se suas configurações são adequadas.

• Forneça à VPN o mesmo nome no applet NetworkManager que você atribuiu à configuração conn em /etc/ipsec.conf

• O plug-in network-manager-l2tp parece estabelecer a conexão L2TP correspondente por meio do endereço lns ip em /etc/xl2tpd/xl2tpd.conf . O nome que você atribuiu à configuração [lac vpn-name] não parece importar para o plug-in.

• Essas notas também se aplicam à configuração de L2TP com ipsec em Arch Linux . Use Libreswan ( Strongswan ipsec não funciona no Arch Linux) com o network-manager-l2tp plugin & coloque os detalhes da sua conexão ipsec em /etc/ipsec.d/*.conf . O nome do arquivo pode ser qualquer coisa, pois o plug-in pesquisa uma string conn nos arquivos de configuração que correspondem ao nome da VPN no NetworkManager .