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?
bergquistcompanyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

What do the logs show when attempting to ping?
0
rauenpcCommented:
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.
0
bergquistcompanyAuthor Commented:
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
0
Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

rauenpcCommented:
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.
0
bergquistcompanyAuthor Commented:
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
0
rauenpcCommented:
The nat exemptions defined are:

[i]nat (inside,outside) source static obj-10.10.0.0 obj-10.10.0.0 destination static obj-10.61.0.0 obj-10.61.0.0
nat (inside,outside) source static obj-10.10.0.0 obj-10.10.0.0 destination static obj-10.10.7.0 obj-10.10.7.0
nat (inside,outside) source static obj-10.20.0.0 obj-10.20.0.0 destination static obj-10.61.0.0 obj-10.61.0.0
nat (inside,outside) source static obj-10.20.0.0 obj-10.20.0.0 destination static obj-10.10.7.0 obj-10.10.7.0
nat (inside,outside) source static obj-10.30.0.0 obj-10.30.0.0 destination static obj-10.61.0.0 obj-10.61.0.0
nat (inside,outside) source static obj-10.30.0.0 obj-10.30.0.0 destination static obj-10.10.7.0 obj-10.10.7.0
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[/i]


What's in bold are all the nat exemptions defined for traffic going to/from 10.10.7.0/24. 10.61.0.0 is included, however...


route outside 10.61.0.0 255.255.0.0 *********** 1
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
crypto map outside_map 4 match address tunnel-acl
crypto map outside_map 4 set peer ********
crypto map outside_map 4 set ikev1 transform-set ESP-3DES-MD5
crypto map outside_map 4 set security-association lifetime seconds 28800
crypto map outside_map 4 set security-association lifetime kilobytes 4608000


Since the 10.61.0.0 is not a local subnet to the ASA but rather another remote VPN subnet, this means that client vpn traffic actually has to hairpin through the ASA. I believe the NAT exemption should be (outside,outside), and not (inside,outside).

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
Same security traffic also needs to be allowed, but that command is already in place.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bergquistcompanyAuthor Commented:
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
0
rauenpcCommented:
yes, i believe that may be the answer to your current issue.
0
bergquistcompanyAuthor Commented:
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
0
rauenpcCommented:
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
0
bergquistcompanyAuthor Commented:
inside IP is 10.10.x.x correct

No same thing
0
rauenpcCommented:
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.
0
bergquistcompanyAuthor Commented:
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
0
rauenpcCommented:
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?
0
HalldorGCommented:
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?
0
bergquistcompanyAuthor Commented:
got me in the right direction.  Flipped the obj- and added inter-interface and working now
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cisco

From novice to tech pro — start learning today.