Cisco EasyVPN: can't get a vlan added

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?
travisryanAsked:
Who is Participating?
 
travisryanAuthor Commented:
I had another colleague take a look at my config. Both my EasyVPN sites were sharing the same tunnel group, I needed to split this out into separate tunnel groups, then everything worked.

Regardless, thanks for all of your input Max.
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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

0
KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

 
travisryanAuthor 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.
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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?
0
 
max_the_kingCommented:
check access-lists
max
0
 
travisryanAuthor 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?
0
 
max_the_kingCommented:
you can use packet tracer from asdm
max
0
 
travisryanAuthor Commented:
Max, do you have any experience with it? I'm getting no results.
0
 
travisryanAuthor Commented:
Capture buffer showing empty.
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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.
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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.
0
 
max_the_kingCommented:
allowed really means allowed
0
 
travisryanAuthor 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.
0
 
max_the_kingCommented:
check the other firewall
0
 
travisryanAuthor Commented:
For what?
0
 
max_the_kingCommented:
you already did  ... Just realized
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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.
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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.
0
 
travisryanAuthor 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.
0
 
travisryanAuthor Commented:
I wonder if using an actual IP addresses in the nat statement instead of assigning a subnet to a group would change anything?
0
 
max_the_kingCommented:
It is worth a try ... whenever possible
0
 
travisryanAuthor Commented:
Is there some specific debugging I should be turning on to help troubleshoot the issue?
0
 
max_the_kingCommented:
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
0
 
max_the_kingCommented:
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
0
 
travisryanAuthor 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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.