IPSEC VPN - Connectivity Issues

[TeamSystems]

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

[ede_pfau]

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}

[TeamSystems]

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]

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?

[TeamSystems]

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]

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

[TeamSystems]

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]

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