We help IT Professionals succeed at work.

Cisco EasyVPN: can't get a vlan added

travisryan
travisryan asked
on
104 Views
Last Modified: 2016-10-28
This has to be something easy I'm missing. I have a main site with a Cisco ASA 5520 and a remote site with a Cisco ASA 5506. I already have an ezvpn site to site set up with several vlans added. I just tried to add another one and can't get pings to go over the tunnel. My configs are below:

MAIN SITE ASA

       object-group network Internal_Networks
     network-object 12.1.80.0 255.255.255.0
        network-object 12.1.70.0 255.255.255.0
        network-object 12.1.60.0 255.255.255.0

       object network remote_network_1
        subnet 12.4.1.0 255.255.255.0


       access-list ezvpn_split extended permit ip object-group Internal_Networks object remote_network_1

group-policy ezvpnpolicy internal
       group-policy ezvpnpolicy attributes
        split-tunnel-policy tunnelspecified
        split-tunnel-network-list value ezvpn_split
        nem enable

username <remote site 1> password <removed>
====================

REMOTE SITE 1 ASA


vpnclient server <ezvpn server IP>
vpnclient mode network-extension-mode
vpnclient nem-st-autoconnect
vpnclient vpngroup <ezvpn group name> password *****
vpnclient username <remote site 1 ezvpn name> password *****
vpnclient enable


PROBLEM: I have the 12.1.80.0 and the 12.1.70.0 subnets pinging to the remote subnet 12.4.1.0 just fine. I added the 12.1.60.0 subnet and can't get it pinging with the 12.4.1.0. What am I missing?
Comment
Watch Question

CERTIFIED EXPERT

Commented:
Hi,
you may have forgotten to exempt NAT as you probably did with former subnets.

Something like:

nat (inside,outside) source static obj-local obj-local destination static obj-remote obj-remote

please do a check on that

hope this helps
max

Author

Commented:
Max, below is my nat entry on the Main ASA:

nat (inside,outside) source static Internal_Networks Internal_Networks destination static remote_network_1 remote_network_1 no-proxy-arp route-lookup

Open in new window

Author

Commented:
I was trying to use packet tracer on this one, but all of my tests come up allowed. I'm currently research how to set up packet captures to help troubleshoot.
CERTIFIED EXPERT

Commented:
Hi,
since you have added an item (the new subnet) into the object which was already natted, you should have previously remove that nat statement, then add the new subnet into the object and then reissue the nat statement: did you do that.
This is why I usually do not use summarized objects on nat statements.

It might be worth a try

hope this helps
max

Author

Commented:
Max, I cleared the nat statements and re-added them, no dice. Then I removed the subnet from the Internal_Networks group and made it it's own group, put that in it's own nat statement then applied that, still didn't work.

Any other suggestions?
CERTIFIED EXPERT

Commented:
check access-lists
max

Author

Commented:
Max, I posted all relevant access lists. No other ACL references the 12.4.1.0 network. Do you use packet tracer or packet capture to troubleshoot issues like this?
CERTIFIED EXPERT

Commented:
you can use packet tracer from asdm
max

Author

Commented:
Max, do you have any experience with it? I'm getting no results.

Author

Commented:
Capture buffer showing empty.
CERTIFIED EXPERT

Commented:
depends on which asdm version you have.
You Can as well use asdm monitoring and set a filter with the subnet or IP you are testing.
max

Author

Commented:
I'm really looking for more of a packet tracer type tool to see where the packets stop at, can packet capture help me do this? I need to know what I'm missing.
CERTIFIED EXPERT

Commented:
in asdm packet tracer you need To set source ip and port and destination ip and port.
as easy as that. It will show you the flow.
max

Author

Commented:
I tried that for this connection and it shows allowed. From what little I've found about packet tracer and VPNs it looks like it doesn't work for some reason.
CERTIFIED EXPERT

Commented:
allowed really means allowed

Author

Commented:
Remote Site 1 Firewall
packet-tracer input inside icmp 12.4.1.11 8 0 12.1.60.14
Result: Allow
When I try to ping from the device with the IP address 12.4.1.11 to 12.1.60.14 the ping fails

Main Firewall
packet-tracer input inside icmp 12.1.60.14 8 0 12.4.1.11
Result: Allow
When I try to ping from the device with the IP address 12.1.60.14 to 12.4.1.11 the ping fails

