Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
TeamSystems
New Contributor

IPSEC VPN - Connectivity Issues

Hello, I' m having a weird issue with a an IPsec VPN tunnel. The first issue is when I ping a device on the other network segment, the first two packets Time Out, and then the next two receive a reply. But if I do a constant Ping, I have no problems pinging the device. Also, connectivity back to servers seem to be sporadic. I' m out of ideas here as we have other VPN' s working fine, but this one is causing nothing but grief. Thanks for your help! Wallace
7 REPLIES 7
ede_pfau
SuperUser
SuperUser

I' d say that that' s nothing to worry about: initially, the tunnel is down as no traffic is running across it. Tunnel negotiations take maybe 2 seconds, the time it takes for 2 pings so these pings get lost. The next pings go right through (check with ' ping -t' ). If you see frequent tunnel-downs during the day then either check the timeouts or check the quality of the connection. Every lost packet will tear the tunnel down. If you want your tunnel to be up all time, independent of traffic, then you can set a parameter in phase 2 to have it auto-negotiated. This is in CLI only:
 config vpn ipsec phase2 // or phase2-interface
    edit <tunnel_name>
       set auto-negotiate {enable | disable}
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
TeamSystems
New Contributor

How do you go about checking the timeouts of the connection? Because I' m still having issues with connections going across my VPN. Any tips ideas on what I can do to figure this out? Any help is appreciated. Thanks!
ede_pfau
SuperUser
SuperUser

You could do a continuous ping (ping -t) across the tunnel, preferably with logging, to see if there are outages despite ongoing traffic. If so, it' s not the idle timer. Check the keylife timers on both sides (phase1/2) to be equal. Do you have ' auto-nego' configured yet?
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
TeamSystems
New Contributor

Keeping a continuous ping will have the ping have a reply. But if I wait say 1-2 min and try it again, it takes a while for the ping to get a reply. Almost like the tunnel keeps on failing and has to be reestablished. Even with set auto-negotiate enable this keeps on happening. Phase 1 edit " SECRADPvpn" set interface " MTS Internet" set local-gw <Local GW IP> set dhgrp 1 set proposal des-md5 set remote-gw <remoteip> set psksecret ENC <blahblah> Phase 2 edit " SECRADPvpn" set auto-negotiate enable set keepalive enable set pfs disable set phase1name " SECRADPvpn" set proposal des-md5 set replay disable set dst-subnet 192.168.50.0 255.255.255.0 set keylifeseconds 3600 set src-subnet 206.89.23.0 255.255.255.0 No idea what' s going on. I have other VPN' s that are working fine. Any help is appreciated. Thanks!
emnoc
Esteemed Contributor III

What' s on the other side of the VPN? You might need to research/review that device configuration.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
TeamSystems
New Contributor

I' m using a DLink-130 router. Find attached the screen shot of the config screen for it. Also, I' ve included the log from the DLink. Apr 17 11:30:08 IPSec IPSec " conn_SECRADPvpn" #25: received Delete SA payload: deleting ISAKMP State #25 Apr 17 11:39:00 IPSec IPSec " conn_SECRADPvpn" #37: initiating Quick Mode PSK+ENCRYPT+TUNNEL to replace #35 Apr 17 11:39:00 IPSec IPSec " conn_SECRADPvpn" #37: You should NOT use insecure ESP algorithms [ESP_DES (56)]! Apr 17 11:39:00 IPSec IPSec " conn_SECRADPvpn" #37: Dead Peer Detection (RFC3706) enabled Apr 17 11:39:00 IPSec IPSec " conn_SECRADPvpn" #37: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 Apr 17 11:39:00 IPSec IPSec " conn_SECRADPvpn" #37: sent QI2, IPsec SA established Apr 17 12:26:56 IPSec IPSec " conn_SECRADPvpn" #38: initiating Quick Mode PSK+ENCRYPT+TUNNEL to replace #37 Apr 17 12:26:56 IPSec IPSec " conn_SECRADPvpn" #38: You should NOT use insecure ESP algorithms [ESP_DES (56)]! Apr 17 12:26:56 IPSec IPSec " conn_SECRADPvpn" #38: Dead Peer Detection (RFC3706) enabled Apr 17 12:26:56 IPSec IPSec " conn_SECRADPvpn" #38: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 Apr 17 12:26:56 IPSec IPSec " conn_SECRADPvpn" #38: sent QI2, IPsec SA established Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #36: received Delete SA payload: replace IPSEC State #38 in 10 seconds Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #36: received and ignored informational message Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #39: You should NOT use insecure ESP algorithms [ESP_DES (56)]! Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #39: responding to Quick Mode Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #39: transition from state (null) to state STATE_QUICK_R1 Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #39: Dead Peer Detection (RFC3706) enabled Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #39: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2 Apr 17 12:52:33 IPSec IPSec " conn_SECRADPvpn" #39: IPsec SA established Apr 17 13:48:03 IPSec IPSec " conn_SECRADPvpn" #40: initiating Quick Mode PSK+ENCRYPT+TUNNEL to replace #39 Apr 17 13:48:03 IPSec IPSec " conn_SECRADPvpn" #40: You should NOT use insecure ESP algorithms [ESP_DES (56)]! Apr 17 13:48:03 IPSec IPSec " conn_SECRADPvpn" #40: Dead Peer Detection (RFC3706) enabled Apr 17 13:48:03 IPSec IPSec " conn_SECRADPvpn" #40: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 Apr 17 13:48:03 IPSec IPSec " conn_SECRADPvpn" #40: sent QI2, IPsec SA established
emnoc
Esteemed Contributor III

Suggestions:
conn_SECRADPvpn" #40: You should NOT use insecure ESP algorithms [ESP_DES (56)]!
1: Will I would not use DES unless that was the only option. Does the DLINk support at least 3DES? dh-grp 1 and DES is a very bad allocation from a security technologies. It' s only used in general, when you need quick keypairs generation and your concern with overall CPU impact. Typically one starts with dh-grp2 or 5 in some cases, and fallback or revert to DH-grp1 as a last ditch effort. ( just something to think about ) 2:Next, strict all of the other proposals to eliminate any confusions. Since you only need one. Why have proposal 2 3 4 5 3: I believe your problem is a NAT transversal and you need to adjust the time interval

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors