Cisco ASA Clients connects to VPN but no route inside, need some help?

[zafnath]

Hello Everyone...!

I have a Cisco ASA running IOS Version 8.0(4) everyone in my company connects good throug the VPN Clients connect, but they don´t have routing.

I´m wondering why the connnect to the VPN and then don´t have any traffic inside.

Need some tips..

[Jitendriya Athavale]

try the following

icmp permit any inside

i see you have logging buffered deb thats good

clear logging buffered

managemant-access inside

from the client

ping insid einterface ip

show logg | in

[Jitendriya Athavale]

also once you are connectde through the vpn

give show route command and verify that you see a static route to the vpn cient ip pointing to outside interface

[zafnath]

Nothing  Happen with this...

Fw(config)# icmp permit any inside

Fw(config)# sh logg | in 10.XX.XX.0

But no output

[Jitendriya Athavale]

Fw(config)# sh logg | in 10.XX.XX.0

thios would be incorrect

Fw(config)# sh logg | in 10.XX.XX.13 something like this or just leave it at xx do not enter the last octet

[zafnath]

Here we go with the sceenshoots of the stats.

[Namit Agarwal]

Hi ,

Thanks a ton for the outputs. It clearly shows from the statistics on the VPN Client and the outputs on the ASA that the ASA is receiving the packets across the tunnel decrypting but the replies are not being encrypted. Please paste the output of the following command

packet-tracer input inside icmp 8 0 < IP address from the remote pool assigned to the PC connected to VPN>

Thanks,

Namit

[Jitendriya Athavale]

as the packet tracer says it being dropped in nat rules

please past eyour nat rules

show run nat

show run global

sh run static

sh access-list

[Namit Agarwal]

Hi ,

Do your remote pool subnet and the subnet for the internal network for the ASA overlap ? I mean is it something like that the remote pool is 192.168.1.1-192.168.1.25 and the internal subnet on the ASA is 192.168.1.0/24.

Thanks,

Namit

[zafnath]

After a while of troubleshooting with my networking  team, we found that the packet is drop it at the end .

Now we need to find out why is doing that.

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (ipsec-spoof) IPSEC Spoof detected

[Jitendriya Athavale]

did you make any changes to the rules in firewall bcoz i see the packet tracer outputs look to be different

also have you verifed that the vpn pool ip and the internal network ip do not overlap

[zafnath]

no i didnt a change...anything I will delete the conection profile and I will doit again.

[zafnath]

How Come...!!!! This is a Black Magic...!!!!!!

I made a fullbackup of JUN2010 and the problem persist.....!!! What!!!!!!!

[zafnath]

FOR THE RECORDS HERE IS THE ANSWER.....!!!!

I made a new IP-Pool with a diferent network  avoiding use the same IP Addressing of my Inside Network and applying it to the Group Policy. This is the only change that i made to the firewall.

In the Core SW I made a static route of the new network with the Inside Firewall Interface as a gateway of the last resort.

and Done it works!!!!