USG40 to USG40 IpSec VPN: sometimes fall and do not restart
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.
0
All Replies
-
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.0 -
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 zoneScheda 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...
0 -
Click show advance settings,then select the indicated Interface (192.168.40.1) to see if the ping can work.0
-
As requested. As expected.With tunnel working...
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 146 Nebula Ideas
- 96 Nebula Status and Incidents
- 5.7K Security
- 262 USG FLEX H Series
- 271 Security Ideas
- 1.4K Switch
- 74 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.4K Consumer Product
- 250 Service & License
- 387 News and Release
- 84 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.5K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 85 About Community
- 73 Security Highlight