08-17-2020 02:39 AM - edited 08-17-2020 02:40 AM
Hi and thank you for looking at my post.
I am not a VPN expert.
I am trying to allow access to a second subnet (setup on a different interface) in an existing IPsec remote access VPN on an old ASA 5505.
Currently, users connected to the VPN can ping devices on the subnet that was already set up but not the new subnet. Users are handed a 192.168.46.x address. Their default gateway is 192.168.46.1. They can ping any device on the 192.168.47.0 network. But they cannot ping devices on the 192.168.48.0 network.
The clients are using the old Cisco VPN client.
The VPN already had split tunnelling set up. So I started by adding the new subnet to the split tunnel ACL set. This added a route to the new subnet on the client when they next connected.
But, I've missed something because pings still do not work.
I would usually diagnose a failed ping by checking the logs for dropped packets and/or running a packet trace. But I am not seeing any dropped packets in the logs. I asked my tester to set up a continuous ping to both the .47 and the .48 subnets and I set the ADSM logging level to debug. I can see entries for the .47 packets. But not the .48 packets.
So I then tried to do a packet trace. But I'm not sure what the source address should be or even the source interface... I am missing fundamental understanding of what happens to packet routing when a client is connected to a VPN. Is the source address the client's public IP? Or their private IP? Is the source interface the external interface or the internal interface? I just don't quite understand what happens when the client is connected to a VPN.
So, would anyone be able to help me understand what is happening here? Does the fact that I am not seeing any entries in the logs for the .48 network mean that there is something wrong on the client? Or is that a red herring and I've forgotten some config on the ASA that means packets are getting dumped before they touch the logs?
I'm looking for help understanding how routing works when connected to the VPN and ideas for diagnosis rather than to be given a set of config changes to do that I don't understand.... I can post the full config if that will be more useful than running diagnostic commands.
Any guidance would be very, very much appreciated.
08-17-2020 02:49 AM
08-17-2020 07:43 AM
Hi Ron,
Thank you very much for your reply. It is very much appreciated.
Is there a way I can prove it's the NAT? I've always been able to use packet tracer to pinpoint either NAT or firewall rule issues before.... How would I set up a packet trace for this particular scenario...? The .47 and .48 networks are each on separate interfaces to the external network. Which source and destination interfaces would I use and what IP from the client would I use (public or the private .46 address)?
I have looked at the existing NAT rules and there is one there that looks like it turns NAT off completely for the .46 network. But I can't see anything that specifies NAT for the .47 network...
I'd like to understand how NAT for VPNs works. If I understood where NAT fits into to remote access VPNs, I'd be in a much better position.
I have anonymised our config and will attach it. It's very old and has a lot of redundant entries that have not been cleaned out. It was originally configured by a staff member who is no longer with us. once you've had a chance to look through, I can add the NAT entry you have suggested (although I'd like to understand what exactly I am configuring if you wouldn't mind explaining it; NAT is not a strong point of mine).
Thanks again for your help so far.
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