04-28-2009 07:20 AM
I had a LAN-to-LAN VPN set up to another organization. There is no longer a need for the VPN tunnel, and I have removed all traces of it from my ASA. However, the other organization still has the VPN configured, and this former VPN peer is still sending traffic to my ASA, causing the following series of messages in the log:
Apr 27 03:49:22 [192.168.53.254.2.2] %ASA-4-713903: Group = X, IP = X, Can't find a valid tunnel group, aborting...!
Apr 27 03:49:22 [192.168.53.254.2.2] %ASA-3-713902: Group = X, IP = X, Removing peer from peer table failed, no match!
Apr 27 03:49:22 [192.168.53.254.2.2] %ASA-4-713903: Group = X, IP = X, Error: Unable to remove PeerTblEntry
Apr 27 03:49:27 [192.168.53.254.2.2] %ASA-4-713903: IP = X, Header in
valid, missing SA payload! (next payload = 4)
I would like to eliminate these messages from my ASA's log, as I have no control over when, if ever, the remote entitiy will stop sending this traffic to my ASA.
I have tried several blocking access-list rules to try and block this traffic, but the rules are never matched (hit count is always 0). Below are examples of the rules I have tried:
access-list OUTSIDE_IN line 1 extended deny udp X eq isakmp any (hitcnt=0)
access-list OUTSIDE_IN line 2 extended deny ip host X host 'myASA IP' (hitcnt=0)
access-list OUTSIDE_IN line 6 extended deny ip host X any (hitcnt=0)
I suspect that this ISAKMP traffic is bypassing the access list so that the packet can attempt to be decrypted before an access-list is applied.
Is there any way to block this ISAKMP traffic from the former VPN peer without affecting any other ISAKMP traffic?
04-28-2009 12:49 PM
You could create a static route for that host to null0 in our upstream router (assuming you have one). I can't think of a way on the ASA.
ip route x.x.x.x 255.255.255.255 null0
04-28-2009 03:44 PM
Thanks for the reply; the null route is a good idea, but I received the following suggestion on how to do it on the ASA:
Due to the command sysopt connection permit-vpn the IPSEc traffic bypasses
the ACL on the outside interface and therefore the rules you configured are
not taking effect.
To allow the ACL on the outside interface to block the IPSEC traffic you
would need to remove the sysopt connection permit-vpn command and manually
allow and deny the VPN traffic.
So the access list on the outside interfac should look like this:
Access-list test deny udp host X host Y eq 500
Access-list test deny udp host X host Y eq 4500
Access-list test deny esp host X host Y
Access-list test permit udp any host Y eq 500
Access-list test permit udp any host Y eq 4500
Access-list test permit esp any host Y
Access-list test permit ip a.a.a.a 255.255.255.0 b.b.b.b 255.255.255.0
Access-list test permit ip a1.a1.a1.a1 255.255.255.0 b.b.b.b 255.255.255.0
Access-list test permit ip a2.a2.a2.a2 255.255.255.0 b.b.b.b 255.255.255.0
Access-list test permit ip aN.aN.aN.aN 255.255.255.0 b.b.b.b 255.255.255.0
Where X is the IP address of the undesired remote peer and Y is the public
IP address of your ASA and the a.a.a.a are the valid private networks behind
each valid remote peer and b.b.b.b is your local private network where the
a.a.a.a networks need to go over the VPN tunnel.
Diego Marin.
VPN Team
CISCO TAC Engineer
04-29-2009 05:03 AM
Oh yeah, sysopt. Thanks for posting the resolution.
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