L2L VPN, but the ping fails.

[JustTakeTheFirstStep]

Configured an L2L VPN, but the ping fail.

Can you see what's the problem??

Please check the files

[Rob Ingram]

The output seems to confirm that you are sending and receiving packets.
Is 172.29.2.1 the IP address of the peer ASA? Ping through the ASA to another device rather than the ASA itself.

[JustTakeTheFirstStep]

Attach the diagram.
2.1 is the inside IP of the ASA.
In addition, the BR-4 image is also attached, so please check it.

[Rob Ingram]

So you are testing from HQ?

You should always test connectivity of a VPN, by connecting to a device on the inside of the ASA, rather than test "to" the ASA. However you can configure the command "management-access INSIDE" (assuming the interface name is INSIDE) to permit icmp and ssh, http management via the inside interface over a VPN tunnel.

So can you ping a device on the inside of the ASA? The switch 172.29.2.13?

[JustTakeTheFirstStep]

SangHai-OF-ASA# sh int ip b
GigabitEthernet1/1 58.246.2.50 YES CONFIG up up
GigabitEthernet1/2 172.29.2.1 YES CONFIG up up

SangHai-OF-ASA# ping 172.29.2.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.29.2.13, timeout is 2 seconds:
!!!!!

[Rob Ingram]

Ok, so that confirms the tunnel is up and working for traffic "through" the ASA.
As previously mentioned you would need the "management-access <interface>" command configured to be able to ping the ASA itself over the VPN tunnel.

[JustTakeTheFirstStep]

SangHai-OF-ASA(config)# management-access inside
But still the ping fails.

[Rob Ingram]

You are going to have to provide more information in order to help you.
Was the source of the ping the PC connect to the inside of the HQ ASA or from the HQ ASA itself?
Do you filter traffic from pinging the remote ASA with the "icmp" command?
I assume the interface you are attempting to ping is named "inside"?

[JustTakeTheFirstStep]

SW(172.29.2.13) - BR ASA ------------------ HQ ASA - PC172.16.0.0

plz help me

[Rob Ingram]

---

@JustTakeTheFirstStep wrote:

SW(172.29.2.13) - BR ASA ------------------ HQ ASA - PC172.16.0.0

plz help me

---

You previously confirmed you could ping the switch 172.29.2.13, so it's working

[JustTakeTheFirstStep]

No. That is not an tried to ping the 172.29 network from HQ. The 172.29 network does not ping with HQ. You check hostname

[Rob Ingram]

In your output text files you are running ping/traceroute from the ASA.

VPN-ASA-HQ# ping 172.29.2.1 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.29.2.1, timeout is 2 seconds:
?????

VPN-ASA-HQ# traceroute 172.29.2.1

Type escape sequence to abort.
Tracing the route to 172.29.2.1

1 172.30.1.2 1 msec 1 msec 1 msec
2 * *

...so the source will not be from an IP address defined in the crypto ACL - therefore traffic will not be encrypted.

In you last message you said "SW(172.29.2.13) - BR ASA ------------------ HQ ASA - PC172.16.0.0" which is not testing from the ASA (as per your logs). The information you are providing is confusing, not helpful and doesn't help me help you.

Test a VPN by sending traffic "through" the VPN, to a device behind the peer ASA.

[Marius Gunnerud]

Do you have routing /default route configured on the switches behind the ASAs? If yes, do the routes point to, the ASA or somewhere else?

If you are testing ping over VPN from the ASA, as Rob has mentioned you need the command management-access <interface> (where interface is the name of the source interface) and make sure the IP or subnet of that interface is allowed over the VPN in the crypto ACL.  Then when pinging from the ASA specify the source interface...for example ping inside 172.29.2.13

You are missing "inspect ICMP" command in the policy map on the Sanghai ASA and it doesn't look like you have a policy map configured on the HQ ASA.  I suggest adding inspect ICMP to Sanghai and copy paste the Sanghai policy map to the HQ ASA. and then test. (see red text below)

class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options

inspect icmp
!
service-policy global_policy global

[JustTakeTheFirstStep]

Hi.
Thank you for your interest in my question.
I don't know why, but L2L works fine now.
I think maybe backbone routing is the problem.
I've modified the settings many times so I don't know exactly what was causing it.
God bless you