Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

%ASA-7-710006: ESP request discarded from <> to outside_int:

I would be grateful if somebody can help me on the issue I have.

IPSec tunnel comes up only if interesting traffic is started from behind ASA, not from router side.

I configured ASA (8.2.1) using IPSec Wizard for L2L IPSec tunnel. Both ends are static public IPs. Another end is IOS router. Understand this is the simpliest configuration possible.

Still something is wrong

Below is ASA configuraiton concerning IPSec tunnel:

interface GigabitEthernet0/0
nameif inside_int
security-level 100
ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif outside_int
security-level 0
ip address 192.168.2.1 255.255.255.0
!
boot system disk0:/asa821-k8.bin
ftp mode passive
access-list outside_access_in extended permit ip any any
access-list inside_int_nat0_outbound extended permit ip 192.168.100.0 255.255.255.0 192.168.45.0 255.255.255.0
access-list outside_int_1_cryptomap extended permit ip 192.168.100.0 255.255.255.0 192.168.45.0 255.255.255.0
asdm image disk0:/asdm-631.bin
no asdm history enable
arp timeout 14400
nat-control
nat (inside_int) 0 access-list inside_int_nat0_outbound
access-group outside_access_in in interface outside_int
route outside_int 0.0.0.0 0.0.0.0 192.168.2.2 1
route inside_int 192.168.100.0 255.255.255.0 192.168.10.2 1
route inside_int 192.168.101.0 255.255.255.0 192.168.10.2 1
route inside_int 192.168.102.0 255.255.255.0 192.168.10.2 1
route inside_int 192.168.103.0 255.255.255.0 192.168.10.2 1
!
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_int_map 1 match address outside_int_1_cryptomap
crypto map outside_int_map 1 set peer 192.168.2.2
crypto map outside_int_map 1 set transform-set ESP-3DES-MD5
crypto map outside_int_map interface outside_int
crypto isakmp enable outside_int
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
!
group-policy DfltGrpPolicy attributes
vpn-tunnel-protocol IPSec
tunnel-group 192.168.2.2 type ipsec-l2l
tunnel-group 192.168.2.2 ipsec-attributes
pre-shared-key *
isakmp keepalive disable
!
And router:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco123 address 192.168.2.1
!
!
crypto ipsec transform-set STRONG esp-3des esp-md5-hmac
!
crypto map MYMAP 10 ipsec-isakmp
set peer 192.168.2.1
set transform-set STRONG
match address 101
!
!
!
!
interface Loopback0
ip address 192.168.45.1 255.255.255.0
!
interface Ethernet0/0
ip address 192.168.2.2 255.255.255.0
half-duplex
crypto map MYMAP

!

access-list 101 permit ip 192.168.45.0 0.0.0.255 192.168.100.0 0.0.0.255

!

  • VPN
7 REPLIES
Cisco Employee

Re: %ASA-7-710006: ESP request discarded from <> to outside_int:

Hi,

Usually tunnel initiation from one side, is caused by following:

1. If the dynamic map entry on the remote side has the sequence number higher than the static sequence number.

2. if one of the vpn peers (in our case ASA or router) is behind a natting device, and we are not using NAT-T.

3. We have zone-based configuration on the router, which does a inspect on the self-out zone, so that tunnel can be initiated from the router side only (rare to see such config scenario, but possible).

From the config that u have pasted i do not see dynamic map entries, but please do check again for such an entry. Also i see the crypto map on the ASA is applied on the interface outside_int, which has a private ip address. So is there another device in front of the ASA that is doing the natting ? If yes, try using NAT-T.

Also please paste the complete error/log message that you are seeing on the ASA in regards to ESP request discarded...(with ip addresses removed ofcourse)

Let me know if this helps,

Cheers,

Rudresh V

New Member

Re: %ASA-7-710006: ESP request discarded from <> to outside_int:

Hi Rudresh,

Thank you for your prompt answer.

