Desvios aleatórios do túnel IPsec VPN Vyatta

2

Eu continuo recebendo quedas aleatórias para o meu túnel VPN, isso só acontece raramente (~ duas vezes por semana) se eu fizer um "serviço ipsec restart" então ele imediatamente começa a funcionar novamente. Realmente chato como eu estou tentando replicar uma grande VM para o nosso site de DR e toda vez que o túnel cai eu tenho que começar de novo!

Config como abaixo. Alguma idéia caras?

esp-group DR {
         compression disable
         lifetime 3600
         mode tunnel
         pfs enable
         proposal 1 {
             encryption aes128
             hash sha1
         }
     }


 ike-group DR {
         dead-peer-detection {
             action restart
             interval 15
             timeout 30
         }
         lifetime 28800
         proposal 1 {
             dh-group 2
             encryption aes128
             hash sha1
         }
     }



peer *.*.*.* {
             authentication {
                 mode pre-shared-secret
                 pre-shared-secret ***
             }
             connection-type initiate
             description "DR Site"
             ike-group DR
             local-address *.*.*.*
             tunnel 2 {
                 allow-nat-networks disable
                 allow-public-networks disable
                 esp-group DR
                 local {
                     prefix 192.168.*.0/24
                 }
                 remote {
                     prefix 10.*.0.0/24
                 }
             }
         }

Após verificar os registros, eles pareciam estar cheios com esta mensagem:

Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: received Vendor ID payload [Dead Peer Detection]
Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [RFC 3947]
Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Apr  3 13:23:37 *.*.*.* pluto[20789]: packet from *.*.*.*:500: initial Main Mode message received on *.*.*.*:500 but no connection has been authorized with policy=PSK
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: process_status_message: bad node [****] in message
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG: Dumping message with 12 fields
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[0] : [t=status]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[1] : [st=active]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[2] : [dt=2710]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[3] : [protocol=1]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[4] : [src=****]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[5] : [(1)srcuuid=0x201c570(36 27)]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[6] : [seq=28077b]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[7] : [hg=50b63627]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[8] : [ts=533d60db]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[9] : [ld=0.00 0.01 0.05 1/87 31182]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[10] : [ttl=3]
Apr  3 13:23:39 *.*.*.* heartbeat: [3397]: ERROR: MSG[11] : [auth=1 96fa591a077c1bd3941d450c9c8973d8f0a9440f]
    
por Mark Gifford 03.04.2014 / 14:04

2 respostas

1

O cenário que encontrei ajudou muito a estabilidade do túnel

set vpn ipsec auto-update '60'

Meus intervalos de detecção de peidos mortos & os tempos limite foram maiores que os seus (30 e 120 segundos, respectivamente) e usei VTIs, mas suas configurações são quase idênticas às minhas. Consegui sustentar 400 Mbps através do túnel dentro de uma VM VyOS sem problemas.

    
por 23.01.2015 / 07:07
0

Desculpe, não posso comentar, não é realmente uma resposta:

  • Você tentou aumentar o valor ike-group DR dead-peer-detetion timeout ?
  • É possível que, aleatoriamente, duas vezes por semana, haja um pico de uso da rede que sature toda a largura de banda disponível?
por 18.04.2014 / 10:29

Tags