Link to home
Start Free TrialLog in
Avatar of bergquistcompany
bergquistcompany

asked on

VPN users can't ping specific subnet when connected to Cisco ASA5525

Hello EE,

We have a 10.10.7.x dhcp network that Cisco VPN clients connect to when remote.
The problem is when I had my PIX 515e in place they could VPN in and ping my 10.61.x.x network and since I put in the Cisco ASA5525 they can not anymore.  Any suggestions?
Avatar of Jan Bacher
Jan Bacher
Flag of United States of America image

Are you allowing ICMP on the interface for the 10.61.x.x network?

What do the logs show when attempting to ping?
Also, can you connect to that subnet with different protocols? Such as file sharing, FTP, www, etc.
If you can post a scrubbed config that would be useful as well.
Avatar of bergquistcompany
bergquistcompany

ASKER

No if I VPN and get 10.10.7.x IP when connect with Cisco VPN Client to new ASA5525 at corporate cant ping or browse 10.61.x.x.

However sitting at desk at corporate getting 10.10.13.x can browse 10.61.x.x

I can work on getting one as well but replaces PIX with ASA and not sure as imported old config so should work I'd think
The nat rules and acl's changed between the pix and asa5525. A direct import wouldn't work so nat/acl statements could be missing or incorrect. A scrubbed config would be the best bet for us to help you out.
Here is a scrubbed config where users VPN get 10.10.7.x and can get to 10.20.x, etc but not 10.61.x.x
BQCORPASA5525.txt
ASKER CERTIFIED SOLUTION
Avatar of rauenpc
rauenpc
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
so change
nat (inside,outside) source static obj-10.61.0.0 obj-10.61.0.0 destination static obj-10.10.7.0 obj-10.10.7.0

to

nat (outside,outside) source static obj-10.61.0.0 obj-10.61.0.0 destination static obj-10.10.7.0 obj-10.10.7.0
yes, i believe that may be the answer to your current issue.
ok removed nat (inside,outside) source static obj-10.61.0.0 obj-10.61.0.0 destination static obj-10.10.7.0 obj-10.10.7.0 and changed to nat (outside,outside) and still can't access 10.61.x.x via ping or browse
hmmm... I have a question. You have scrubbed the inside IP address from the firewall. Is it a 10.10.x.x/16 IP address? The subnet mask used might be important for this.

also, you can try to add the route-lookup option to the end of the nat statement, not sure if that will help.

nat (outside,outside) source static obj-10.61.0.0 obj-10.61.0.0 destination static obj-10.10.7.0 obj-10.10.7.0 route-lookup
inside IP is 10.10.x.x correct

No same thing
Since this inside IP and the remote vpn client fall in the same 10.10.0.0 subnet, this can be a source of difficulties. Confusion is only made worse that depending on the interface traffic is received the routing function of the ASA can seem different. I'm going to assume that the 10.20.0.0 and 10.30.0.0 is on the inside of the firewall on a different router or L3 switch (the important part is that it's an inside route. Here's what I've understood to happen in this scenario.
When traffic goes from 10.10.7.0 to 10.20.0.0, it hits the outside interface. By using the routing rules, it determines that the egress interface should be the inside interface. From there the rest of the rules are run to determine if or how that packet will pass. Traffic makes it to the 10.20.0.0, and a response is made. The response hit's the firewall due to proxy arp and the nat rules, due to the ingress interface, determine that the egress interface is the outside. Traffic uses the vpn to pass back to the client.
when it comes to the traffic that is going across another site to site vpn, the packets are treated differently. When traffic goes from 10.10.7.0 to 10.61.0.0, it hits the outside interface. By using the nat/routing rules, it determines that the egress interface should be the outside interface. Traffic makes it to the 10.61.0.0, and a response is made. The response hit's the firewall's outside interface and by using routing rules, it determines that the egress interface is the inside interface because of the locally configured IP address. Using the inside interface in this situation won't work because it needs to go back out the outside interface.

From here I have two thoughts. You can reconfigure the vpn to use a unique subnet. I feel that this is the best overall design choice for (almost) every client vpn situation. For you this would mean configuring a new local pool, updating routing, and updating the site to site vpn to Hong Kong. This may or may not be more work than you'd like to tackle.

My second thought would be to set reverse route injection. This creates a static host route for each client connection. This static route can even be injected into dynamic protocols if you'd want to do so.

crypto dynamic-map outside_dyn_map 20 set reverse-route

The above command, along with the route-lookup option for nat exemption referencing 10.10.7.0 and 10.61.0.0 could be the ticket for you. You might need that on all nat exemptions referencing 10.10.7.0, but I don't think you will.

Warning - this command will kick out all current vpn clients without any warning. They should be able to reconnect right away, but they will lose their session for sure. Some ASA issues are very easy to troubleshoot via forums like this, but sometimes the issues become difficult and start relying a lot more on theory/guesses. From my perspective, you seem to be getting in to the theory/guess arena since I can't log in to your ASA and run packet tracers, show logs, etc. So you can give this a shot, but just be aware that users will get kicked out. Good luck, I hope this works. If it doesn't, my next thought would be the unique subnet but I'll continue to think of other theories.
I used to have a PIX515e and Cisco translated the commands for the ASA5525 so I'm surprised the ASA can't do it.

So are you saying try adding this as the second change to the nat (outside,outside):
crypto dynamic-map outside_dyn_map 20 set reverse-route
The reverse route is a command that affects the crypto portion of the config, not nat necessarily.

I've converted enough configs from the PIX/old ASA to know that some are much easier to do than others. It can be very difficult to know every command needed to each situation. To straight up change nat statements and ACL's (which is the biggest change in code versions) is relatively straight-forward. But in some cases the order of operations becomes important and it's hard to make things work end to end without being right there doing testing and making changes. I'm not trying to make an excuse for Cisco, but just know that even experienced engineers like myself run in to difficulties. I had one conversion that took 3 hours and worked perfect, and I had another that took 40 hours and that was before implementing (and no, it wasn't my first conversion ;)

I suppose if my suggestions don't result in a solution, would you be able to go back to Cisco and request that they resolve the issue since technically it's their config that isn't working?
The comment says

route outside 10.61.0.0 255.255.0.0 *

But the access-list is
access-list tunnel-acl remark CRYPTO MAP FOR NEW HONG KONG TUNNEL
access-list tunnel-acl extended permit ip 10.10.0.0 255.255.0.0 10.61.0.0 255.255.255.0
access-list tunnel-acl extended permit ip 10.20.0.0 255.255.0.0 10.61.0.0 255.255.255.0
access-list tunnel-acl extended permit ip 10.30.0.0 255.255.0.0 10.61.0.0 255.255.255.0

Wrong mask in the 10.61.0.0 network?
got me in the right direction.  Flipped the obj- and added inter-interface and working now