We have a client who has two ISP subnets at their head office (leased line and satellite broadband). I have been trying to establish a VPN tunnel between the head office PIX (PIX1) and a remote site (PIX2). PIX1 has two VLANs configured on Ethernet0. The crypto map for the tunnel is mapped to one of the VLAN interfaces, as is the isakmp policy. However, the tunnel would not establish.
At the remote PIX2, sh isakmp sa showed the status as QM_ IDLE.
At the head office sh isakmp sa reported nothing.
Further research back in the office showed that a default route had to be applied to the same vlan interface as the crypto map and isakmp policy before there was any isakmp activity. This is fine except that I need the default route to be out of the other vlan interface. Note that adding a host route to the remote site was not sufficient. Adding a default route to both vlan interfaces but with different metrics does not solve the problem either as the route with the lowest metric has to be applied to the "tunnel" vlan interface, (each default route was to different routers) Besides, what would happen if there was a requirement to have two tunnels using two vlan interfaces? PIX OS is v6.33
I hope this all makes sense. I've spent two days bashing my brains out on my keyboard to solve this - any ideas anyone?
You do not need a default route for a IPSec tunnel to work, however, you do need a route on PIX1 that points to IP address of PIX2 (IPSec peer) via the interface which the crypto map is bound to.
Have you tried to debug it when PIX2 tries to connect to tunnel? My first shot wold be to use "debug crypto isakmp" since it s clear to me that phase1 (isakmp) is not working fine. If you are using pre-shared key, please do check if they are the same at both PIX´s, a mismatch between the two pre-shared keys is often the problem.
Try debug crypto isakmp and post output if you need further assistance.
I agree that in theory I should not need a default route to be applied to the "tunnel" interface, a host route statement should be sufficient. However, in practice it would appear that a default route statement is required on the "tunnel" interface simply to get isakmp to function.
On PIX1 with a default route applied, "debug crypto isakmp" shows isakmp activity. Without the default route applied there is no isakmp activity whatsoever. The preshared keys match.
I cannot give you a copy of the output as I am not in the office today. When I'm back in I'll pursue this further
I´m starting to think that the problem does no resides on your side, but that the other side have not set up the host route to your PIX1 via the appropiate link. I start to believe that PIX2 tries to send the packets via the other vlaninterface.
Anyway, please try a debug crypto isakmp on noth situation then (with host route and with default route) and mail you output to me, so I can take a look at it.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...