IOS VPN tunnel interface keeps going down

[ricardo1831]

Hello Community,

I hope someone might be able to help with an issue I'm seeing on an IOS VPN Tunnel interface which keeps going down and then back up...

We have a Cisco 2811 acting as a VPN Hub router on the backbone, which connects to various client sites over VPN. Of the 7 VPNs configured so 6 work well and are generally trouble free. The VPN interface on the other VPN keeps going down ,multiple times throughout the day, just recently the client has been noticing loss of connectivity. The remote router is managed over the VPN so there is always some kind of traffic over it.

Does anyone know or be able to help find the answer as to why this is happening. Please see router log below...

*Sep  7 06:40:53.631: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to down

*Sep  7 06:41:23.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to up

*Sep  7 15:21:12.541: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to down

*Sep  7 15:21:43.013: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to up

*Sep  7 23:58:46.451: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to down

*Sep  7 23:59:16.811: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to up

*Sep  8 08:37:07.705: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to down

*Sep  8 08:37:38.117: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to up

*Sep  8 12:30:37.200: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to down

*Sep  8 12:34:05.248: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel111, changed state to up

Issue has caused outages a number of times today. See config snippets below, with equivalent on the backbone router...

crypto isakmp policy 10

encr aes 256

authentication pre-share

group 2

crypto isakmp key 6 [sharedkey] address X.X.X.X no-xauth

crypto isakmp invalid-spi-recovery

crypto isakmp ccm

!

!

crypto ipsec transform-set OPNET_VPN_TS esp-aes 256 esp-sha-hmac

!

crypto ipsec profile OPNET_VPN_IPSEC_PROFILE

description *** OPNET VPN IPsec Profile - RH - July 2011 ***

set transform-set OPNET_VPN_TS

set pfs group2

interface Tunnel111

description *** Client OPNET VPN Tunnel (OPNET-VPNHUB-RT1:X.X.X.X) ***

bandwidth 2048

ip address 172.32.111.2 255.255.255.252

ip mtu 1400

ip nat outside

ip virtual-reassembly

ip tcp adjust-mss 1360

tunnel source FastEthernet0/0

tunnel destination X.X.X.X

tunnel mode ipsec ipv4

tunnel protection ipsec profile OPNET_VPN_IPSEC_PROFILE

I hope someone out there will be able to help. All response appreciated.

Regards,

Ric

[Marcin Latosiewicz]

Ric,

This is a VTI tunnel, VTI tunnels' line protocol goes up/down depending on state of IPSec. I.e. unlike GRE, VTI tunnel with go up/up only when IPsec negotiation is successful.

In almost all the case I see the tunnel goes down for 30 seconds exactly.

I think the best is to open up a case with TAC so they can investigate why IPsec SAs are going down (normally new ones should be negotiates before the old ones expire).

Alternatively:

- Increase IPsec SA liftime

- Increase IKE SA liftime

- If you're running 12.4T code, consider going to 15.0.1M7 maybe?

The first two options should decrease impact and frequency of failures IF this is related to a fault in IPsec.

HTH,

Marcin

[ricardo1831]

Hello Marcin,

Thanks for your reply. I have found the cause to this issue and it wasn't anything to do with the VPN tunnel configuration or the VPN termination routers.

The issue was with the client site firewall the VPN has to pass through to hit the router:-

In a nutshell: The firewall uses a resource on the internet to determine if a certain WAN interface is still connected to the internet, the firewall had difficulties reaching this resource and as a result stamped one of the interfaces as unreliable. You can probably guess which interface.

One to watch if anyone else comes across this type of issue.

As ever I appreciate your response and thanks to the Support Community in general, the best place to go for all Cisco technical queries!!

Many Thanks,

Ric