only 1 subnet can access remote peer network

jigz.bagsicjr · ‎02-27-2007

Team,

I have a router 3845 running NAT as well site-to-site vpn to singapore concentrator. The E0 from my router is connected to my core switch where my LAN subnets are 172.22.195.0/24; 172.22.192.128/26 and 172.22.200.0/21. Now i can see the tunnel is up and route to the remote peer. now my problem is only 172.22.195.0/24 (vlan for servers) and 172.22.192.128/26 (vlan for switch management) can access the host in singapore, the 172.22.200.0/21 subnets from my lan has a request time out or no access at all to singapore. i'll attached my config here.

for concentrator config:

interface: E2 A.A.A.178

Peer: B.B.B.74

Digital certificate: NONE(used preshared keys)

Transmission: Identity certificate only

PReshared Key: <string>

Authentication: ESP/MD5/HMAC-128

Encryption: 3DES-168

IKE proposal: IKE-3DES-MD5

Filter: NONE

IPsecNAT-T: value is uncheck

Bandwith Policy: NONE

Routing: NONE

***Local network Subnets***

172.22.40.0/0.0.0.255

172.22.41.0/0.0.0.255

172.22.42.0/0.0.0.255

172.22.43.0/0.0.0.255

172.22.44.0/0.0.0.255

172.22.45.0/0.0.0.255

172.22.46.0/0.0.0.255

172.22.47.0/0.0.0.255

172.22.48.0/0.0.0.255

172.22.49.0/0.0.0.255

***remote peer LAN***

172.22.192.0/0.0.0.255

172.22.193.0/0.0.0.255

172.22.194.0/0.0.0.255

172.22.195.0/0.0.0.255

172.22.196.0/0.0.0.255

172.22.197.0/0.0.0.255

172.22.198.0/0.0.0.255

172.22.199.0/0.0.0.255

172.22.200.0/0.0.0.255

thanks..

Ajit Singh · ‎02-27-2007

Hi,

As the crypto ACL, defining interesting traffic:

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.40.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.41.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.42.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.43.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.44.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.45.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.46.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.47.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.48.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.22.49.0 0.0.0.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.20.0.0 0.0.255.255

access-list 120 permit ip 172.22.192.0 0.0.15.255 172.21.0.0 0.0.255.255

I do not see any rule which permits 172.22.200.0 to access the remote networks (172.22.4x.0).

I believe we need to add the entries in access-list 120 and allow a nat bypass in 121 for .200 subnet.

Moreover, if the above configurations are taken into account, kindly check the ipsec SA's to encrypted/decrypted packet (sh cry ipsec sa).

Once u see the SA's created for the two subnets nd do not see proper encrypts/decrypts, it will be routing issue.

Regards,

Ajit Singh

jigz.bagsicjr · ‎02-28-2007

Hi,

My knowledge was set into that .200 subnets is already part of the 172.22.192.0 0.0.15.255 definition in the cyrpto ACL(in short summarized network). i also tried to break them down in per subnets and it works fine (meaning all of my subnets was able to access the remote LAN subnets of vpn concentrator including the .200 ; .193 and others.) however as the 4 hours past the the .200 and .193 subnets were getting request timeout and what has been consistent is the .195 and .192 subnets to access the remote LAN. do you have any idea on this issue?

I really appreaciate any idea to resolve this issue.

Thanks

Jigz

jigz.bagsicjr · ‎02-28-2007

Hi,

once i received the message on my router -->

%CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has in

valid spi for destaddr=R.R.R.74, prot=50,

spi=0x33B49ACE(867474126), srcadd

r=C.C5.C.178

that the time i got a request time out on .200 subnet.

note:

R- is router

C- is concentrator

Regards,

Jigz

kaachary · ‎02-28-2007

Hi,

I would suggest to correct the config first. The remote LAN on the concentrator should be only one subnet . i.e.

172.22.192.0/0.0.15.255

Like you have defined it on the Router.

Try this and see if it helps.

-Kanishka

jigz.bagsicjr · ‎02-28-2007

Hi,

Yes i did, however it gave me the same issue. Just a while ago, when i tried to run clear crypto session on the router, then the .200 subnets works but whent i recieved the error below that is the time it failed. Then i keep on repeating clearing the crypto session for .200 works.

%CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has in

valid spi for destaddr=222.127.40.74, prot=50, spi=0x33B49ACE(867474126), srcadd

r=203.125.182.178

%CRYPTO-4-IKMP_NO_SA: IKE message from C.C.C.178 has no SA and is not an initialization offer

Regards,

Jigz

blakem · ‎06-14-2007

I would like to add that I've got a similar problem on my 2851 routers.

When I make changes to the crypto ACL's the IPSEC SA's don't reflect the new source and destination addresses (they still show the source and destinations from the old ACL's).

So I try to bring down the ISAKMP and IPSEC SA's with the following commands (but with no effect):

clear crypto isakmp

clear crypto sa peer (peer address)

clear crypto spi (peer address) esp (spi number)

clear crypto session remote (peer address)

The only way I am able to bring down the SA completely is to bring down all the SA's (through clear crypto sa). This is not ideal as I have other tunnels I don't want to bring down.

Obviously if I don't manage to bring down the old SA's I get 'decrypted packet failed SA identity check' error.

If anyone knows why the commands I tried to bring down tunnels individually don't work, I'd really appreciate some advice!