Crypto ISAKMP SA Debug

[config t]

Seeing this on one of my DMVPN hubs. I admittedly need more training on IPSEC as a whole and plan to watch some videos tonight. But for now, am I safe in saying the debug below means the distant end has a mismatched transform set?

Code Select Expand

Nov  4 09:49:07.353: ISAKMP (74528): received packet from X.X.X.X dport 500 sport 500 Global (R) QM_IDLE     
Nov  4 09:49:07.353: ISAKMP: set new node 413457031 to QM_IDLE     
Nov  4 09:49:07.353: ISAKMP:(74528): processing HASH payload. message ID = 413457031
Nov  4 09:49:07.353: ISAKMP:(74528): processing SA payload. message ID = 413457031
Nov  4 09:49:07.353: ISAKMP:(74528):Checking IPSec proposal 1
Nov  4 09:49:07.353: ISAKMP: transform 1, ESP_AES
Nov  4 09:49:07.353: ISAKMP:   attributes in transform:
Nov  4 09:49:07.353: ISAKMP:      encaps is 2 (Transport)
Nov  4 09:49:07.353: ISAKMP:      SA life type in seconds
Nov  4 09:49:07.353: ISAKMP:      SA life duration (basic) of 3600
Nov  4 09:49:07.353: ISAKMP:      SA life type in kilobytes
Nov  4 09:49:07.353: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
Nov  4 09:49:07.353: ISAKMP:      authenticator is HMAC-SHA
Nov  4 09:49:07.353: ISAKMP:      key length is 128
Nov  4 09:49:07.353: ISAKMP:      group is 2
Nov  4 09:49:07.353: ISAKMP:(74528):atts are acceptable.
Nov  4 09:49:07.353: ISAKMP:(74528): IPSec policy invalidated proposal with error 256
Nov  4 09:49:07.355: ISAKMP:(74528): phase 2 SA policy not acceptable! (local X.X.X.X remote X.X.X.X)
Nov  4 09:49:07.355: ISAKMP: set new node 2846154503 to QM_IDLE     
Nov  4 09:49:07.355: ISAKMP:(74528):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
        spi 139792137676088, message ID = 2846154503
Nov  4 09:49:07.355: ISAKMP:(74528): sending packet to X.X.X.X my_port 500 peer_port 500 (R) QM_IDLE     
Nov  4 09:49:07.355: ISAKMP:(74528):Sending an IKE IPv4 Packet.
Nov  4 09:49:07.355: ISAKMP:(74528):purging node 2846154503
Nov  4 09:49:07.355: ISAKMP:(74528):deleting node 413457031 error TRUE reason "QM rejected"
Nov  4 09:49:07.356: ISAKMP:(74528):Node 413457031, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH

[Dieselboy]

Not necessarily. I have had this problem and both sides had EXACTLY the same configuration. Took me a couple of days to fix it. In the end, a reboot was the fix. I have since had this problem and sometimes removing all the config and pasting it back in does the trick. Could also be a mistake with one side of the config

The logs are saying that something is wrong with the phase 2 part.

[config t]

Did you reboot the DMVPN hub router or the spoke?

The customer doesn't seem to care enough to actually troubleshoot it at the moment and haven't responded to my emails or phone calls. It's a failover link.. they will be VERY interested in troubleshooting it when it doesn't come up. This is why I archive emails..

I could pull a sneaky and reboot their router remotely 

Anyway, I have been learning the bit about defaulting and reconfiguring tunnel interfaces too. I don't know why that works but it definitely does sometimes.

Cheers

[Dieselboy]

I rebooted both. Seems the config was not applied. But I had better results by removing and re-adding the config. TAC said the same. I think you can also try adding the same config again with different names to try and work around it.

Whats the defaulting the tunnel interface? Like "default interface tunnelXX" ? I did not think to try that. TAC said to remove the IPSEC config from the tunnel, then remove/add or add new IPSEC VTI config, then add the line back to the tunnel and no shut the tunnel.

It's a PITA. When it works it's fine but when it doesnt work and the logs show that your config is wrong but it is not wrong, then I've had to fiddle with the config and bang my head until it works.

Although once, I did miss out one line in the config and once I realised and pasted it in - everything worked.

[deanwebb]

Agree with Diesel, I've had cases where I wiped the default config, typed in the one I wanted, and got Phase 2 errors until we bounced the Cisco end. The Juniper end of the DMVPN was fine...

[config t]

I rebooted both. Seems the config was not applied. But I had better results by removing and re-adding the config. TAC said the same. I think you can also try adding the same config again with different names to try and work around it.

Whats the defaulting the tunnel interface? Like "default interface tunnelXX" ? I did not think to try that. TAC said to remove the IPSEC config from the tunnel, then remove/add or add new IPSEC VTI config, then add the line back to the tunnel and no shut the tunnel.

It's a PITA. When it works it's fine but when it doesnt work and the logs show that your config is wrong but it is not wrong, then I've had to fiddle with the config and bang my head until it works.

Although once, I did miss out one line in the config and once I realised and pasted it in - everything worked.

Yeah "default interface tunnelXX" - that's how I do it. I'm not sure how the distant end is doing it when I tell them to default the tunnel and reconfigure. My guess is they are just blowing it away and pasting in the config again.

I've also had it work by ONLY reconfiguring the key. I asked the distant end do it.. no result. Then I reconfigured the key on my end (same key we used the first time) and it formed the SA and the tunnel went up. Silly Cisco.

Oddly, after this particular scenario I SSH'd into their router and discovered they had configured the key in plain text, and my end was encrypted. And it still worked.

Another concern for this environment is transport since we are using VSAT terminals between Kuwait and Bahrain. So that adds another layer of WTF.

Had to Google PITA.. forgot about that one 

[deanwebb]

I deal with PITA every day, so I'm current on that term.

And good mentioning the plaintext working when the other side is encrypted. I *hate* that! You'll be chugging along, thinking everything is encrypted and then there's a tap on your shoulder and a manager with an audit finding...