This is not a real life config where we see public IPs but rather a lab setup.

See file attached that shows connection diagram, Router R2 config as well as ASA config.

There is a log message:

%ASA-7-710006: ESP request discarded from 192.168.2.2 to outside_int:192.168.2.1
%ASA-7-710006: ESP request discarded from 192.168.2.2 to outside_int:192.168.2.1
%ASA-7-710006: ESP request discarded from 192.168.2.2 to outside_int:192.168.2.1

New Member

%ASA-7-710006: ESP request discarded from <> to outside_int:

Did you ever get this resolved?  I have the identical scenario and problem:

%ASA-7-710006: ESP request discarded from 10.1.1.2 to outside:10.1.2.1

My only difference is I have a router between my ASA and the router terminating the tunnel.  I can initiate the tunnel from a node on the inside of the ASA but not from a node on the inside of the router.

Mine is currently in a lab environment as well.

New Member

%ASA-7-710006: ESP request discarded from <> to outside_int:

Can you verify if when you are originating traffic from the Router end, you are indeed sourcing from the Loopback interface?

Also, enable the following on the ASA and confirm what you see; i.e. is the tunnel being negotitated?

logging con 7

logging on

debug crypto isakmp 127

debug crypto ipsec 127

Since, the tunnel is terminating on the ASA's outside interface, ESP packets need not be explicitly allowed.

New Member

%ASA-7-710006: ESP request discarded from <> to outside_int:

Thanks for the quick reply.  I solved my problem by adding a policy map to the ASA (see below).  My original ASA (v8.02) configuration did not have a policy-map.  My originating traffic was sourced from the router's inside interface.

class-map inspection_default

match default-inspection-traffic

!

!

policy-map global_policy

class inspection_default

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect esmtp

  inspect sqlnet

  inspect skinny

  inspect sunrpc

  inspect xdmcp

  inspect sip

  inspect netbios

  inspect tftp

  inspect icmp

New Member

%ASA-7-710006: ESP request discarded from <> to outside_int:

Thanks for your response.Your output does not clarify whether you applied the policy globally i.e. service-policy global_policy global. The inspection engine comes into play only when traffic is traversing from a high sec to a low sec level (traffic through the ASA) and has no bearing on traffic terminating at the ASA. In your original statement, the flow of traffic was working when originating from the ASA to the Router but not other wise even before you defined this global_policy. The latter (Rtr to ASA) should not hit the inspection engine. I am not discounting what you did to resolve it, but it doesn't resonate the ASA's logic. Glad it is working though. I did mimick your configuration on an ASA 5505 (8.4) w/o an inspection engine and was able to make it work.

New Member

Re: %ASA-7-710006: ESP request discarded from <> to outside_int:

I agree about the service policy should not have a bearing on the terminating traffic.  I applied it globally:

service-policy global_policy global

I believe my testing process was flawed as I just now tested again by removing the service policy and it works.  I need to review my settings as I changed many variables (MD5 vs SHA, DES vs 3DES, interesting traffic ACL, various IOS versions) and may have been fooled by something lingering.

I will attempt to break it and report back.

[EDIT]

I reverted back to my original configuration and found one side had PFS set and the other side did not.  I am not sure at what point in my configuration changes I noticed the error message "ASA-7-710006: ESP request discarded from ..." but I am almost sure this was not my original error.  I was able to create this error my having the hash misaligned (one side SHA, the other side MD5).

I believe I was decieved by the router not displaying the default values (HASH, LIFETIME, etc) in a sho run, out of sight out of mind.  Darn those default values, I've got to quit relying on show run.

I now have eveything working as it should.   I was also able to make this work in GNS3 with ASA8.0(2) and ASA8.4(2).  I've attached a snippit of the configs and my GNS3 diagram.  There are more comprehensice configurations on cisco.com with explanations.

9944
Views
0
Helpful
7
Replies
This widget could not be displayed.