Thanks a lot for your valuable input... Heres the running-config and also a brief comment on whats going on here...

172.4.4.0/24-->VPN3000----ISP----1841<--192.168.2.0/24

The VPN3000 will be the one triggering the VPN tunnel setup.

Remote host 172.4.4.5 will be querying a local database at 192.168.2.14:1000

According to my "remote peer" specifications I have to NAT the local address 192.168.2.14

to the Global address 172.17.0.65 in order for the VPN 3000 to accept returing packets.

As far as I know thats how they've implemented their ACLs in the VPN 3000.

Thats the reason for the static NAT entry in the running-config and thats also the reason for the

ACL 101.

Please let me know if this scenario is clear enough or if you need additional input from my side. Again, thx a bunch

***********************************************************************************************

UACA-VPN#show running-config

Building configuration...

Current configuration : 2550 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname UACA-VPN

!

boot-start-marker

boot-end-marker

!

enable secret 5 $1$n8of$osX1TuEuCWxuhMXwNp3WQ0

!

no aaa new-model

!

resource policy

!

no ip source-route

ip cef

!

!

!

!

no ip bootp server

no ip domain lookup

!

!

!

!

!IKE Phase 1 parameters

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

crypto isakmp key 6 ***** address 200.122.146.39

!

!IPSec phase 2 parameters

!

crypto ipsec transform-set ENLACE-UACA-BNCR esp-3des esp-sha-hmac

!

crypto map ENLACE-UACA-BNCR 10 ipsec-isakmp

set peer 200.122.146.39

set peer 200.91.79.6

set transform-set ENLACE-UACA-BNCR

!traffic to encrypt according to ACL 101

!

match address 101

!

!

interface FastEthernet0/0

description WAN interface. Local peer for VPN tunnel setup

ip address 201.196.33.30 255.255.255.248

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

crypto map ENLACE-UACA-BNCR

!

interface FastEthernet0/1

description LAN interface

ip address 192.168.2.4 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

!

!

interface Serial0/1/0

no ip address

shutdown

clock rate 2000000

!

interface Vlan1

no ip address

!

ip route 0.0.0.0 0.0.0.0 201.196.33.25

!

!

no ip http server

no ip http secure-server

!

ip nat inside source static 192.168.2.14 172.17.0.65

!

!

!

access-list 101 permit ip 172.4.4.0 0.0.0.255 172.17.0.64 0.0.0.7

access-list 101 permit tcp host 172.4.4.5 host 172.17.0.65 eq 1000

access-list 101 permit udp host 172.4.4.5 host 172.17.0.65 eq 1000

access-list 101 permit icmp any any echo

access-list 101 permit icmp any any echo-reply

!

!

!

control-plane

!

!

!

line con 0

logging synchronous

line aux 0

line vty 0 4

password 7 08146D6D285413071C

login

!

scheduler allocate 20000 1000

end

***********************************************************************************************

Glenn

The original question is now easy to answer. As I suggested in my first response the access list that identifies traffic for IPSec includes your ping traffic:

access-list 101 permit icmp any any echo

access-list 101 permit icmp any any echo-reply

so the router will take any ping request or any ping response and try to put it through the IPSec process. And that will prevent ping from working to the local subnet (and probably to anywhere else as well). Was there a reason to identify all ping traffic this way. It seems to me that since everything else in the access list is related to 172.4.4 that it would be reasonable to identify ping that way.

I am not sure that I understand the business about translating the address. And if you are going to translate one specific host then I am puzzled why the access list starts by identifying a whole subnet:

access-list 101 permit ip 172.4.4.0 0.0.0.255 172.17.0.64 0.0.0.7

access-list 101 permit tcp host 172.4.4.5 host 172.17.0.65 eq 1000

access-list 101 permit udp host 172.4.4.5 host 172.17.0.65 eq 1000

I also note that given this access list that the second and third statements are more specific matches for what will match in the first statement and therefore are redundant.

HTH

Rick

Thanks for your reply it worked as soon as I removed those entries from the ACL.

Now the whole deal about the translation goes like this (I'll try to explain it the easiest way)

The NetAdmin for the VPN 3000 has configured the ACLs to ONLY permit TCP and UDP traffic with source address of 172.17.0.65. Thats why I have to statically NAT my local address of 192.168.2.14 to the global address of 172.17.0.65. I'm natting and then encrypting the nat'd traffic

Now, why am I configuring an ACL for a whole subnet ? Because the NetAdmin on the VPN 3000 specifically warned me about including that entry when configuring the ACL (according to his version we needed in order to allow some other traffic for testing porpoises)

I hope this whole thing is a little bit clearer to you now... let me know if you'd like additional info.

I'm about to start testing so I might be calling for help... ;)

thx again

Glenn

You know what the admin asked you to do, and if he asked for the subnet definition then that probably is what you should do. But since you are only translating a single address if they were to send you traffic for some address in that subnet I believe that you would discard it.

At this point probably the best thing to do is to test and see what works. If there are other issues let us know.

HTH

Rick

I will and I'll let you guys know...

Thanks a bunch for your help Rick

Glenn