Como eu configuro o StrongSwan para atuar como um cliente IKEv1?

Question

Um cliente do nosso negócio de desenvolvimento forneceu acesso à VPN IPSec, fornecendo as credenciais necessárias (anônimas):

• Gateway: example.fake
• Grupo: MYGROUP
• Usuário: MYUSER
• Senha: MYPASSWORD
• PSK: MYPSK

Eles também forneceram os parâmetros configurados ao seu lado:

Phase 1

• Authentication: SHA1
• Encryption: AES 256
• SA Life: 1 hour
• Key Group: Diffie Helman group 2
• NAT Traversal & DPD are enabled
• Keep-alive interval: 20 seconds

Phase 2

• Type: ESP
• Authentication: SHA1
• Encryption: AES 256
• Force key expiration: 1 hour

O tipo de conexão é IKEv1 e eles configuraram o acesso através do túnel VPN somente em um IP 1.2.3.4 específico, porque essa é a única máquina que temos que acessar.

Meta e tentativa

Estou tentando descobrir como configurar o StrongSwan para se conectar à sua VPN. Eu preciso disso trabalhando em um VPS com o Ubuntu Server 16.04.

Eu tentei seguir um monte de guias, mas alguns eram para versões mais antigas do StrongSwan, então eles não funcionavam. Por fim, editei /etc/ipsec.conf com a seguinte tentativa de configuração:

config setup

conn myconn
    authby=xauthpsk
    dpdaction=restart
    esp=aes256-sha1
    ike=aes256-sha1-dh2
    ikelifetime=1h
    keyexchange=ikev1
    leftauth=psk
    leftauth2=xauth
    leftgroups=MYGROUP
    leftid=@MYUSER
    right=example.fake
    rightsubnet=1.2.3.4/32

Eu criei /etc/ipsec.secrets :

: PSK "MYPSK"
MYUSER: XAUTH "MYPASSWORD"

Estado final desejado e mensagem de erro

O estado final desejado é que nossa máquina se conecta à VPN do cliente e podemos alcançar esse único IP 1.2.3.4. O restante do tráfego deve ser dividido e não passar pela VPN.

Apesar do fato de myconn ser definido em /etc/ipsec.conf , essa mensagem de erro aparece ao tentar se conectar:

# ipsec restart
Stopping strongSwan IPsec...
Starting strongSwan 5.3.5 IPsec [starter]...
# ipsec up myconn
no config named 'myconn'

Arquivos de log

Estas linhas são adicionadas a /var/log/syslog após a execução de ipsec restart :

Jun  5 16:45:01 server charon: 00[DMN] signal of type SIGINT received. Shutting down
Jun  5 16:45:03 server charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.8.0-53-generic, x86_64)
Jun  5 16:45:03 server charon: 00[CFG] disabling load-tester plugin, not configured
Jun  5 16:45:03 server charon: 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
Jun  5 16:45:03 server charon: 00[CFG] dnscert plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] ipseckey plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] attr-sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jun  5 16:45:03 server charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jun  5 16:45:03 server charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jun  5 16:45:03 server charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jun  5 16:45:03 server charon: 00[CFG]   loaded RSA private key from '/etc/ipsec.d/private/myKey.der'
Jun  5 16:45:03 server charon: 00[CFG] sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] opening triplet file /etc/ipsec.d/triplets.dat failed: No such file or directory
Jun  5 16:45:03 server charon: 00[CFG] eap-simaka-sql database URI missing
Jun  5 16:45:03 server charon: 00[CFG] loaded 0 RADIUS server configurations
Jun  5 16:45:03 server charon: 00[CFG] no threshold configured for systime-fix, disabled
Jun  5 16:45:03 server charon: 00[CFG] coupling file path unspecified
Jun  5 16:45:03 server charon: 00[LIB] loaded plugins: charon test-vectors unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt af-alg fips-prf gmp agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity
Jun  5 16:45:03 server charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jun  5 16:45:03 server charon: 00[JOB] spawning 16 worker threads

