12-05-2010 08:51 PM
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
Solved! Go to Solution.
01-29-2011 03:45 PM
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=
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
12-05-2010 09:15 PM
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
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
12-05-2010 09:29 PM
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
12-05-2010 09:42 PM
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
12-05-2010 10:04 PM
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!
12-06-2010 05:29 AM
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
12-06-2010 02:11 PM
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
12-07-2010 05:39 AM
It does sound like a support case would be the reasonable next step. Please let us know how it turns out.
HTH
Rick
01-29-2011 03:45 PM
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=
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
01-29-2011 05:54 PM
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