Ping drops possible sign why IPSEC tunnel will not complete phase 1?

[CiscoBrownBelt]

Notice that pings to peer addresses for tunnel can be very slow (compared to similar distance tunnels that work) and also will fail every so many !!!! so I am thinking there is possibly a routing problem. Could this also affect the phase 1 Ikev1 negotiation? I don't believe it is making it past the first 1 or 2 messages in Main mode. Here are some errors that stand-out in debug (can't transfer debugs on here as of now): I do get up to at least ATTs are acceptable so I believe policies are good.

Any Help??

CRYPTO-6IKMP_NOT_ENCRYPTED: IKE packet from xxx was not encrypted and
it should have been

Peer does not do paranoid keepalives

His hash no match - this node outside NAT
vendor ID seems Unity/DPD but major 0 mismatch
vendor ID is DPD

[Rob Ingram]

Hi,
They could just be rate limiting icmp.
Can you provide the full ikev1/isakmp debugs we can have a look

HTH

[CiscoBrownBelt]

Ok thanks. Unfortunately i cant get it at this time. If not from qos, could that be problem? Anything particular in debug I should look out for?

[Rob Ingram]

If there is a connectivity issue, then yes that could cause an issue when establishing a VPN. VPN connectivity does not rely on a ping response, it requires a stable connection.

Slow ping or timeouts do not necessarily indicate an issue that could stop a VPN being established, as mentioned those protocols can be rate limited and therefore be misleading.

If you aren't getting past the MM1/MM2 then that does sound like a comms issue, is there a firewall or ACL in the path? The initial connection is udp/500 to establish IKE SA, then esp and udp/4500 (if nat).

HTH

[CiscoBrownBelt]

Did a packet capture and verified UDP 500 bidirectional traffic between the peers. No natting done. Do you think perhaps a FW in between the peers (handled by ISP) could still be blocking traffic?
The keys should be the same and in debugs it show "Att accepted" so I believe policies match. Do you think perhaps keys are actually mismatched?
I

[Sheraz.Salim]

If there is a firewall in between the peer yes that could be a problem. 
need debug and the configuration from both sides in order to fix the issue.

[CiscoBrownBelt]

Unfortunately transferring or getting configs and debug on here is not possible aside from me typing it all. It makes it to the policies check and showed "Att accepted" or whatever, the pre-share key validation is after that correct? I confirmed the states go from mm_Exchange then goes to mm_no state so that would point to pre-share key mismatch possibly correct? This is being done on the responder end.

[Rob Ingram]

UPDATED: If there is bi-directional udp/500 traffic then a firewall is not going to cause an issue stopping the IKE SA being established. Obviously ESP needs to be allowed between the peers for IPSec SA to be established, but you've NOT got that far yet if you can't establish an IKE SA.

If the PSK were mismatched then you'd fail later than MM2.
Can you provide the configuration and debug so we can spot the error.

HTH

[CiscoBrownBelt]

Sorry Im confused with "but you've got that far yet if you can't establish an IKE SA."
So you mean the PSK check is after all the policies checks (need to get ATT accepted) correct?

[Rob Ingram]

Sorry, I missed a crucial word "you've NOT got that far yet".

IKE SA is established over udp/500, which you've proved is bi-directional, so ACL/FW is not blocking that communication. So Phase 1 is failing, you will need to check IKE policies, PSK, crypto ACL etc mirror the peer.

Here is a useful troubleshooting guide.

[Sheraz.Salim]

if you are using a cisco router than there are few thing you can do on box in order to pin point where the issue could be. I assume you have access to router cli/ssh.

1. debug to run

2. use a monitor capture command to capture the packet. once the packet capture download then to .pcap file. it will show you what and where the communication is breaking down. but debug shall be more useful.

[CiscoBrownBelt]

Yes I can get access. What in particular will I see in the monitor capture as opposed to debug?
I believe only thing I could see on the router/responder (could have been acting as initiator as I did not see actual key authentication fails or anything if I am supposed to) is I think it gets to "ATT accepted" for the policies but then just keeps re-initiating mm_state or something like that. I have to reference it again. Actual key verification/exchange is after that correct?