05-02-2022 02:36 PM - edited 05-02-2022 02:36 PM
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
Solved! Go to Solution.
05-02-2022 02:38 PM
traffic make the tunnel active does traffic hit policy ACL ?
05-04-2022 11:26 AM
@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.
05-04-2022 12:46 PM
@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.
05-02-2022 02:38 PM
traffic make the tunnel active does traffic hit policy ACL ?
05-03-2022 12:07 AM
@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.
05-04-2022 09:05 AM
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.
05-04-2022 09:16 AM
@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?
05-04-2022 11:39 AM
Tunnel source must use interface not ip address.
05-04-2022 11:15 AM - edited 05-04-2022 11:17 AM
@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
05-04-2022 11:26 AM
@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.
05-04-2022 11:53 AM - edited 05-04-2022 11:53 AM
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?
05-04-2022 12:01 PM
@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?
05-04-2022 12:14 PM
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.
05-04-2022 12:23 PM
@Leftz then it probably isn't in use and disabling aggressive mode is not the cause of the problem.
05-04-2022 12:32 PM - edited 05-04-2022 12:41 PM
@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?
05-04-2022 12:46 PM
@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.
05-05-2022 07:39 AM
Thank you Rob. after shutdown tunnel, the issue resolved.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide