VPN question(s)

Hi Frank,

Error Message:

%CRYPTO-4-IKMP_BAD_MESSAGE : IKE message from [IP_address] failed its sanity check or is malformed

Explanation:

A quick verification check is done on all received ISAKMP messages to ensure that all component payload types are valid and that the sum of their individual lengths equals the total length of the received message.

This message indicates a failed verification check.

Persistently bad messages could mean a denial-of-service attack or bad decryption.

Recommended Action:

Contact the administrator of the remote peer.

-------------------------------------------------

PIXs and Cisco routers

Symptom/Message:

(Router) log message of

CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from x.x.x.x failed its sanity check or is malformed

Likely cause or solution:

Pre-shared key mismatch.

This is more often a router VPN message than a PIX VPN message.

-------------------------------------------------

It seems to be a preshared mismatch.

Make sure they are both the same.

Remember if you are going to make a change you need to disable the crypto map on the interface, make the changes and then enable it back.

Changes made without following these steps might not work properly.

-------------------------------------------------

Verify your crypto settings on both devices match, all the way to the SA lifetimes.

Run a 'sh run' on both devices and check your crypto statements line by line.

If they match and are all correct, remove all the lines, clear your SAs, and apply the lines once again.

This way you know you started with a clean slate.

-------------------------------------------------

Issuing a "clear crypto sa" will clear the problem.

In the past, Cisco TAC has indicated that the problem is due to the use of the keyword "any" in the crypto ACL

Sincerely,

Brad Reese

I also thought so but they are identical. I'll go and check the quoted web sites but I still wonder if this _can_ work with the NAT inbetween? I can't find the interesting point in the debug output and I'm running out of ideas what's wrong here ...

Regards

fw

Yes. Turn on NAT-T (NAT Traversal). On PIX 6.3, that would be isakmp nat-traversal 20

If NAT-T is not enabled, there is still the -possibility- that it will work, provided that that DSL router is able to forward ESP (IP Protocol 50) to the 1710. On some DSL routers, that might require configuring some sort of "DMZ" option; without that, it isn't possible on a number of consumer NAT'ing DSL routers, as it is not uncommon on consumer devices to only be able to specify forwarding destinations for TCP and UDP.

Note: if the 1710 does not have a fixed IP address (e.g., if the DSL line is using PPPoE and having a dynamic IP assigned to it), then the 1710 will have to initiate the connection to the PIX 515, and the PIX 515 will have to receive it using a "crypto dynamic-map" entry.

NAT-T has to be anabled on the PIX? I supposed I need something like this on the DSL router but it only has "VPN passthrough". Anyway, I must admit that I don't know what either one does exactly :( ...

It _is_ enabled now but the tunnel still doesn't come up. May I send you some config by mail?

It's a Netgear FVG318 which has a DMZ option - but this is more like a "honey pot". Even worse, this router has VPN features and therefore might capture some of the IPsec traffic instead of forwarding it. BTW: I also didn't get it running with the Netgear as the client.

Seems to be the case.

Sure :) ...

I'm still wondering how exacylt the "crypto" things work and what command is resposnible for what effect. If there is a dynamic map, can I restrict VPN clients by hostname or whateer or can any router connect as soon as it has the PSK? Do VPN clients (the Cisco software) interfere with the above setup or does this work concurrently?

TIA

fw

It works! The only thing missing was an approprate entry in the "no NAT" ACL on the PIX ...

Now I can access the corporate LAN from the 1710 and I can "ping" the 1710 from there. As I have a static crypto map on the 1710, the ACL and the defined peer work like route. This doesn't apply to the dynamic map on the PIX. What gateway would I have to use for a backward route from the corporate LAN to the home network? I can't establish the tunnel in this direction but is even the traffic one-way?

TIA

fw

Ensure that the subnet used by the 1710 network is not part of the same network "inside" the PIX; after that, your normal default route on the PIX will take care of returning packets.

With the 1710 not having a static IP, the traffic restriction is just that if the tunnel is not up, the PIX cannot start the tunnel back to the 1710. When the tunnel is up, connections can be started in either direction.

The reason that the PIX cannot bring up the tunnel is not because of some arcane IPSec mechanism: quite simply, when the tunnel is down then the PIX cannot bring it back up because it doesn't know the current IP address of the 1710! (The address might have changed since the PIX last talked to the 1710.)

But other than the fact that the PIX cannot bring the tunnel up, when the tunnel -is- up, it is just as if it were a standard site-to-site tunnel.

The routing really seems to be handled by the ACL exchange in the backward direction. The fact that I can't reach all addresses in my network from the other end of the tunnel is probably caused by an internal routing issue.

Walter, I'm pretty aware of that. What I wanted to say is: even if the DSL router/the 1710 had a static address it might be a problem as the DSL router has some VPN capabilities of its own (and therefore might do things with the incoming packets) and cannot forward IPsec to an internal address.

Regards

fw