SRP527W trouble forming VPN with 1841

[smith.dean]

I am currently trying to set up a site-to-site VPN between an SRP527W and a Cisco 1841 but am failing to negotiate a connection at level 1.  The isakmp appears to be failing with the dreaded MM_NO_STATE message prominent in the crypto isakmp debug output on the 1841.  Regardless of what parameters I seem to set on the SRP527W, I can't negotiate a connection when mirroring the settings on the 1841.  The only variable I can think that "may" differ between the two (PSK, DH group, encryption type) is the lifetime association tied to the isakmp setting.  Whilst you can set this on the 1841 isakmp policy, there's nowhere on the SRP527W GUI that it can be set; at least as far as I can tell.  I have tried changing the encryption types between AES, DES and 3DES variations (matching at both ends) but continue to get the MM_NO_STATE errors as per the below isakmp debug output:

Dec  6 14:40:20 AEDT: ISAKMP: received ke message (1/1)

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0): SA request profile is (NULL)

Dec  6 14:40:20 AEDT: ISAKMP: Created a peer struct for <remote_SRP527_peer>, peer port 500

Dec  6 14:40:20 AEDT: ISAKMP: New peer created peer = 0x635C57B0 peer_handle = 0x8000003E

Dec  6 14:40:20 AEDT: ISAKMP: Locking peer struct 0x635C57B0, IKE refcount 1 for isakmp_initiator

Dec  6 14:40:20 AEDT: ISAKMP: local port 500, remote port 500

Dec  6 14:40:20 AEDT: ISAKMP: set new node 0 to QM_IDLE     

Dec  6 14:40:20 AEDT: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 62EB7888

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0):Can not start Aggressive mode, trying Main mode.

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0):found peer pre-shared key matching 203.217.8.56

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0): constructed NAT-T vendor-07 ID

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0): constructed NAT-T vendor-03 ID

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0): constructed NAT-T vendor-02 ID

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0):Old State = IKE_READY  New State = IKE_I_MM1

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0): beginning Main Mode exchange

Dec  6 14:40:20 AEDT: ISAKMP:(0:0:N/A:0): sending packet to <remote_SRP527_peer> my_port 500 peer_port 500 (I) MM_NO_STATE

Dec  6 14:40:30 AEDT: ISAKMP:(0:0:N/A:0): retransmitting phase 1 MM_NO_STATE...

