03-07-2014 11:00 PM - edited 02-21-2020 07:33 PM
Hi everyone,
I can connect to cisco anyconenct fine no issues.
When connected i can ping the ASA inside interface and other subnets which are behind the ASAs inside interface from the the PC connected via VPN.
My only issue is that from ASA i can not ping IP 10.0.0.5.
ASA1# sh vpn-sessiondb anyconnect
Session Type: AnyConnect
Username : anyconnect_user Index : 54
Assigned IP : 10.0.0.5 Public IP : 192.168.98.2
Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License : AnyConnect Essentials
Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)AES128 DTLS-Tunnel: (1)AES128
Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1 DTLS-Tunnel: (1)SHA1
Bytes Tx : 12318 Bytes Rx : 73502
Group Policy : anyconnect_group
Tunnel Group : anyconnect_connection_profile
Login Time : 23:21:28 MST Fri Mar 7 2014
Duration : 0h:34m:33s
Inactivity : 0h:00m:00s
NAC Result : Unknown
VLAN Mapping : N/A VLAN : none
I can ping the switch connected to ASA inside interface
ASA1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
i can ping the ASA inside interface
ASA1# ping 10.0.0.1-------------------------------------------ASA inside interface
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
ASA1# ping 10.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.5, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
ASA1#
Log shows
Mar 07 2014 23:00:52: %ASA-6-302020: Built outbound ICMP connection for faddr 10.0.0.5/0(LOCAL\anyconnect_user) gaddr 192.168.1.171/1168 laddr 192.168.1.171/1168
Mar 07 2014 23:01:02: %ASA-6-302021: Teardown ICMP connection for faddr 10.0.0.5/0(LOCAL\anyconnect_user) gaddr 192.168.1.171/1168 laddr 192.168.1.171/1168
Where IP 192.168.1.171 is ASA outside interface
Regards
MAhesh
Solved! Go to Solution.
03-08-2014 02:25 PM
Hello Mahesh,
Have you tried to ping from the inside network? Or source the packet from the inside interface of the ASA? Remember, that you should have some nat exemption rules for the packets going through the VPN connection. That's how we specify what networks are allowed to reach the VPN clients. If you ping without specifying any interface the packet will be sourced from the outside interface and probably that interface/subnet is not allowed through the VPN connection. Are you using split-tunnel or tunnelall?
You could try to enable management-access on the inside interface and the ping sourced from the inside. These packets should hit the nat exemption rule and will be sent through the tunnel instead of the Internet.
This are the commands needed:
To specify an interface as a management-only interface, enter the following command:
hostname(config)# management access inside
Then you could do a ping inside 10.0.0.5 in order to ping the AnyConnect client from the ASA.
Notes about management access command:
If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you can identify that interface as a management-access interface. For example, if you enter the ASA from the outside interface, this feature lets you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface when entering from the outside interface. Management access is available via the following VPN tunnel types: IPsec clients, IPsec LAN-to-LAN, and the AnyConnect SSL VPN client.
Hope this helps,
Luis
03-12-2014 11:30 PM
Hello Mahesh,
Great to hear that everything is working fine!
Basically, when you tried to ping the VPN client subnet (10.0.0.0/24) the packet was being sourced from the Outside interface of the ASA, however, this ip/subnet was not allowed to go through the VPN connection because it was not included on the split tunnel ACL. Remember that the split tunnel ACL is used to specify the networks reachable through the VPN tunnel. If the network or ip address is not included the packets will be sent through the Internet instead of the VPN. You could find the networks reachable through the VPN connection on the VPN client once you are connected. You can go to VPN clients statistics=> route details => Secure routes.
At this point packets from ASA towards to the client and viceversa should be going through the VPN connection.
Hope this clear your doubts,
Luis.
03-08-2014 02:25 PM
Hello Mahesh,
Have you tried to ping from the inside network? Or source the packet from the inside interface of the ASA? Remember, that you should have some nat exemption rules for the packets going through the VPN connection. That's how we specify what networks are allowed to reach the VPN clients. If you ping without specifying any interface the packet will be sourced from the outside interface and probably that interface/subnet is not allowed through the VPN connection. Are you using split-tunnel or tunnelall?
You could try to enable management-access on the inside interface and the ping sourced from the inside. These packets should hit the nat exemption rule and will be sent through the tunnel instead of the Internet.
This are the commands needed:
To specify an interface as a management-only interface, enter the following command:
hostname(config)# management access inside
Then you could do a ping inside 10.0.0.5 in order to ping the AnyConnect client from the ASA.
Notes about management access command:
If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you can identify that interface as a management-access interface. For example, if you enter the ASA from the outside interface, this feature lets you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface when entering from the outside interface. Management access is available via the following VPN tunnel types: IPsec clients, IPsec LAN-to-LAN, and the AnyConnect SSL VPN client.
Hope this helps,
Luis
03-09-2014 10:41 AM
Hi Luis,
Yes i am able to ping from inside network fine.Also when i ping with inside interface it works fine.
I was using spilt tunnel policy.
management access inside is already configured on the ASA.
Also now i added the outside interface subnet under the split tunnel and now i am able to ping the IP 10.0.0.5 from ASA without using the
inside.
So does it mean that earlier ping was failing because subnet 10.0.0.0/24 traffic was going via the tunnel and it was using outside interface IP
as source and traffci flow was from the source as internet (outside interface IP of ASA) and destination was user PC IP (inside the tunnel?
So seems when we do ping from VPN client PC to inside interface of ASA that packet goes via
tunnel right?
OR when i ping from ASA with inside IP 10.0.0.5 that packet also goes via tunnel right?
Regards
MAhesh
03-12-2014 11:30 PM
Hello Mahesh,
Great to hear that everything is working fine!
Basically, when you tried to ping the VPN client subnet (10.0.0.0/24) the packet was being sourced from the Outside interface of the ASA, however, this ip/subnet was not allowed to go through the VPN connection because it was not included on the split tunnel ACL. Remember that the split tunnel ACL is used to specify the networks reachable through the VPN tunnel. If the network or ip address is not included the packets will be sent through the Internet instead of the VPN. You could find the networks reachable through the VPN connection on the VPN client once you are connected. You can go to VPN clients statistics=> route details => Secure routes.
At this point packets from ASA towards to the client and viceversa should be going through the VPN connection.
Hope this clear your doubts,
Luis.
03-13-2014 11:06 AM
Hi Luis,
Many thanks for great explanation.
Seems you know the VPNs very well.
Best Regards
Mahesh
03-13-2014 04:44 PM
Hi Mahesh,
No problem. My pleasure!
Luis.
03-08-2014 10:27 PM
Hello Mahesh,
Adding to the great answer that Luis just provided you it's important to check the basics as well.
Make sure the Windows Firewall is disabled on that PC and that you are not running any powerful Anti-Virus system that could be blocking this traffic.
If that does not help then follow Luis instructions as those are the next steps.
Regards,
Bebeeee
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide