StrongSwan 5.2.1 no Debian Jessie vs Juniper SSG 550M - Tempo de vida de conexão curto

Question

Estamos tentando estabelecer uma conexão VPN persistente contra uma caixa do Juniper. No entanto, há algum erro de configuração. Quando começamos o serviço StrongSwan, o túnel está funcionando e todo o tráfego está bom. Mas assim que não houver fluxo de tráfego em alguns segundos, a conexão estará inativa e o serviço deverá ser reiniciado. Quando executamos um loop de ping sem fim para o endereço IP de destino da VPN em segundo plano, a conexão sobrevive. Acreditamos que é algum tipo de problema relacionado ao keep-alive. Alguém vê alguma inconsistência de configuração possível?

Folha de especificações - os dois sites concordaram com as seguintes configurações de IPSec:

Fase 1 (troca de chaves):
Criptografia {3DES, AES256}: AES256
Integridade de dados {MD5, SHA1, SHA2}: SHA256
Diffie-Hellman {MD5, SHA1, SHA2}: 5
Renegociar IKE SA {Segundos}: 86400

Fase 2 (transporte de dados):
IPSec: ESP
Criptografia {3DES, AES256}: AES256
Integridade de dados {MD5, SHA1, SHA2}: SHA256
PFS: Sim
Diffie-Hellman: 5
SA Life Time {Segundos}: 3600
Compressão IP: Não

Arquivos de configuração relacionados a seguir.

ipsec.conf:

config setup
  charondebug="ike 4, knl 4, cfg 4, net 4, esp 4, dmn 4,  mgr 4"
conn %default
  type=tunnel
  authby=secret
  ikelifetime=86400
  lifetime=3600
  keyexchange=ikev1
  compress=no
  dpdaction=restart
  dpddelay=10s
  dpdtimeout=500s
conn otto-105-183
  also=otto
  rightsubnet=10.108.105.183/32
conn otto-100-34
  also=otto
  rightsubnet=10.108.100.34/32
conn otto-100-35
  also=otto
  rightsubnet=10.108.100.35/32
conn otto
  auto=start
  ike=aes256-sha2_256-modp1536!
  esp=aes256-sha2_256-modp1536!
  left=%defaultroute
  leftsubnet=10.107.54.33/32
  leftfirewall=yes
  right=my_public_IP_address  ; redacted

charon.conf:

charon {
    keep_alive = 20s
    crypto_test {
    }
    host_resolver {
    }
    leak_detective {
    }
    processor {
        priority_threads {
        }
    }
    start-scripts {
    }
    stop-scripts {
    }
    tls {
    }
    x509 {
    }
}

    

Answer 1

A VPN descendo e caindo parece ser um problema (freqüente) de negociação de timeout.

Eu aconselho mudar o timeout do dpd nos equipamentos de ambos os lados da VPN para 30 segundos. Ambos têm que ter o mesmo valor.

No lado do Linux, é suficiente definir

dpdtimeout=30s

Em algumas situações, ao lidar com hardware de terceiros, da minha experiência, parece ser mais bem-sucedido escolher menores tempos limite de peer inoperante.

De Compreendendo a detecção de pares mortos

Dead peer detection (DPD) is a method that network devices use to verify the current existence and availability of other peer devices.
A device performs DPD verification by sending encrypted IKE Phase 1 notification payloads (R-U-THERE messages) to a peer and waiting for DPD acknowledgements (R-U-THERE-ACK messages) from the peer. The device sends an R-U-THERE message only if it has not received any traffic from the peer during a specified DPD interval. If the device receives an R-U-THERE-ACK message from the peer during this interval, it considers the peer alive. If the device receives traffic on the tunnel from the peer, it resets its R-U-THERE message counter for that tunnel, thus starting a new interval. If the device does not receive an R-U-THERE-ACK message during the interval, it considers the peer dead.