cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1507
Views
0
Helpful
7
Replies

VPN confusion ASA/PIX L2L config

robert.croxford
Level 1
Level 1

Hello all,

Our main Office has an ASA with 5 L2L VPNs running to various sites.  All without any problem what so ever.  I tried creating a new VPN tunnel for a new site and the VPN link failed (using ASDM first and then CLI).  The remote site is using a PIX505e with ver 6.3(1) SW.  The tunnel will come up if remote site pings my inside interface, and is getting an MM_Active status from the CLI.  The PIX gets QM_Idle.  I, however can not ping the remote internal network from either the ASA or from a PC on my side of the VPN.  We can not pass any interesting traffic via this tunnel (obviously!). 

We have a remote user who uses client software to access our LAN from the remote site in question, when he is connected, and is configured as a remote VPN user on the ASA.  When he uses this SW while connected to the remote LAN I get MM_Active but the typeis still L2L... Obvioulsy peer IP is the same as the remote LAN public address.

Debug shows nothing out of the ordinary as far as I'm aware (all of this is from previous experience, not certified but used to be CCNA).  I'm more than happy setting up VPNs using IOS routers but PIX/ASAs are 'new' to me.  I can post scrubbed configs if this will help anyone...

HELP!

Any useful posts are gratefully received

7 Replies 7

Hi Rob,

The configuration on the PIX and ASA are different from each other and from IOS.

You can check this link that shows how to create a L2L between an IOS and ASA:

http://www.cisco.com/en/US/products/ps5855/products_configuration_example09186a0080a9a7a3.shtml

Also the VPN configuration information on ASA:

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/vpn_site2site.html

If you have any questions you can post your configuration.

Hope it helps.


Federico.

Thanks for the import Federico,

I know the ASA is different from the PIX which, in turn is different from IOS Routers.  That's not necessarily the problem (although it is for debug purposes as I'm having to rely heavily on forums at the moment).  I have successfully configured remote users and other remote sites (18xx and 8xx series routers advanced ip IOS / adv. sec IOS) on the ASA and these work fine.  The settings follow the same rules (albeit different phase 1 / 2 info) as the other tunnels but still nothing.  This leads me to believe it's a routing issue?  Internal to Main Office is a L3 Switch and a Watchguard Firewall.  Internal to remote site is Cisco 2950 Switch.

See attached for configs -

Thanks, Rob

Rob,

The traffic that you want to encrypt is between ASA's inside 192.168.1.0/24 and remote 192.168.0.0/24


The encrypt ACL on the ASA is:
access-list BTNET_7_cryptomap extended permit ip 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0

But I don't see that traffic being exempt from NAT, you should add on the ASA:
access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0

On the PIX you don't seem to have the problem.

Please try it and let us know.

Federico.

Hi Federico,

The NAT excemption for that particular network is:

access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 WATFORD-EXPO-Net 255.255.255.0

That was my original thought as I had missed it.  Even with it there now though, I still can't transmit any interesting traffic

Rob

Rob,

Let's do the following:

Things to check on the configurations:

1. On the ASA and PIX check that the interesting traffic 192.168.1.0/24 and 192.168.0.0/24 is not matched to any other tunnel (ACL of any other crypto map instance).

2. Check there's no route to the remote network (LAN of the peer) pointing to any other interface (should point to the outside).

Add the command management-access inside to both sides and PING between internal IPs:

ASA:

ping inside 192.168.0.3

PIX:

ping inside 192.168.1.253

The above will enable the inside interface to participate in the interesting traffic so that you can try to bring up the tunnel by sending a PING to the peer's internal IP.

It the above works, then we need to check that the default gateway of the LANs on each side is the respective ASA/PIX or at least they have a route to reach the remote network.

Federico.

Federico,

Thanks for your ongoing support,

1. I've made sure the interesting traffic is not matched to any other crypto ACL on either side using the GUI (ASDM and PDM).

2. There's a static route configured to point my inside network to remote external IP and there is nothing else pointing to this IP Address.

I will add the following command to both devices and report back with the results of the PING:

management-access inside

On the last note, my local default gateway is the L3 Switch (HP) could this be having an adverse affect?  All devices on the local LAN have a default gateway of .254 (switch) which, in turn points to the ASA.  Could this be having an adverse affect on the routing?  I've checked the switch configs and there is nothing to suggest there is a problem  (there is no mention of the other remote sites in the routing table on the L3 switch).

The one thing that I do find odd is how a remote user (logs into our LAN via VPN Client but whilst at the remote site at question, comes in on the VPN tunnel remote IP - obviously connecting through their LAN, accessing the www through their PIX and finally to the local LAN) can log on, when this user has connectivity, the show crypto isakmp sa on the ASA, it shows his connection as MM_ACTIVE, initiator L2L whereas other remote users show as AM_ACTIVE, responder, user.  I know that MM and AM are different (AM - aggressive mode / MM - main mode) but why does this tunnel show as L2L when it is a user tunnel with a different phase 1 / 2 configuration?

I think this is the cause of my issues at the moment, do you agree?

Once again, thanks for your ongoing support,

Rob

The result of doing the:
ASA:
ping inside 192.168.0.3
PIX:
ping inside 192.168.1.253
were succesful?

The test that we are doing with the above is making sure we can send traffic through the L2L tunnel (originated
from the inside IP of the respective device).

If the default gateway of the internal LAN is a switch, you just need to make sure that the switch has either
a default gateway to the ASA/PIX or a route to point back to the remote L2L subnet.

Can you post the output of:
sh cry isa sa
sh cry ips sa

For the L2L tunnel between the ASA and the PIX on both sides when attempting to send traffic?

Federico.