Dec  6 14:40:30 AEDT: ISAKMP (0:0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1

Dec  6 14:40:30 AEDT: ISAKMP:(0:0:N/A:0): retransmitting phase 1 MM_NO_STATE

Is there something I am overlooking here or are there known compatibility issues with certain encryption types / config parameters when trying to set up a site to site VPN with an 1841?  Incidentally, here is the 1841 config snippet I am trying to use:

crypto isakmp policy 10

encr 3des !!! have also tried aes at both ends too

authentication pre-share

group 2  !!! have tried group 1 on both ends too

lifetime 43200 !!! have also tried removing this

crypto isakmp key <key> address <remote_SRP527_peer>

!

crypto ipsec transform-set RMCG-RFC esp-3des esp-sha-hmac !!! have tried many variations here too

!

crypto map RMCG-RFC 11 ipsec-isakmp

set peer <remote_SRP527_peer>

set security-association lifetime kilobytes 2000000

set security-association lifetime seconds 7800 !!! matches on SRP527W IPSEC config end

set transform-set RMCG-RFC

set pfs group2 !!! have also tried disabling PFS at both ends

match address VPN

qos pre-classify

!

ip access-list extended VPN

permit ip 10.0.1.0 0.0.0.255 192.15.0 0.0.0.255

!

int dialer1

crypto map RMCG-RFC

I'm at a loss here and if anyone could offer any suggestions, I'd be greatly appreciative.

[Richard Burts]

I am not familiar with SRP527W and am fairly familiar with 1841. So I might be missing something about your situation. But what I see in the debug is that your 1841 received a key exchange message and then this happened:

1841 sent a packet to SRP527, 1841 retransmitted the packet, 1841 retransmitted the packet again (see details from output below). To me this indicates that the SRP527 is not happy with something that the 1841 sent. Are there any log messages or any debug capability on the SRP527 to investigate what it is doing?

beginning Main Mode exchange

sending packet to my_port 500 peer_port 500 (I) MM_NO_STATE

retransmitting phase 1 MM_NO_STATE...

incrementing error counter on sa, attempt 1 of 5: retransmit phase 1

retransmitting phase 1 MM_NO_STATE

HTH

Rick

[smith.dean]

Thanks for the reply Richard, and unfortunately, that is the issue I have; the SRP527 offers absolutely no feedback regarding the process.  It is web GUI driven and the only VPN status feedback it offers is whether it is connected or not.  If they were both 1841's (or any IOS based models), I suspect it would be a lot easier to diagnose!  As it stands at the moment, I am trying to troubleshoot with visibility from one side of the connection only.

Regards

[Richard Burts]

Well tha certainly makes troubleshooting more difficult.

Does the SRP527 give you any way to view what is in its config (especially the crypto part of the config)?

HTH

Rick

[smith.dean]

Thanks Richard.  That's a good idea and I'm trying to get the config file off the SRP now.  I can do that, I'm just not sure what format the resulting .cfg file is.  It's all garbled irrespective of what application I try and open it in.  Either a weird encoding issue or is encrypted even.  I now need to figure out how to get this file legible and when done, will analyse it further.  This is my first taste with the SRP series (am normally dealing with, and comfortable with, ISR's).  These things have already left a bad taste in the mouth!

[Richard Burts]

It might be an encoding or encryption issue. And it might just be that the SRP527 was designed to be managed by a GUI and does not have a readable text file of the config.

If you do not succeed in getting a readable text of the config perhaps you can go back to the GUI and verify/record the parameters specified and post them.

HTH

Rick

[smith.dean]

Hi Rick.  I have come to the conclusion that the backup config file is definitely not meant to be read as a text file.  It's the GUI or nothing at all.  I have attached a couple of screen caps for the settings and have changed these around at both ends continually so that the isakmp policy matches whatever parameters I set in the SRP drop down boxes.  It just seems that the SRP doesn't respond to the MM1 requests as the 1841 is getting nothing back.  There is no firewall set up on the SRP either and the 1841 has an ACE on the outbound interface allowing isakmp / udp 500 traffic inbound (although is not getting any hits against it).  I'm at a bit of a loss and think I might try opening a support case against it as a next resort.  Really appreciate your feedback to date though.

Regards

[Richard Burts]

It does sound like a support case would be the reasonable next step. Please let us know how it turns out.

HTH

Rick

[Andrew Hickman · Accepted solution]

Sorry for the late comment here.

You can collect a readable configuration from the SRP in XML format, by collecting the following: http://192.168.15.1/admin/config.xml&xuser=admin&xpassword=.  The backup file is a binary image really intended for device recovery.

Where you able to make any progress by opening a support case?

I've just tried a similar configuration with the following:

SRP521W (1.01.19) -> IPSec/IKE -> Cisco870 (15.1(1)T)

Which works with the config you list above.

Which firmware version are you using with the SRP?  If you need a copy of 1.1.19 before it is posted in a couple of weeks, please let me know.

For reference, this is the IOS configuration I used:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key SECRET-KEY address 192.168.200.162
!
crypto ipsec transform-set SETNAME esp-3des esp-sha-hmac
!
crypto map CISCO 1 ipsec-isakmp
set peer 192.168.200.162
set transform-set SETNAME
set pfs group2
match address 110
!
interface FastEthernet4
ip address 192.168.200.146
crypto map CISCO
!
interface Vlan1
ip address 192.168.9.1 255.255.255.0
!
access-list 110 permit ip 192.168.9.0 0.0.0.255 192.168.15.0 0.0.0.255

SRP Configs are:

Hope that helps.

Andy

[smith.dean]

Hi Andy.  Thanks very much for the effort you went to here.  I believe I have got to the root cause of my problem now and it wasn't a compatibility issue between the SRP and 1841.  It was a conflicting NAT-T rule on the 1841 which was hijacking the ISAKMP negotiation and sending it off to another host on the network (which users externally connect to via L2TP).  There are fundamental design issues with this network I've inherited here and I'm working on how accommodate this VPN differently.  For the short-term, I'm going to try a GRE tunnel to get around the conflicting VPN connections, but that's another story!

Thanks again for your help.

Gareth, I'm still with you; the SRP's aren't my favourite device to deal with.  But I have had to retract my abuse levelled at it in this instance as my problem was not related to that but rather model. 

Regards

[Gareth Tomlinson]

I see you've got it working in Main Mode, at least you've got that far! I still don't see an IKE TTL parameter, i guess you're saying that it is set at 28800 and you can't alter it.

Has anybody got one of these working in Aggressive mode?

[Gareth Tomlinson]

I'm trying to get a site-to-site VPN established from a dynamic IP address to a WatchGuard, and that fails also.

I'm using Main mode and dyndns, which the 527w reports as updated successfully, but the WatchGuard diagnostics say the 527w peer ID is incorrrect.

Aggressive mode also fails with incorrect peer ID reported by the WatchGuard.

I've tried setting the hostname to every different combination of the dyddns name there is with no change.

There is nowhere in the 527w that I can find to enter a local ID, and in addition, where is the IKE TTL? There is only a lifetime parameter on the IPSEC tunnel, which is phase 2.

I'm running the latest OS on the 527w, before anyone asks! I've just powered it off preparatory to throwing it at the wall, so I can't tell you the revision number.