Hello,

Thank you for your quick response.

I cannot use ezvpn because the HeadOffice Side is not in my control and is also not cisco (Astaro)

The problem as I can identify is to do with DHCP / NAT at my end.

HeadOffice have given me vpn access with a PSK + fixed to my static IP address e.g 81.112.208.125

If I do the setup as:

192.168.210.0/24----ASA5505VPN-----81.112.208.125-----Internet-----88.193.146.66--------HeadOfficeVPN--192.168.130.0/24

Then my setup works fine as there is no nat

I can set the outside interface with the IP of 81.112.208.125

When I setup a IPSEC VPN it connects first time with no problems.

However if I stick a router in fron of my ASA5505 then the trouble starts:

e.g

192.168.210.0/24---ASA5505VPN---192.168.0.103--Router--81.112.208.125---Internet---88.193.146.66----HeadOfficeVPN

So my side is NATed

In this scenario I get: (extract)

6 Group = 88.193.146.66, IP = 88.193.146.66, Automatic NAT Detection Status:     Remote end is NOT behind a NAT device     This   end   IS   behind a NAT device

5 Group = 88.193.146.66, IP = 88.193.146.66, Received non-routine Notify message: Invalid ID info (18)

5 Group = 88.193.146.66, IP = 88.193.146.66, Received non-routine Notify message: Invalid message id (9)

As far as I can see the issue is that the id for the 5505VPN is now 192.168.0.103 and not 81.112.208.125

I use to have a similar problem on my Billion Router but solved it by Setting Local ID to IP Address 81.112.208.125

I assume I have to do something similar on the ASA5505 unit but am lost as to exactly what and where

Would configure mode commands/options be the correct fix here and if so how would I use it?

Thanks

Tahir,

According to the best of my knowledge neither ASA nor IOS will do that sort of spoofing.

It's an odd reason to drop and certainly not one that we do on our devices unless PSK is missing.

Can you get fill "deb crypto isakmp 255" when the ASA is trying to initiate?

Marcin

Hi Marcin,

It is strange as I would have thought that this was a simple NAT issue.

From what I can work out the HeadOffice Side Tunnel has been set to initate a tunnel with:

e.g 81.112.208.125 and PSK 1234

As the ASA5505 is stuck behind the router and presents its outside interface as 192.168.0.103

then the tunnel will not establish.

If I move the ASA5505 towards the Public WAN so that its outside interface is 81.112.208.125

then everything is good.

The really annoying thing is that the Billion has no problems with this at all!!!

Am I on the right track in identifying the issue or is there something else at fault?

>>Can you get fill "deb crypto isakmp 255" when the ASA is trying to initiate?

I cannot do this via the ASDM and assume I need to do it telenet via the console cable

which I do not have here.

Thanks

Tahir,

During mainmode messages 1-4 we don't exchange IP address.

You only exchange VIDs

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftipsnat.html

"During Internet Key Exchange (IKE) phase 1 negotiation, two types of NAT  detection occur before IKE Quick Mode begins—NAT support and NAT  existence along the network path.

To detect NAT support, you should exchange the vendor identification  (ID) string with the remote peer. During Main Mode (MM) 1 and MM 2 of  IKE phase 1, the remote peer sends a vendor ID string payload to its  peer to indicate that this version supports NAT traversal. Thereafter,  NAT existence along the network path can be determined".

The problem is that the other side might not recognize properly some VID?

Anyway if NAT is detected we should start using NAT-T and again should not be problem from Cisco's side.

The only problem I could see if when IKE peers exchange MM5 and MM6 messages. If ASA is set to send identity as IP address it will most likely send the IP address assigned to interface we have crypto map on.

Are you sure you have nat-t enabled on ASA?

Marcin

>> Are you sure you have nat-t enabled on ASA

Fair Question

*As far as I am aware NAT-T is enabled of ASA unless you disable it.

*I ran crypto isakmp nat-traversal 20 just in case but no joy

*On a Test VPN Tunnel Setup By HeadOffice where they set it to Respond Only and therefore did not fix the Branch End Public IP the IPSECVPN worked fine behind the router. Therefore NAT-T I think is doing its job.

>>it will most likely send the IP address assigned to interface we have crypto map on.

I think this is the root of the problem and unless we can tell it to send an alternative ID, then I am stuck with using the Billion.

