| Crypto ISAKMP Debugging I "sooooooooo" give up right now... :-( After 6hrs straight, I'm still no further finding out why my tunnel between an 871w and a CISCO RV220w small business router won't come up. I've gotten rid of "route-map" statements and have opted for a simple "ip nat inside source list..." instead and am still getting nothing. Here's what I'm getting from the debugs:
----------------------------------------------------------------
*Sep 2 18:07:14.514: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Sep 2 18:07:19.358: ISAKMP: set new node 0 to QM_IDLE
*Sep 2 18:07:19.358: ISAKMP:(0):SA is still budding. Attached new ipsec request
to it. (local 71.77.78.79, remote 97.81.82.83)
*Sep 2 18:07:19.358: ISAKMP: Error while processing SA request: Failed to initi
alize SA
*Sep 2 18:07:19.358: ISAKMP: Error while processing KMI message 0, error 2.
*Sep 2 18:07:24.302: ISAKMP:(0):purging SA., sa=837AEBDC, delme=837AEBDC
*Sep 2 18:07:24.514: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
*Sep 2 18:07:24.514: ISAKMP:(0):peer does not do paranoid keepalives.
*Sep 2 18:07:24.514: ISAKMP:(0):deleting SA reason "Death by retransmission P1"
state (I) MM_NO_STATE (peer 97.81.82.83)
*Sep 2 18:07:24.514: ISAKMP:(0):deleting SA reason "Death by retransmission P1"
state (I) MM_NO_STATE (peer 97.81.82.83)
*Sep 2 18:07:24.514: ISAKMP: Unlocking peer struct 0x831BD56C for isadb_mark_sa
_deleted(), count 0
*Sep 2 18:07:24.514: ISAKMP: Deleting peer node by peer_reap for 97.81.82.83:
831BD56C
*Sep 2 18:07:24.514: ISAKMP:(0):deleting node 1876493171 error FALSE reason "IK
E deleted"
*Sep 2 18:07:24.514: ISAKMP:(0):deleting node -502406047 error FALSE reason "IK
E deleted"
*Sep 2 18:07:24.514: ISAKMP:(0):deleting node 542167521 error FALSE reason "IKE
deleted"
*Sep 2 18:07:24.514: ISAKMP:(0):deleting node -483257117 error FALSE reason "IK
E deleted"
*Sep 2 18:07:24.514: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
*Sep 2 18:07:24.514: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_DEST_SA
*Sep 2 18:07:24.534: ISAKMP:(0): SA request profile is (NULL)
*Sep 2 18:07:24.534: ISAKMP: Created a peer struct for 97.81.82.83, peer port
500
*Sep 2 18:07:24.534: ISAKMP: New peer created peer = 0x831B77E0 peer_handle = 0
x8000008F
*Sep 2 18:07:24.534: ISAKMP: Locking peer struct 0x831B77E0, refcount 1 for isa
kmp_initiator
*Sep 2 18:07:24.534: ISAKMP: local port 500, remote port 500
*Sep 2 18:07:24.534: ISAKMP: set new node 0 to QM_IDLE
*Sep 2 18:07:24.534: ISAKMP: Find a dup sa in the avl tree during calling isadb
_insert sa = 837AEBDC
*Sep 2 18:07:24.534: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
*Sep 2 18:07:24.534: ISAKMP:(0):found peer pre-shared key matching 97.81.82.83
*Sep 2 18:07:24.534: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
*Sep 2 18:07:24.534: ISAKMP:(0): constructed NAT-T vendor-07 ID
*Sep 2 18:07:24.538: ISAKMP:(0): constructed NAT-T vendor-03 ID
*Sep 2 18:07:24.538: ISAKMP:(0): constructed NAT-T vendor-02 ID
*Sep 2 18:07:24.538: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
*Sep 2 18:07:24.538: ISAKMP:(0):Old State = IKE_READY New State = IKE_I_MM1
*Sep 2 18:07:24.538: ISAKMP:(0): beginning Main Mode exchange
*Sep 2 18:07:24.538: ISAKMP:(0): sending packet to 97.81.82.83 my_port 500 pee
r_port 500 (I) MM_NO_STATE
*Sep 2 18:07:24.538: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Sep 2 18:07:34.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
*Sep 2 18:07:34.538: ISAKMP (0:0): incrementing error counter on sa, attempt 1
of 5: retransmit phase 1
*Sep 2 18:07:34.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
*Sep 2 18:07:34.538: ISAKMP:(0): sending packet to 97.81.82.83 my_port 500 pee
r_port 500 (I) MM_NO_STATE
I also have some of this mess happening as well:
*Sep 2 18:07:54.534: ISAKMP:(0):SA is still budding. Attached new ipsec request
to it. (local 71.77.78.79, remote 97.81.82.83)
*Sep 2 18:07:54.534: ISAKMP: Error while processing SA request: Failed to initi
alize SA
*Sep 2 18:07:54.534: ISAKMP: Error while processing KMI message 0, error 2.
*Sep 2 18:07:54.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
*Sep 2 18:07:54.538: ISAKMP (0:0): incrementing error counter on sa, attempt 3
of 5: retransmit phase 1
*Sep 2 18:07:54.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
*Sep 2 18:07:54.538: ISAKMP:(0): sending packet to 97.81.82.83 my_port 500 pee
r_port 500 (I) MM_NO_STATE
*Sep 2 18:07:54.538: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Sep 2 18:08:04.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
*Sep 2 18:08:04.538: ISAKMP (0:0): incrementing error counter on sa, attempt 4
of 5: retransmit phase 1
*Sep 2 18:08:04.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
*Sep 2 18:08:04.538: ISAKMP:(0): sending packet to 97.81.82.83 my_port 500 pee
r_port 500 (I) MM_NO_STATE
*Sep 2 18:08:04.538: ISAKMP:(0):Sending an IKE IPv4 Packet.
---------------------------------------------------------------
I've set all timers to "3600 seconds" because I was getting "phase I is timing out" (or something along those lines).
Any thoughts?
Jay |
|
nosx
join:2004-12-27
00000
kudos:5 | I have not seen crypto-map based nat work with NAT if you are not doing destination based route-map NAT exceptions.
Turn NAT off and see if you can troubleshoot it. I remember your setup and there are alot of layers of complexity. |
|
| I actually got gid of the route-maps in the present situation to cut down on the margin of error this time.  Unfortunately, the new ccnp route exam uses crypto map scenarios, which is why I'm hard & heavy on working with them. I'll provide the example I'm basing things off of in just a second...
Thanks for responding |
|
|
|
| reply to DocLarge
Okay,
here's what I'm referencing:
»www.carbonwind.net/VyattaOFR/Vya···mode.htm
I'm running a CISCO 871w on my side; just imagine the Vyatta side as being another CISCO router (actually a CISCO RV220w small business router), and that's pretty much what I'm working with.
Now, if I take down my 871w and put another RV220w in it's place, the tunnel comes up. However, when I have my 871w trying to bring up the tunnel with the RV220w on the other side, nothing happens. Based on that, I'm "positive" the ISP isn't blocking anything, so the issue is with my config on the 871w *shrug*
Jay |
|
| reply to DocLarge
Can you post your config and what you have setup on the RV220? |
|
| reply to DocLarge
Overkill,
here's what I have so far. I've got my config from my 871w, the debugging I did on it, plus the phaseI/phaseII configs from a Linksys WRV54g I've been trying to connect to at another location. I had some users on the RV220w that were experiencing network disruption with my testing so I moved the show to another router
Again, it's the damnest thing; if I put a CISCO (formerly Linksys) router (RV220w) in place of the 871w, the tunnel will come up with the WRV54g. However, if I use the "exact" same config on the 871w to bring up the tunnel with the WRV54g, I get the errors you see in the 871w debug text file *shrug* |
|
| reply to DocLarge
Have you tried removing this line:
set pfs group2
from the config? |
|
| Not really, only because (in tge past whrn I had this working) the cicsco documentation stated I needed thls line for phase 2 DH authentication to match the opposite side (i.e., Wrv54g phase 2 authentication).
I'll take it out and see what happens.... |
|
| reply to OVERKILL
Nope :-(
That didn't work either...
Still looking for a solution... |
|
| Odd.
Not that this helps, but I've used a similar crypto map setup to connect to Linux boxes (IPCop) and BSD (PFSense) without issue. Everything you've done (that I can see at this point, I'll look again) appears correct. |
|
| reply to DocLarge
I know, right??? WTF? I've been at this for a few weeks now(when time permits) and I am no closer to a solution. I'm just glad ni one was paying for this Any other thoughts because I'm just abouy out of ideas at this stage |
|
| reply to DocLarge
Have you tried the simple stuff like using MD5 instead of SHA? |
|
2 edits | Not as of yet; I've been stuck on SHA due to being more secure. At this stage, it's not going to hurt trying that
EDIT:
Still the same thing (no change) :-(
Here's what floors me: before I even got my CCNA, I was configuring site-to-site vpn tunnels all the time. Hell, MSN (whom we rarely ever see these days due to other duties) helped me put the following config together on the exact same router I'm having issues with "and it worked:"
»www.linksysinfo.org/index.php?th···s.22426/
Per NOSX, I've dropped the "route-maps" to lower the level of difficulty to include running a single crypto map and this tunnel still won't come up...
For the life of me, I don't know what's so different all of a sudden
*scratch* *scratch* |
|
| reply to DocLarge
OK, I'll take another look at it tomorrow. Too tired tonight. I do a LOT of VPN stuff, never had this issue. Gotta be something simple.
And yes, USE ROUTE MAPS. They are a blessing. |
|
| Cool.. I'm setting up a new Brother 2270DW printer at the moment and have given up on vpn for the day (have actually spent most of it studying for my "route" exam).
Thanks for checking in. |
|
| reply to DocLarge
Looking at the log I see this -
*Sep 2 18:07:24.538: ISAKMP:(0): beginning Main Mode exchange
*Sep 2 18:07:24.538: ISAKMP:(0): sending packet to 97.81.82.83 my_port 500 pee
r_port 500 (I) MM_NO_STATE
*Sep 2 18:07:24.538: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Sep 2 18:07:34.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
*Sep 2 18:07:34.538: ISAKMP (0:0): incrementing error counter on sa, attempt 1
of 5: retransmit phase 1
*Sep 2 18:07:34.538: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
*Sep 2 18:07:34.538: ISAKMP:(0): sending packet to 97.81.82.83 my_port 500 pee
r_port 500 (I) MM_NO_STATE
It means exactly what it says - ike timed out waiting for a reply from the peer and is retransmitting the initial IKE message. Obviously this is due to one of -
1. The packet is being blocked in the 871 and not getting out
2. The packet is getting out but not getting to the peer
3. The packet is getting to the peer but the peer is
dropping/rejecting it
4. The peer is responding but the packet is not getting back to the
871
5. The packet is getting to the 871 but not getting to the IKE
process
The tools to use in a case like this are -
1. debug ip packet command on the 871 (with an ACL and disable
CEF)
2. Wireshark
3. Logs on the peer.
Once you determine when the packet is getting lost/dropped you will be able to determine why and fix the problem. |
|
| reply to DocLarge
quote:
I've set all timers to "3600 seconds" because I was getting "phase I is timing out" (or something along those lines).
Not sure which timers you are referring to but if it is the SA lifetime then that has no relationship with IKE's timeout. It appears from the logs that the IKE retransmit timer is 10 seconds. |
|
Reviews:
 ·Nexicom
| said by F430 : quote:
I've set all timers to "3600 seconds" because I was getting "phase I is timing out" (or something along those lines).
Not sure which timers you are referring to but if it is the SA lifetime then that has no relationship with IKE's timeout. It appears from the logs that the IKE retransmit timer is 10 seconds. I believe he is referring to the key life time. |
|
| quote:
I believe he is referring to the key life time.
IKE negotiates lifetimes for the SAs it creates but nowhere could I find a reference to key lifetimes. I must have missed it. Could you please explain which keys these are and how does one configure their lifetimes? |
|
Reviews:
·Nexicom
| said by Lasky : quote:
I believe he is referring to the key life time.
IKE negotiates lifetimes for the SAs it creates but nowhere could I find a reference to key lifetimes. I must have missed it. Could you please explain which keys these are and how does one configure their lifetimes? Check his images above, it lists key lifetime at 28800.
In his config:
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 28800
|
|
