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

How to add a second subnet to an existing IPSec remote access VPN on an ASA 5505

jm14
Level 1
Level 1

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.

 

 

2 Replies 2

Hi,
I imagine (it's usually the case), that your VPN traffic is unintentially being natted. Normally you would have a dynamic NAT rule that nats all outbound traffic from the inside networks (.47 and .48) behind the outside interface. It's possibly this nat rule that is causing an issue.

You would need to have a NAT Exemption rule, from inside to outside with the original source and translated source as .48 network and the original and translated destination as .46 network. This would ensure that traffic between those networks is not natted behind the dynamic nat rule.

If you need further assistance provide your configuration and I can let you know what to amend.

HTH

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.