Anyway I attach the relevent extracts in case I have missed something obvious

Group = 88.193.146.66, IP = 88.193.146.66, PHASE 1 COMPLETED

Group = 88.193.146.66, IP = 88.193.146.66, De-queuing KEY-ACQUIRE messages that were left pending.

Group = 88.193.146.66, IP = 88.193.146.66, Received non-routine Notify message: Invalid ID info (18)

Teardown UDP connection 83 for outside:192.168.212.11/161 to inside:192.168.210.30/1030 duration 0:02:17 bytes 312

Group = 88.193.146.66, IP = 88.193.146.66, Received non-routine Notify message: Invalid message id (9)

Teardown dynamic UDP translation from inside:192.168.210.30/1044 to outside:192.168.0.103/25949 duration 0:00:30

Group = 88.193.146.66, IP = 88.193.146.66, Received non-routine Notify message: Invalid message id (9)

Teardown dynamic UDP translation from inside:192.168.210.30/1030 to outside:192.168.0.103/6834 duration 0:02:30

Group = 88.193.146.66, IP = 88.193.146.66, Received non-routine Notify message: Invalid message id (9)

Group = 88.193.146.66, IP = 88.193.146.66, QM FSM error (P2 struct &0xd8635630, mess id 0xfff3c84b)!

Group = 88.193.146.66, IP = 88.193.146.66, Removing peer from correlator table failed, no match!

Group = 88.193.146.66, IP = 88.193.146.66, Session is being torn down. Reason: Lost Service

Group = 88.193.146.66, Username = 88.193.146.66, IP = 88.193.146.66, Session disconnected. Session Type: IKE, Duration: 0h:00m:32s, Bytes xmt: 0, Bytes rcv: 0, Reason: Lost Service

IP = 88.193.146.66, Received encrypted packet with no matching SA, dropping

Thank you again for all your help!

Tahir,

Phase 1 is completed! So we might as well forget about VIDs and identity exchange.

I did a quick check on our case DB.

I found several mentions of this log message, every time this is related to PFS settings.

ASA uses group 2 if PFS set.

Some other cases where problem was a misconfiguration of ACLs.

It would not explain why moving device directly to public IP would make things work.

Marcin

Hi Marcin,

Thank you again for the quick response.

I am pretty sure PFS is not inolved.

At the HeadOffice the settings are:

IKE: AES 256  MD5 28800 Group 5 MODP 1536

IPSEC: AES 256 MD5 3600 PFS:None

At my end on the ASA5505 the settings are:

Result of the command: "show run crypto ipsec"

crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

Result of the command: "show run crypto isakmp"

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption aes-256

hash md5

group 5

lifetime 86400

Result of the command: "show run crypto map"

crypto map outside_map 1 match address outside_1_cryptomap

crypto map outside_map 1 set peer  88.193.146.66

crypto map outside_map 1 set transform-set ESP-AES-256-MD5

crypto map outside_map interface outside

So as you can see PFS is disabled on both ends.

In Summary:

Billion S10 Security Device Connects VPN No Problems from behind router and getting its address via DHCP from router as long as I set VPN ID to my Public IP Address 81.112.208.125

ASA5505 No Problems if connected directly to Public IP  81.112.208.125 with above settings

ASA5505 Problem if behind router and getting its outside address via DHCP from router.

Thanks

Tahir,

Well I'd suggest to open a TAC case with both our TAC and whoever is handling the headend device.

It would be interesting to:

1) Know why they reply with invalid ID

2) How the whole debug looks both sides.

Knowing one can maybe explain the other, but having both is being able to get this to work ;-)

Marcin

Hi Marcin,

I think I will have a further play first and as you suggest examine both ends for a more complete picture as to what is happening.

It is not a critical issue as I can still revert back to the Billion or move the ASA unit to Public WAN.

At first I thought it would be a simple command to set the local ID hence my post, but clearly this is not the case!

If after examination of logs on both ends during the weekend, I discover anything new then I will post back here

and obviously also if I do get a solution!

Thanks again for all your advice.

Tahir,

As I said it would be interesting to know what's happening on the headend, as you see this is not a typical message ASA is expecting - thus it cannot react in a way the other side expects.

If possible debugs on both ends would be helpful.

ASA has type isakmp captures - with them you can have a look into IKE packets.

--------

capture IKE type isakmp pack 1512 ....

---------

Marcin