Arul,

You mean remove

ip nat inside source list 1 interface FastEthernet0/0 overload? I thought this line is for internet NAT ( 192.168.0.0). Thanks

Well, for your traffic from the LAN to go back to the VPN Client pool of IP Addresses, you need to bypass NAT.

So, you need to remove the existing "ip nat ..." configuration and configure the one that I had posted in my previous post.

That statement will make sure that NAT is bypassed only for VPN Client and all other traffic will get NATTed. Give it a shot and let me know how it goes.

Regards,

Arul

** Please rate all helpful posts **

Arul,

I did it but still no luck. Here is the error. *Mar 1 00:27:19.047: %SEC-6-IPACCESSLOGP: list outside denied udp 192.168.100.1

03(1643) -> 192.168.0.20(53), 1 packet

*Mar 1 00:27:22.635: %SEC-6-IPACCESSLOGP: list outside denied udp 192.168.100.1

03(1174) -> 192.168.0.20(53), 1 packet

Cisco#

*Mar 1 00:28:04.787: %SEC-6-IPACCESSLOGDP: list outside denied icmp 192.168.100

.102 -> 192.168.0.20 (8/0), 14 packets

Interesting. Can you add this statement to your extended access-list and let me know if it works. Make sure the statement is before your Deny any any statement.

permit ip 192.168.100.0 0.0.0.255 192.168.0.0 0.0.0.255

Regards,

Arul

** Please rate helpful posts **

Arul,

That acl allow me to ping successfully but still can't access anything inside the LAN. Also the public interface respond not the inside interface.

C:\ping 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=804ms TTL=255

Reply from 1.1.1.1: bytes=32 time=402ms TTL=255

Reply from 1.1.1.1: bytes=32 time=583ms TTL=255

Reply from 1.1.1.1: bytes=32 time=303ms TTL=255

Can you post your current configuration from the router. Also, did you do a "clear ip nat translations" and test the VPN Client.

Once you are VPNed into the router, can you post the outputs of "show cry is sa" and "show cry ips sa" when you try to access something on the LAN.

Regards,

Arul

** Please rate helpful posts **

interface: FastEthernet0/0

Crypto map tag: avi, local addr. 1.1.1.1

protected vrf:

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (192.168.100.102/255.255.255.255/0/0)

current_peer: 74.95.200.9:1152

PERMIT, flags={}

#pkts encaps: 71, #pkts encrypt: 71, #pkts digest 71

#pkts decaps: 184, #pkts decrypt: 184, #pkts verify 184

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 1.1.1.1, remote crypto endpt.: 74.95.200.9

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0

current outbound spi: BFF48B33

inbound esp sas:

spi: 0x6AF3BD49(1794358601)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel UDP-Encaps, }

slot: 0, conn id: 2000, flow_id: 1, crypto map: avi

sa timing: remaining key lifetime (k/sec): (4518802/3533)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xBFF48B33(3220474675)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel UDP-Encaps, }

slot: 0, conn id: 2001, flow_id: 2, crypto map: avi

sa timing: remaining key lifetime (k/sec): (4518818/3532)

IV size: 8 bytes

replay detection support: Y

outbound ah sas:

outbound pcp sas:

Ok, I still dont see this line configured as per Previous e mail.

permit ip 192.168.100.0 0.0.0.255 192.168.0.0 0.0.0.255

The reason I ask you to do this is very simple, I dont remember the exact version, but IOS used to behave in such a way that after the packets are decrypted on the router, if there are any ACL applied inbound, the traffic will be inspected against the ACL. Since, you are not allowing permit ip 192.168.100.0 0.0.0.255 192.168.0.0 0.0.0.255 explicitly on the ACL, traffic could be very well decrypted and denied by the ACL.

Regards,

Arul

** Please rate helpful posts **

It worked!. I remember I did added it but still didn't work that's why I removed it. Since we enable 192.168.100.0 to 192.168.0.0 is this secure? Thanks

Great! :-))

Since we enable 192.168.100.0 to 192.168.0.0 is this secure? Well, in my world, I would consider it less secure but I have seen people argue both ways. So, if you think this is not secure in your environment, I would upgrade the chassis to a 12.4 Mainline code and then there should be no need to configure this ACL. I know the bug was fixed in some 12.3T Train but not sure which one. 12.4 should address this behavior.

Also, if you dont mind, can you let the forum know that the response resolve the issue, so it is beneficial for others when they run into similar issues. Thanks!

Regards,

Arul

** Please rate all helpful posts **

Hello, For some reason I can't ping from the router to IP VPN pool when the client connected. Ex. 192.168.100.100. Firewall on windows has turned off but still can't ping. Thanks