Disabling aggressive mode is good way, but

[Leftz]

Hi we have some routers which show security vulnerability. After disabling aggressive mode for tunnel, it has a good results. But one of them still has the issue. After checking, I found the tunnel is inactive. My question is what is a better way to resolve the issue? I do not want to remove the tunnel. Thank you

[MHM Cisco World · Accepted solution]

traffic make the tunnel active does traffic hit policy ACL ?

[Rob Ingram]

@Leftz troubleshoot the issue, determine whether this is related to aggressive mode or a conincident.

Turn on IKE debugs, generate interesting traffic to attempt to establish the tunnel and provide the debug output.

[Leftz]

Thank you very much for your reply!

I am not sure if it is vpn for this issue. The below is only one Tunnel that is up now. but its inactive based on the command show crypto isakmp sa. so that we can just shutdown it

interface Tunnel10
ip address 172.16.222.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source 39.2.2.2
tunnel destination 51.5.5.5
tunnel protection ipsec profile ABC

I am not security guy. and we just occasionally touch vpn/gre. so it would be much better if you can provide some commands for troubleshooting.  

[Rob Ingram]

@Leftz this is a route based VPN, this should always be up (if no issues).

Can you ping the peer device - 51.5.5.5?

Run "show crypto ipsec sa" and determine if you've got an IPSec SA pair.

Have you got a route (static or dynamic) via Tunnel10?

What is the rest of the configuration, ISAKMP r IKEv2 policies and profiles?

[MHM Cisco World]

Tunnel source must use interface not ip address.

[Leftz]

@Rob Ingram Thanks Rob

Please see the below:

Can you ping the peer device - 51.5.5.5?    Cannot ping it

Run "show crypto ipsec sa" and determine if you've got an IPSec SA pair.

A01#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
51.5.5.5 39.2.2.2 MM_NO_STATE 0 ACTIVE
51.5.5.5 39.2.2.2 MM_NO_STATE 0 ACTIVE (deleted)

Have you got a route (static or dynamic) via Tunnel10? Yes, there is static route

What is the rest of the configuration, ISAKMP r IKEv2 policies and profiles? The config looks mess and no relevant config 

[Rob Ingram · Accepted solution]

@Leftz should be able to ping the peer device or is ICMP filtered? If you should be able to ping it and it is not responding then that might be your issue.

There is other relevant configuration, you'll have an IPSec profile called ABC and ISAKMP/IKEv2 policies/profiles.

Do you control the other peer device? If not contact the partner and ask them to troubleshoot with you.

Turn on your ISAKMP/IKEv2 debugs and provide the output.

If you disabled agressive mode, then renable it and confirm if the issue remains or is resolved. If you still have another issue then it may not be related.

[Leftz]

the tunnel0 config below has three ip address. the device can only ping 172.16.222.1 and cannot ping other two 39.2.2.2 and 51.5.5.5. This 39.2.2.2 is source. do you know why it cannot be ping. when show ip int bri, its up

interface Tunnel10
ip address 172.16.222.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source 39.2.2.2
tunnel destination 51.5.5.5
tunnel protection ipsec profile ABC

I cannot control other end. As the tunnel is inactive, what we want is to make decision whether or not to shutdown. Based on the config, it looks gre over ipsec. do you agree? 

[Rob Ingram]

@Leftz why can you not ping 39.2.2.2, it should be local to your router? That IP address should be the IP address of the internet/WAN facing interface, which your peer should be attempting to establish a tunnel with.

You've provided no configuration or information to answer why you cannot ping your own IP address.

The VPN is a GRE over IPSec with Tunnel Protection.

Did this tunnel work before you made the change?

This post is 2 days old, surely if the tunnel was in use someone would have mentioned it?

[Leftz]

The tunnel is inactive for long time. so it should not be in use for long time. Checking its interface, it shows no any traffic. 

The strange thing that i just found is the interface 39.2.2.2 is up, but it cannot ping. 

[Rob Ingram]

@Leftz then it probably isn't in use and disabling aggressive mode is not the cause of the problem.

[Leftz]

@Rob Ingram  Since the tunnel and its interface facing outside have not traffic, it can be shutdown. but what we want to know is if the shutdown can resolve security vulnerability issue. That is the purpose of the post. but we can try it anyway as it has not traffic. Do you agree?

[Rob Ingram · Accepted solution]

@Leftz aggressive mode is disabled globally and you've already confirmed good results. So as the this tunnel is not in use, you can safely disable.

[Leftz]

Thank you Rob. after shutdown tunnel, the issue resolved.