USG40 to USG40 IpSec VPN: sometimes fall and do not restart

mMontana
mMontana Posts: 420  Master Member
Hoping to writing down the full scenario...
USG40 1: server side.
NAT-Ted WAN1, already using 10 tunnels/8 gateways configuration without hassle (1 gateway allows 3 tunnels for two local and two remote subnets).
Most of gateways are receiving only. Recent hardware 4.62 firmware.

USG40 2: client side.
NAT-Ted Wan1, using 1 tunnel to USG60 (another site, no issues on this tunnel at all), 1 tunnel for the "server" USG40. Older hardware, 4.62 firmware.

Here there are details about VPN connection:

  • Ike V2 - Static Address
  • Phase1 - Gateway
  • Pre-Shared Key
  • ID Type  DNS (local and remote)
  • SA LifeTime 86400
  • AES128 - SHA1
  • DH2
  • No EAP

  • Phase 2 - Tunnel
  • Enabled- (Nailed Up on client side)
  • Both Sides
  • Enable Replay detection
  • MSS Adjustment Auto
  • Narrowed Enabled
  • Site To Site
  • Coherent gateway and policies
  • SA LifeTime 86400
  • ESP - Tunnel
  • AES128 - SHA1
  • DH2

No connection check in any places. Tunnel and or gateway, server and/or client.

Tunnel most of the time works. But if it fails, my only option is manually disable the server side gateway and re-enable it. Once done, tunnel establish correctly and works as expected.

Feel free to ask me any of missing settings.

Answers

  • Jeremylin
    Jeremylin Posts: 166  Master Member
    I think you can try to enable connectivity check to avoid the tunnel down.
    Configure connectivity check on Client side, and the Check IP you can set IP of Lan device which behind USG40 1: server side.
  • mMontana
    mMontana Posts: 420  Master Member
    edited May 31
    IMVHO this could lead to another issue: the reliability of the connection is depending on "upness" of another device which is not the firewall.
    Client side firewall currently cannot ping server side

    (no rule should block that)

    But devices on server side can ping client zone

    Scheda Ethernet Ethernet:

       Suffisso DNS specifico per connessione: server.local
       Indirizzo IPv4. . . . . . . . . . . . : 192.168.10.59
       Subnet mask . . . . . . . . . . . . . : 255.255.255.0
       Gateway predefinito . . . . . . . . . : 192.168.10.1
    ping 192.168.40.1 -n 10
    Esecuzione di Ping 192.168.40.1 con 32 byte di dati:
    Risposta da 192.168.40.1: byte=32 durata=40ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=35ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=33ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=34ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=35ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=35ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=35ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=34ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=34ms TTL=61
    Risposta da 192.168.40.1: byte=32 durata=34ms TTL=61

    Statistiche Ping per 192.168.40.1:
        Pacchetti: Trasmessi = 10, Ricevuti = 10,
        Persi = 0 (0% persi),
    Tempo approssimativo percorsi andata/ritorno in millisecondi:
        Minimo = 33ms, Massimo =  40ms, Medio =  34ms


    (please, forgive the italian outputs of the console, my computer currently italian language only, but most of the meaning should be understandable... 10 packets sent, 10 packets received, 100% success)

    Do you think this could be a "safe" way to realize connectivity check?
    Also: which is default action about checking the connection? IMVHO should be reset...










  • Jeremylin
    Jeremylin Posts: 166  Master Member
    edited June 2
    Click show advance settings,then select the indicated Interface (192.168.40.1) to see if the ping can work.



  • mMontana
    mMontana Posts: 420  Master Member

    As requested. As expected.
    With tunnel working...



Security Highlight