You‘re using a Cisco Box
| Platform | Symptom/Message | Likely cause or solution |
| PIXs and Cisco routers |
(Router) log message of:
|
Pre-shared key mismatch This is more often a router VPN message than a PIX VPN message |
|
(Router) log message of
|
No policy defined with correct combination of DES/3DES, MD5/SHA and Group1/2 This is more often a router VPN message than a PIX VPN message |
|
|
Any message containing a reference to "proxy identities not supported" usually something like the following PIX debug output:
where 1.1.1.2 and 2.2.2.3 are the VPN peer addresses, and 4.4.4.0/26 and 5.5.5.0/27 are the local and remote networks (encryption domains for each peer) You MUST run debug on the PIX to see these messages |
The most common PIX problem. The two peers must agree exactly on the definitions for the local and remote networks (i.e the encryption domains for each peer) If, for example, you have your local network precisely defined as "1.2.3.0/29" and and your peer has it loosely defined as "1.2.3.0/24" they mismatch and the tunnel will fail. If, for example, you have your local domain defined as a network of "1.2.3.0/29" and and your peer has it defined as individual hosts within that network, they mismatch and the tunnel will fail. The same is true for the definitions of the remote network. Your local nets must match the peers remote nets Your remote nets must match the peer‘s local nets. Check the I should also note that "proxy identities not supported" can come up if you‘ve specified particular ports on the "interesting traffic" ACL, and the traffic doesn‘t match the specified ports. I would expect "denied" instead, but no, it‘s "proxy identities not supported." This, however, is very easy to debug by simply making the ACL "permit ip source dest " and "permit ip dest source.". If that works and your desired ACL doesn‘t, then the restrictions must be the issue. |
|
|
PIX debug output of:
|
Usually pix-to-pix, but can happen with other firewalls smart enough to do detailed negotiation, like a checkpoint. The official wording from Cisco is that "The access list on each peer should mirror each other (all entries should be reversible)." The key here is that this is just more info associated with the "proxy identities" message described above. |
|
|
PIX debug output of:
|
No policy on PIX with correct combination of DES/3DES, MD5/SHA and Group1/2 | |
|
PIX debug output of:
|
Cisco says that "The crypto map map-name local-address interface-id command causes the router to use an incorrect address as the identity because it forces the router to use a specified address."
Which means that either the crypto map is applied to the wrong interface or, it is not applied at all. Check the configuration to ensure that crypto map is applied to the correct interface. |
|
|
PIX debug output of:
|
Mismatch in the PIX "crypto ipsec transform-set" statement for this tunnel |
|
|
PIX debug output of:
|
Wrong peer address in PIX "crypto map" statement for this tunnel |
|
|
PIX debug output of:
|
Cisco‘s only doc on this message says: The error message below normally appears with the corresponding VPN 3000 Concentrator error message "Message: No proposal chosen(14)". This is a result of the connections being host-to-host. The router configuration had the IPSec proposals in an order such that the proposal chosen for the router matched the access list, but not the peer. The access list had a larger network that included the host that was intersecting traffic. To correct this, make the router proposal for this concentrator-to-router connection first in line, so that it matches the specific host first. From experience, though, If x.x.x.x is the address of your own firewall, check and see if you haven‘t accidentally reversed an ACL. Look at the way that they are mirrored (vs identical) in the Cisco PIX Firewall and VPN Configuration Guide Chapter 7 |
|
|
PIX debug output of:
|
The received proxy identity does not match the configured proxy identity as per the access list, i.e. the gateways are right but the host isn‘t in the ACL. You‘ve established a tunnel, and then the peer tries to send you some traffic through it that doesn‘t match the "interesting traffic"/"encryption domains" specified on your side. | |
|
PIX debug output of:
|
Almost always an ISAKMP key mismatch Can also show up if you‘ve accidentally cut and pasted the wrong peer address into the crypto map |
|
|
PIX debug output of:
|
Check if you forgot to apply your crypto map to the appropriate interface Also often, a mismatch in encryption domains Make sure your definitions for networks/hosts on both sides match the peer‘s By report, this can sometimes indicate that you need to add "no-xauth no-config-mode" to the isakmp key line. This is not necessarily a fatal error - sometimes it‘s a stupid peer that won‘t follow protocol. I have working tunnels that get this message all the time |
|
|
PIX debug output of:
|
No tunnel has ever been set up, but some operation is being attempted that presumes one has been set up, Maybe you got a delete SA or delayed traffic from a misconfigured peer? If this shows up alongside "retransmitting phase 1" see below. | |
|
PIX debug output of:
|
If you are initiating, you sent a phase one and got no response. Do both peers have a correct route out? Is one one the other getting its IKE traffic blocked by some intervening firewall or ACL‘ed router? If s/he is initiating, Peer started a phase 1 and you answered, but it never completed. Your PIX is still trying. Doesn‘t tell you much, but in the absence of other errors, it indicates your side is not as likely to be the problem |
|
|
PIX debug output of:
VPN Peer:ISAKMP: Peer Info forx.x.x.x/500 not found - peers:z ISAKMP (0): retransmitting phase 1... x.x.x.x is his peer |
This has appeared where the partner is a Cisco device and there was a mistake in the partner‘s NAT translation for the address of the firewall (or destination hosts) on our side | |
|
PIX debug output of:
|
Ignore it. Normal message. You‘ll see lots of them. This is just garbage collection looking for stale SA‘s to clean up | |
|
PIX debug output of:
|
Well, phase one has completed, but phase 2 is failing. Most commonly, this is just another manifestation of mismatched encryption domains, where you have a network specified and s/he has a single host | |
|
PIX debug output of:
|
Probably not the source of your problem -- this is usually just a sign that something is negotiating the maximum MTU | |
|
PIX debug output of:
|
Mismatch between your transform-set and peer‘s, or your transform-set is somehow invalid | |
|
Normal-looking IPSEC(initialize_sas): ,messages
no then
|
Probably, the peer is specifying single hosts on his key exchange, while you have a subnet specified. If peer won‘t turn on key exchange for subnets (Checkpoint) or expand ACL‘s to match your subnet (PIX) then you‘ll have to change your ACL‘s to contain each lousy host. Can also happen if you‘ve simply specified one or he other encryption domain incorrectly (typo?) or specified the wrong "match " or peer in the crypto map (bad cut‘n‘paste) Note that this is an IPSec message. Very possibly, there‘s already a good ISAKMP SA, and you will not see any additional ISAKMP traffic during debug -- just the annoying repeated message. Possibly there‘s an "incomplete" ISAKMP SA in memory that you won‘t even see with a "sho crypto isakmp sa" command. On 6.3(1) I have once seen this message in a PIX-to-PIX setup, when the PIX believed there was a mismatch because I had specified
instead of
which looks like a bug to me. |
|
|
No phase one messages seen at all Nothing but
and no other messages |
I really think this is the same thing as when one see normal phase one messages, and then sees this afterwards. This drives me nuts. I‘m going to have to get a sniffer out and prove what‘s going on. In this case, you never see ANY kind of ISAKMP messages, or any other IPSec messages. That looks as though you are never sending anything out -- that it‘s trappped on your side and you never even try and negotiate a tunnel But I‘m damned if I don‘t think that the traffic is going on and the messages just aren‘t displaying. Because every time I‘ve seen it, it‘s always been a subnet mismatch that caused it. If you control both ends then it‘s fairly easy to compare the VPN ACL‘s with a " If you control only one endpoint and a have a recalcitrant person running the other, who insists their side is completely correct, then good luck. All I can do is to repeat that every single time I have ever seen this, a subnet mismatch was the cause, even though there were no ISAKMP or IPSec messages to indicate the two machines were in communication. Interestingly enough, this "no other messages" condition has happened to me only when I had IOS boxes on both ends, which makes me think that the two must have some comm going that just doesn‘t show in the debug. Note: I had this happen to me this afternoon, and the root cause was me trying to be tricky. I had a subnet 10.0.0.0/28 call it, that had been expanded to 10.0.0.0/27. I had an existing network object like so:
I was lazy and tried to make the same object work in both tunnels using the old definition and the new one, so I made it:
I‘ve had that kind of trick work many times with things like:
when the other guy insisted on using hosts. Well, today, it broke the tunnel. Fine, I was cheating anyway, but the point is that even in the absence of other debug messages, the two had to be talking for either side to know there was a mismatch. This morning‘s incarnation of this bug is nothing which isn‘t implied by the foregoing, but is worth a note. The Checkpoint peer included its own external IP address in its encryption domain. We didn‘t want to acess it, and in fact rules on our inside interface disallow any such traffic. Nevertheless, the tunnel failed with this error up until we added that gateway address into our remote netwoks object for the VPN ACL. They have to matcheven if the traffic will never flow. An unconfirmed report from the mailbag tells of a tunnel problem between a PIX 515 and a Cisco 1841. In this case, even having the maps identically defined with
didn‘t work. It seems that the 1841 was internally splitting the "172.20.0.0/255.254.0.0" into individual class C‘s (Class-based setup, maybe?) and the VPN failed until the pix side was defined as
|
|
|
PIX debug output of:
|
Normal message, not a sign of a problem. Your peer has set a "keepalive" (i.e. nailed the tunnel up). This message just means "peer x.x.x.x checked to see if I was still alive." | |
|
PIX debug output of:
ISADB: reaper checking SA 0x11ac374, conn_id = 0 DELETE IT! VPN Peer: ISAKMP: Peer ip:x.x.x.x/500 Ref cnt decremented to:0 Total VPN Peers:8 |
Hmm, could be anything on the peer side. Be sure to explicitly specify " isakmp identity address" before doing much more.
|
|
|
Partner is a VPN concentrator.. PIX debug messages are :
but no connect |
You‘ve completed phase 1 OK, the eror is somewhere in phase 2 | |
| Phase one goes OK, you see NOTHING for phase two. |
Difficult to debug, of course. Silence always is. MOST likely, your partner has things fouled up. But let me note some weird things that I‘ve seen cause this: A dual-homed Windows Server 2003 partner caused this when he routed traffic to my VPN peer out of the correct interface, and traffic for the actual host out the wrong interface. Another dual-homed Windows Server 2003 partner caused this when he had two default gateways specified (thinking he needed one for each interface) and created essentially the same situation. I once caused this on the PIX side by accidenatlly specifying a network IP as a host in my objects, i.e.
when I meant
|
|
|
PIX debug output of:
|
Not an error, per se. Your peer just sent you a "delete ipsec sa" instruction | |
|
PIX debug output of:
|
Not an error, per se. Your peer just sent you a "delete isakmp sa" instruction | |
| All VPN messages look good. The PIX logs show a "NO TRANS" error | This is a NAT issue, not a VPN issue. See my preliminary notes towards a page on that here. | |
| All VPN messages look good. The PIX logs show a translation being built. The connection dies with a SYN timeout | If you are sure that the VPN is all good, then this is rourting or firewalling somewhere beyond your own VPN gateway. | |
|
Your partner is a Checkpoint. In his/her logs, your counterpart sees
reason: Client Encryption: User Unknown OM: Failed to obtain user object or unknown user Despite the fact that this is obviously not a SecuRemote client attempting to connect via a client VPN. |
This is a misconfiguration on the PIX side. The PIX is using dynamic or client VPNs for some other connection, and is getting confused. If your crypto map contains both static and dynamic entries, alway give ALL of the statics a LOWER sequence number than ANY of the dynamics. If any of your isakmp keys are wildcarded it should see the non-wildcard entries FIRST Add " |
|
|
Your partner is a Nokia Crypto Cluster. Things look fine on your end. The person configuring the Cluster says they get a message of " |
This is the Crypto Cluster‘s way of complaining about an ISAKMP identity issue. It‘s looking for you to send a string identifying your firewall as a (supposedly optional) part of the negotiation. See above. Look for "
|
|
| Your partner is a Nokia Crypto Cluster. The partner says they see a "tunnel come up" on their Nokia | They only mean they see at least a phase 1 completion. No promises about phase 2 | |
| Tunnel comes up, initial contacts are OK, client fails on large packets |
Someone, somewhere has not accounted for the overhead added by the VPN. I.e., the packet size plus the bytes added for the VPN encapsulation give you packets too big for ethernet, but which are marked "don‘t fragment" You can throttle this back on your side with:
|
VPN debugging notes