cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1650
Views
0
Helpful
15
Replies

IPSEC site to site VPN Issues (lab recreating real issue)

Ninjabean
Level 1
Level 1

I am new to the security world, and am having a bit of trouble.

We are trying to set up a VPN for a customer to a new vendor - and it is quite a complex (to me) design.  They have a DMZ, and basically we are trying to give the 10.2.0.0 remote subnet access to the local 10.1.1.1 machine. In the lab, I am just trying to get the basics and work up from there.

I was able to get phase 1 going, but then phase 2 said it had a mismatch.  I tried to recreate this in packet tracer, and no matter what I do I cannot get phase 2 set up in packet tracer either.  Even following step by step guides, or copying the solution from a packet tracer lab, I cannot get it to work.  

I feel like I am missing a piece - what I have so far, and I have changed this setup many many times just trying to get it work:

 

The attached configs are a lab environment and IPs are not real.

1 Accepted Solution

Accepted Solutions

Are you pinging from the ASA? Ping from something inside the network on the correct subnet, to another device (not the ASA) that should bring up the vpn and there should be some matches on the nat rule.

View solution in original post

15 Replies 15

Hi,

Well you've got a dynamic nat rule which would nat the traffic to the remote subnet, so you'll need a no nat rule to ensure the original source network is used rather than natting behind the outside interface.

 

E.g:-

nat (inside,outside) source static local_subnet local_subnet destination static remote_subnet remote_subnet

 

HTH

Gotcha.  Now this may just be a Packet Tracer limitation, but I can't seem to do NAT from global config mode. Is there any other way to do it? Or maybe does something else need to be enabled before I can use that command?

 

It might well be a limitation of Packet Tracer, I haven't used it tbh. What version of ASA is running on it 8.x or 9.x? In version 8.2 the commands were different.

9.6.  This is a 5506, which the only ASA PT offers where you can put addresses on the actual interfaces.  I did try it on the other available 5505 and the command is not there either.  

I may revert to an older version of PT to see if its possible. Unfortunately I don't have the lab equipment to do this for real, and the customer needs to maintain 100% uptime.  I have implemented a nat rule before that took down a different organization's network, so I am worried about doing that again :P.  I do appreciate your help regardless!

Use GNS3 instead of PT

Fair point. 

So I recreated everything in GNS3 (whew was that a pain to get going). Now I can ping from ASA 1 all the way across to ASA 2, but it wont even get phase one up. In wireshark I am seeing no ISAKMP or IPSec packets at all, and also none show up in counters, and debug gives no information.

Post the configs please

Same configs in the OP except also including nat (inside,outside) source static local-subnet local-subnet destination static remote-subnet remote-subnet no-proxy-arp route-lookup.

I think its just a bug though, because I can ping all the way over the the other ASA, and when I remove the access-list for interesting traffic it shows to have killed the ikev1 session via debug, and I see those packets in wireshark. But when I added the acl back in it does not show the SA still, even though I can then ping again.

It also increments the show crypto protocol statistics all when I do that as well.

Any hits on the new nat rule, when you run "show nat"?
Have you run a packet trace?
What subnet are you sourcing the ping from?

There are actually no hits on the rule. And the ping hits from outside but not inside.. didnt think to try that.  Seems like there is still something going on :/

 

Are you pinging from the ASA? Ping from something inside the network on the correct subnet, to another device (not the ASA) that should bring up the vpn and there should be some matches on the nat rule.

 Oh good lord. That was it. I didnt know the SA wouldnt be brought up until you hit it from the inside subnet. You are a life saver! I really appreciate all your help.

Good to hear!

Yes, what ever you define in the ACL is referred to as interesting traffic, only traffic matching source and destination will bring up the tunnel.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card