Estes são adicionados depois de executar ipsec up myconn :

Jun  5 16:45:21 server charon: 15[CFG] received stroke: initiate 'myconn'
Jun  5 16:45:21 server charon: 15[CFG] no config named 'myconn'

Eles parecem consistentes com a mensagem de erro mencionada anteriormente.

Pergunta

Por que ipsec up myconn diz que não existe tal configuração? É a primeira vez que tento lidar com uma VPN IPSec ... a configuração que tentei escrever faz algum sentido?

O que tenho que mudar para que funcione?

Atualizar depois de adicionar auto=add

Como sugerido nos comentários, adicionei auto=add à minha configuração. Eu agora entendo isso:

# ipsec up myconn
initiating Main Mode IKE_SA myconn[1] to <IP of example.fake>
configuration uses unsupported authentication
tried to check-in and delete nonexisting IKE_SA
establishing connection 'myconn' failed

Estas linhas são anexadas ao arquivo de registro:

Jun  5 17:07:19 server charon: 12[CFG] received stroke: initiate 'myconn'
Jun  5 17:07:19 server charon: 14[IKE] initiating Main Mode IKE_SA myconn[2] to <IP of example.fake>
Jun  5 17:07:19 server charon: 14[CFG] configuration uses unsupported authentication
Jun  5 17:07:19 server charon: 14[MGR] tried to check-in and delete nonexisting IKE_SA

Atualizar após remover esp= , ike= e keyexchange=

Após remover as três linhas mencionadas acima, a tentativa de conexão é assim, por três vezes (o snippet mostra apenas o primeiro, o outro é idêntico):

