Re: IPSec with dynamic TED not working ???

ewei · ‎01-12-2005

Hello, everyone

I have a config with IPSec/TED. It works great from non-dynamic map side, but, it has difficulty in probe packets setting up peer from TED side(R8) to R4.

It gives me error said "Rec'd packet not an IPSEC packet". I believe the access-list may not be symmetrically mirror, but it does (see config below)

also, the interesting traffics are in routing table...

Any idea will be appreciated

8.8.8.0 -- R8 ---- WAN --- R2-- 2.2.2.0

R8

crypto isakmp policy 10

hash md5

authentication pre-share

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

!

crypto ipsec transform-set ted esp-des esp-sha-hmac

!

crypto dynamic-map test 10

set transform-set ted

match address 107

!

crypto map test1 10 ipsec-isakmp dynamic test discover

interface Tunnel0

ip address 18.1.x.x.x.255.0

no ip route-cache

no ip mroute-cache

tunnel source FastEthernet0/0

tunnel destination 143.1.46.1

crypto map test1

!

interface serial 0/0

ip address 143.1.x.x.x.255.252

crypto map test1

router eigrp 10

network 8.8.8.0 0.0.0.255

network 18.1.1.0 0.0.0.255

network 143.1.46.0 0.0.0.3

access-list 107 permit ip 8.8.8.0 0.0.0.255 2.2.2.0 0.0.0.255

R2

crypto isakmp policy 10

hash md5

authentication pre-share

crypto isakmp key cisco address x.x.x.x

!

crypto ipsec transform-set ted esp-des esp-sha-hmac

!

crypto map test1 10 ipsec-isakmp

set peer 143.1.46.2

set transform-set ted

match address 107

interface Loopback1

ip address 2.2.x.x.x.255.0

interface Tunnel2

ip address 18.1.x.x.x.255.0

no ip route-cache

no ip mroute-cache

tunnel source s0/0

tunnel destination 143.x.x.2

crypto map test1

interface Serial0/0

ip address 143.1.x.x.x.255.252

crypto map test1

router eigrp 10

network 2.2.x.x.x.0.255

network 18.1.x.x.x.0.255

network 143.x.x.x.0.0.3

access-list 107 permit ip 2.2.2.0 0.0.0.255 8.8.8.0 0.0.0.255

gfullage · ‎01-12-2005

For TED to work both ends need to be configured for it, otherwise the statically configured router is not going to reply to the IKE Discover packet that the initiating router sends out. The way it's working now, with R2 initiating the tunnel, is not actually using TED at all.

Set up R2 with a dynamic crypto map and TED (the same as R8) and you should be fine.

See http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094832.shtml for details.

ewei · ‎01-13-2005

thanks your reply

but, I would respectfully disagree your thought.

The purpose of TED is to reduce static map each peers on a hub and spoke or fully mesh environment. If both sides need to be TED, then, the probe packets from all the sites will take cpu and bandwidth. I do'nt think Cisco intend to do this.

Let me know what you think. I may be wrong

gfullage · ‎01-13-2005

The whole point of TED is that you don't need to statically define peers, you use dynamic crypto maps with TED enabled. The only additional overhead is one IKE probe and reply packet sent out whenever a new tunnel is built. After that it is exactly like a standard IPSec tunnel.

The way you have it configured at the moment, TED is NOT enabled on the statically defined router, and therefore it's not going to listen to the IKE Probe packet. TED needs to be configured on both sides for the two routers to communicate properly.

TED is described in detail here:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087a9a.html

Note the Feature Overview section:

With TED, only a single dynamic crypto map with TED enabled is needed because the peer is discovered dynamically. Thus, static crypto maps do not need to be configured for each peer.

And note the Restriction section:

It is available only on dynamic crypto maps.

ewei · ‎01-14-2005

thanks your explanations. It does make sense.

The static map side does not respond probes will not be able to establish tunnel.The probe packets contains all the ip info in the payload, which the static side does not understand, and it discards.

That is why I see the error messages that receiving packets not encrypted.

Thanks again for your help

mhoda · ‎01-13-2005

Hello,

Shouldn't your ACL include the GRE traffic instead?

Thanks,

Mynul

ewei · ‎01-13-2005

thanks your reply

I tried that too, but it is still the same