Getting a IPSec VPN up on two 2600Series Routers

[cbvisser1]

I'm trying to set-up a VPN between two 2600 routers. On router1 the ip address is 192.168.7.1 On router2 192.168.6.3. For testing purposes I have a 1700 router in between them and they are connected with T1 DSU/CSU WIC Cards with crossover t1 cables. In SDM, everything checks out with my VPN Troubleshooting except for Checking peer connectivity… which fails for both. The failure reason states “The following source is routed through the crypto map interface. 192.168.6.3” Recommended Action(s) says “Go to Configure -> Routing and correct the routing table.”

My routing table is

0.0.0.0 0.0.0.0 serial0/0

0.0.0.0 0.0.0.0 fa0/0

I tried putting in the individual routes put nothing seems to work.

Here is my current running config for Router 192.168.7.1

Building configuration...

Current configuration : 1619 bytes

!

version 12.3

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

crypto isakmp key ****** address 192.168.6.3

crypto isakmp xauth timeout 15

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

!

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to192.168.6.3

set peer 192.168.6.3

set transform-set ESP-3DES-SHA

match address 100

!

interface FastEthernet0/0

ip address 192.168.12.1 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0

description T1toLTC

ip address 192.168.7.1 255.255.255.0

crypto map SDM_CMAP_1

!

ip http server

ip http secure-server

ip classless

ip route 0.0.0.0 0.0.0.0 Serial0/0

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

ip route 192.168.7.1 255.255.255.255 Serial0/0

!

!

access-list 100 remark SDM_ACL Category=4

access-list 100 remark IPSec Rule

access-list 100 permit ip any any

access-list 100 permit tcp any any

!

This is the error message that I'm also getting

07:17:45: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 192.168.6.3

[andrew.prince]

your routes are wrong, remove:-

ip route 0.0.0.0 0.0.0.0 Serial0/0

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

ip route 192.168.7.1 255.255.255.255 Serial0/0

then configure:-

ip route 192.168.6.0 255.255.255.0 serial 0/0

[cbvisser1]

The VPN is up and running thank you. My next problem is the following error message occurs in SDM when I check the tunnel:

Failure Reason:

A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets.

Recommended Action:

1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.

Any Ideas?

Also I keep receiving in the CLI a message that says:

1w0d: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.

(ip) vrf/dest_addr= /224.0.0.9, src_addr= 192.168.7.2, prot= 17

Would that have something to do with the ACL permitting any any?

Thanks so much for all your help

[andrew.prince]

What is your interface mtu set at? setting the DF bit does not allow fragmentation - you have some options, but it's better to sort out the interface MTU first.

The acl is receiving a muticast packet, from 192.168.7.2 - what device is 192.168.7.2???

[cbvisser1]

What is the interface mtu? I'm a little confused with that. I'm guessing I don't have it set then.

192.168.7.2 is the ip address of one of my T1 cards of my middle router between my VPN. I set it up with two 2600 series attached to a single 1700 series router via cross-over T1 cards for testing purposes.

[andrew.prince]

mtu = maximum transmissible unit, so ALL data including data payload, IP header & layer 2 header.

sho int > will tell you the interface mtu.

then you can work out your mss - maximum segment size = the max amount of data you can send without transmission overhead.

TCP header = 20 bytes

IP header = 20 bytes

IPsec header = 56 bytes

layer 2 headr ?? = depends on the technology, Ethernet, ATM, Serial etc

possible total overhead = 96 bytes

Total left for data 1404 byte PER PACKet - without layer 2 header added.

OK - sounds like you have a dynamic roiuting protocol in the mix, and it just so happens that you may be using the same source/destination IP addresses for you VPN tunnel?

[cbvisser1]

My MTUs are set-up at 1500 bytes.

The other question that I have is now that I have the VPN set-up between the serial ports, can I get my inside networks off the fa0/0 to see each other. When I try to ping them they say destination host unreachable.

The dynamic routing protocol that I have running is RIP version 2 and yes I was using the same source/destination IP addresses.

[andrew.prince]

OK - this just means you need to drop the ping packet size down to say 1300 when you set the df bit.

Yes - you have two options, static routes or a duynamic routing protocol. Of you want a dynamic routing protocol, you need to encapsulate it in a GRE tunnel.

That explains the hit on the acl - you can ignore this.

[Wilson Samuel]

I think your Crypto ACL should include only the traffic that must be encrypted i.e. the network that has been configured on both the LAN Interfaces.

I guess, if you do try to encrypt ANY ANY traffic, even the traffic that should otherwise go unencrypted point to point in the Serial/T1 inteface also might get try to get encrypted and resulting in failure of the Tunnel establishment.

HTH,

Please rate if it does help

Regards

Wilson Samuel

[John Blakley]

Can you post the debug from:

debug crypto isakmp

and the config from the other router?

HTH,

John

[Richard Burts]

Chad

I agree that having 2 default routes configured pointing to different outbound interfaces is probably problematic:

ip route 0.0.0.0 0.0.0.0 Serial0/0

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

and should be corrected. A key question to ask yourself in this is if the router needs to route packets to a destination that does not appear in the routing table, then to whom should you send it? This will guide you in getting a correct default route.

I also agree that having the access list used in the crypto map specify permit ip any any is problematic and should be changed.

In addition, from reading your original post I would ask the question of whether you really have ip connectivity to the peer router. From this router can you ping to 192.168.6.3? And from the 192.168.6.3 router can you ping this router?

HTH

Rick