Jun  5 17:18:44 server charon: 06[CFG] received stroke: initiate 'myconn'
Jun  5 17:18:45 server charon: 04[IKE] initiating IKE_SA myconn[1] to <IP of example.fake>
Jun  5 17:18:45 server charon: 04[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
Jun  5 17:18:45 server charon: 04[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:49 server charon: 03[IKE] retransmit 1 of request with message ID 0
Jun  5 17:18:49 server charon: 03[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:56 server charon: 15[IKE] retransmit 2 of request with message ID 0
Jun  5 17:18:56 server charon: 15[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:09 server charon: 01[IKE] retransmit 3 of request with message ID 0
Jun  5 17:19:09 server charon: 01[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:32 server charon: 16[IKE] retransmit 4 of request with message ID 0
Jun  5 17:19:32 server charon: 16[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:20:14 server charon: 05[IKE] retransmit 5 of request with message ID 0
Jun  5 17:20:14 server charon: 05[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:21:30 server charon: 13[IKE] giving up after 5 retransmits
Jun  5 17:21:30 server charon: 13[IKE] peer not responding, trying again (2/3)

Atualização: Configuração de trabalho para ShrewSoft VPN

A conexão com a VPN do cliente foi testada em uma máquina desktop no escritório, usando ShrewSoft VPN, no entanto, isso não é adequado para usá-lo no VPS de desenvolvimento. O referido programa exportou a seguinte configuração:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1
b:auth-mutual-psk:****REMOVED****
n:phase1-dhgroup:2
n:phase1-keylen:0
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:0
n:phase2-pfsgroup:-1
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:1
s:network-host:example.fake
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk-xauth
s:ident-client-type:keyid
s:ident-client-data:MYGROUP
s:ident-server-type:any
s:phase1-exchange:aggressive
s:phase1-cipher:auto
s:phase1-hash:auto
s:phase2-transform:auto
s:phase2-hmac:auto
s:ipcomp-transform:disabled
s:policy-level:auto

Isso sugere alguma alteração que deve ser feita no arquivo ipsec.conf para que isso funcione com o StrongSwan?

    

Answer 1

Talvez esta seja uma resposta tardia, mas aqui estão algumas dicas sobre os problemas que detectei (mas não tentei / testei):

• authby está obsoleto e você está usando o leftauth. Configurar explicitamente o leftauth / rightauth e o leftauth2 / rightauth2 ajudaria. Em minhas experiências (e olhando para o código C no github) para IKEv1, há apenas um número limitado if / else check, e quando esquerda e direita não combinam (diferente de qualquer ), você receberá a mensagem "autenticação não suportada"
• Estranhamente (e eu não olhei para o código C para verificar isso) há alegações de que você deve ter um em cada lado do ':' em seus arquivos de segredos (ou seja, 'MYUSERS: XAUTH "MYPASSWORD"', no seu, você não tem espaço no MYUSER:)
• Dependendo de suas distros, alguns métodos de criptografia podem não ser suportados (isto é, 3DES) - assista ao log de caracteres para plugins para ver o que está carregado.
• Quem disse para remover 'keyexchange' perdeu a sua pergunta que você quer IKEv1. Para o IKEv1, você deve definir explicitamente keyexchange = ikev1 ; O padrão é 'ike', que é tanto IKEv1 quanto IKEv2 no lado do servidor, não no lado do cliente (o que significa que, como servidor VPN, aceitarei tanto a v1 quanto a v2 dos meus clientes). No seu caso, o seu rolo é um cliente, então você teria que ser explícito.
• Eu não concordo com a remoção de esp = e ike = desde que você prestou no seu OP explicitamente o que é sua Phase1 (é dh2 ou aes256-sha1-modp2048?) e Phase2; Se você puder usar a ferramenta 'ike-scan' para sua distro, use isso. Ele vai lhe dar até mesmo algumas dicas sobre se o seu endpoint suporta o IKEv2. Geralmente, o que eu descubro do 'ike-scan' é se o terminal suporta 3DES ou não, já que em algumas distro, eles não mais distribuem com o 3DES como parte do binário.
• Tenho notado que, para a sua configuração do Shrewsoft, você configurou agressive = yes, o que também pode ser necessário para experimentar o ipsec.conf quando a fase2 estiver funcionando.
• Assumindo que sua 'esquerda' é do lado do cliente e 'direita' é o gateway remoto, você definiu 'leftid' em vez de 'rightid' - basicamente, rightid deve corresponder ao seu arquivo .secrets, a menos que você esteja intencionalmente querendo o gateway para autenticar você?

Algumas outras dicas:

• Defina seu log de carnes em 'NET' e 'CFG' (escolha e escolha) para ter um nível de log mais alto, dependendo do que você está depurando (com nível de log alto o suficiente, você não precisa nem de tcpdump)
• Como mencionado acima, é bastante crítico que both esquerda e direita auth / auth2 correspondam (mesmo se a sua esquerda for do lado do cliente) para garantir que você não receba 'configurações de configuração sem suporte ... 'erros (definindo o seu' cfg 'no charon log não vai ajudar aqui, eu tive que olhar para o código C)
• Como alguém mencionou, certifique-se de ter pelo menos 'auto = add' - uma oferta é quando você faz '$ ipsec statusall ' você não verá o seu 'conn' se não fosse adicionou

Em qualquer caso, algumas informações ausentes tiveram que ser deduzidas indiretamente com base em configurações e outros logs que você pode ter desejado fornecer antes para evitar comentários:

• Fase 1: PSK (pré-compartilhada)
• Fase 2: xauth-radius

Não sei muito bem o que seu servidor VPN remoto está usando, mas acima está supondo que ele é baseado em raio, certifique-se de configurar corretamente seus plug-ins xauth com base nele.

Por fim, siga a documentação do 'ipsec.conf' do Strongswan através do que é suportado no IKEv1. Além disso, se seu endpoint for baseado em NTLM, lembre-se de que as senhas NTLM são MD4 codificadas (basta procurar por algo no sentido de inserir a string UTF16 em openssl como MD4).