I've tried 8 0 codes and 0 0 codes, both say allow yet I can't ping between the two addresses.
CERTIFIED EXPERT

Commented:
check the other firewall

Author

Commented:
For what?
CERTIFIED EXPERT

Commented:
you already did  ... Just realized
CERTIFIED EXPERT

Commented:
Hi,
just in case the ASA for any reason doesn't match with crypto map, I would try the following:

no access-list ezvpn_split extended permit ip object-group Internal_Networks object remote_network_1

access-list ezvpn_split extended permit ip 12.1.80.0 255.255.255.0 12.4.1.0 255.255.255.0
access-list ezvpn_split extended permit ip 12.1.70.0 255.255.255.0 12.4.1.0 255.255.255.0
access-list ezvpn_split extended permit ip 12.1.60.0 255.255.255.0 12.4.1.0 255.255.255.0


and then you'd better recreate the
 split-tunnel-network-list value ezvpn_split

or at least check that it did not disappear after deleting that access-list in the previous step.

let me know, if no joy, set the debug on asa while pinging:

debug crypto ikev1
debug crypto ikev2
debug crypto ipsec

max

Author

Commented:
Max, how would I check if the crypto map isn't matching? That split tunnel list is for more than one easy vpn and I'd like to bounce these as little as possible since we have some users at these locations actively using the connection.
CERTIFIED EXPERT

Commented:
yep, this is just a try ...

you may alternatively set debug on ASA and read messages: it would tell you if it doesn't match with crypto map

Author

Commented:
Max, sent pings both ways, tried debug crypto ikev1, debug crypto ikev2 protocol (and platform and ha and timers and debug crypto ipsec. Nothing points to an issue with that tunnel or the 12.1.60 network.

Checking my general debug logs now.

Author

Commented:
So here was an interesting experiment:
I have pings going on a 12.1.60 machine to a 12.4.1 and a 12.5.1 address
Those same pings are coming from my machine on a 12.1.70 address
I ran a: no split-tunnel-network-list value ezvpn_split then saved the config.

Not a ping dropped. I gave it about 5 minutes and not a ping dropped from my 12.1.70 machine to those two addresses. It didn't have an affect on the pings from the 12.1.60 machine.

When I tried the same experiment yesterday with the nat statements, it definitely dropped pings from my machine.

Author

Commented:
I wonder if using an actual IP addresses in the nat statement instead of assigning a subnet to a group would change anything?
CERTIFIED EXPERT

Commented:
It is worth a try ... whenever possible

Author

Commented:
Is there some specific debugging I should be turning on to help troubleshoot the issue?
CERTIFIED EXPERT

Commented:
Hi,
there is one more easy thing you may want to do ...

check that access-lists on each side is identical and separate them, i.e.:

MAIN SITE
access-list ezvpn_split_1 extended permit ip 12.1.80.0 255.255.255.0 12.4.1.0 255.255.255.0
access-list ezvpn_split_2 extended permit ip 12.1.70.0 255.255.255.0 12.4.1.0 255.255.255.0
access-list ezvpn_split_3 extended permit ip 12.1.60.0 255.255.255.0 12.4.1.0 255.255.255.0

REMOTE1
access-list ezvpn_split_1 extended permit ip 12.4.1.0 255.255.255.0 12.1.80.0 255.255.255.0

REMOTE2
access-list ezvpn_split_2 extended permit ip 12.4.1.0 255.255.255.0 12.1.70.0 255.255.255.0

REMOTE3
access-list ezvpn_split_3 extended permit ip 12.4.1.0 255.255.255.0 12.1.60.0 255.255.255.0


I have coped with cases in which summarizing would mess with crypto maps, and i remember that vpn did go up but did not exchanged packets with some subnet: separating them gave me joy.

hope this helps
max
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION
CERTIFIED EXPERT

Commented:
Hi,
well that is really confusing as you did not mention tunnel-groups in your post.
Moreover the tunnel-group must be tied to the IP address (it is mandatory) so i wonder how you could use the same tunnel-group.
have a nice day
max

Author

Commented:
max, I didn't think this was an issue until someone else had taken a look at it. I was using the same tunnel group because both easyvpn site to sites are using the same IP address to connect back to.
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.