cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1361
Views
0
Helpful
2
Replies

Remote Access VPN Ping VPN Clients From ASA

timway001
Level 1
Level 1

I'd like to know if it is normal to not be able to traceroute or ping connected VPN clients from the ASA command line? The VPN client and connection works well currently. I can ping/connect to inside hosts from the VPN and vice versa. I cannot however ping a VPN client IP from the ASA itself though. I am running split-tunnel as well but that appears to be functioning correctly based on the traceroutes I have ran.

Can I have IKEv1 and IKEv2 setup for the IPSEC RA VPN? I'm trying to keep the IKEv1 VPN up for the legacy Cisco VPN client while I start to roll out the AnyConnect client over IKEv2. Do you just end up creating a new VPN setup for the AnyConnect VPN (easier)?


What is the purpose of reverse route injection? It seems to be counter intuitive. I was hoping it would say for VPN DHCP Pool /32 come to me so I would not have to add static routes on my core to point to the ASA for these ranges. This ASA is only for VPN not firewall so traffic normally doesn't head to it. Right now I just have the static route for the /24 I am using in the DHCP pool on the cores. I of course have the option of redistributing the range plenty of other ways with EIGRP / OSPF / RIP it just seems RRI was a nice way to do this but it doesn't seem to be.

This probably all stems from me likely not understanding exactly how bits move through the firewall to the actual VPN client machine. Not seeing a layer 3 interface for the ASA's part in the tunnel I think is part of what confuses me.

I more or less followed this guide and added split-tunnel and aaa via RADIUS all of which seem to be working fine. I can't stress enough that for all intents and purposes it seems the VPN is working as it should right now. Expect for that time I broke it for a few hours while I was playing around with various other commands lol.

Thanks,

Tim

Reference:
ASA 5505 (base license right now, #labgear) running 9.2(4)

1 Accepted Solution

Accepted Solutions

Philip D'Ath
VIP Alumni
VIP Alumni

It is normal to not be able to ping remote VPN clients from the ASA itself.  To be able to do that the ASA's outside IP address would have to be included in the encryption domain, which it normally is not.

Yes, you can use IKEv1 and IKEv2 at the same time.  However if you are changing consider using SSL instead.  It is better supported and less painful.

If you choose to ignore this advice, then I would create a new IKEv2 VPN rather than modifying the existing one, and then migrate users across to it.

Reverse route injection does exactly what you describe.  They appear as static routes on the ASA, which you then have to redistribute into whatever routing protocol you like.  I wouldn't normally use it for user traffic, but for site to site traffic when handling more complex failover scenarios.

I recommend sticking with the simple /24 static route in your core.

View solution in original post

2 Replies 2

Philip D'Ath
VIP Alumni
VIP Alumni

It is normal to not be able to ping remote VPN clients from the ASA itself.  To be able to do that the ASA's outside IP address would have to be included in the encryption domain, which it normally is not.

Yes, you can use IKEv1 and IKEv2 at the same time.  However if you are changing consider using SSL instead.  It is better supported and less painful.

If you choose to ignore this advice, then I would create a new IKEv2 VPN rather than modifying the existing one, and then migrate users across to it.

Reverse route injection does exactly what you describe.  They appear as static routes on the ASA, which you then have to redistribute into whatever routing protocol you like.  I wouldn't normally use it for user traffic, but for site to site traffic when handling more complex failover scenarios.

I recommend sticking with the simple /24 static route in your core.

Thanks p.dath. Sorry a bit of a noob on the ASA, normally have my face buried in routers and switches. Your reply to my ICMP question actually helps me understand the RRI a bit more as well.

Tim