IPSEC tunnel into one WSS data center failed after restart when others worked fine
Article ID: 231518
Updated On:
Products
Issue/Introduction
IPSEC access method into WSS
Users have been accessing WSS via IPSEC tunnel without issues for many months
Cisco vEdge routers tunneling traffic into WSS
After upgrading and restarting the vEdge, users could not longer access web sites through WSS GZAJB1 data center and tunnel was flagged as down.
vEdge had other tunnels from same device into WSS that continued to work during this time (primary was going to GITMI1) - issues only visible with tunnel to GZAJB1
Same tenant had other vEdge tunnels into GZAJB1 data center from other locations and these worked fine.
Environment
Cisco vEdge
IPSEC tunnels into WSS
Cause
vEdge corruption of PSK keys.
Resolution
Recreated the PSK keys on Cisco vEdge.
By doing this, the PSK sent with MM5 exchange was validated successfully by WSS and tunnel was brought up successfully,
Additional Information
From PCAPs and logs, we could clearly see that problem is with the authentication during main mode handshake (IKEv1).
MM5 sends auth request over and WSS rejects it and sends back an error. The following PCAP is taken on the WSS ide, but the same exchange would also be visible on the vEdge side (masked customer IP address for confidentiality)
- packet 5 (MM5) includes the authentication info, and WSS responds with an 'informational' message rather than a successful main mode response (packet 6)
- packet 7 and 8 are MM5 retries and informational response again
- packet 9 (30 seconds later) is a new main mode request to bring up tunnel but hits the same issue
Debug logs on WSS side shows the PLD_MAL informational message returned by WSS.
Dec 3 14:25:28 16[IKE] <77447> 127.132.43.245 is initiating an IKEv1 Main Mode IKE_SA
Dec 3 14:25:28 16[WSS] <77447> Initiator=127.132.43.245, received-proposals='IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024', preferred_auth=pre-shared key, selected-proposal='IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024'
Dec 3 14:25:28 16[WSS] <77447> Initiator=127.132.43.245, Main Mode chose proposal#=0, transform#=1, lifetime=3960
Dec 3 14:25:28 16[NET] <77447> sending packet: from 192.168.3.5[500] to 127.132.43.245[500] (160 bytes)
Dec 3 14:25:28 101[NET] <77447> received packet: from 127.132.43.245[500] to 192.168.3.5[500] (244 bytes)
Dec 3 14:25:28 101[NET] <77447> sending packet: from 192.168.3.5[500] to 127.132.43.245[500] (244 bytes)
Dec 3 14:25:28 38[NET] <77447> received packet: from 127.132.43.245[4500] to 192.168.3.5[4500] (108 bytes)
Dec 3 14:25:28 38[WSS] <77447> Initiator=127.132.43.245, message parsing failed, sending PLD_MAL
Dec 3 14:25:28 38[NET] <77447> sending packet: from 192.168.3.5[500] to 127.132.43.245[500] (76 bytes)
Dec 3 14:25:28 38[WSS] <77447> Initiator=127.132.43.245, ID_PROT request with message ID 0 processing failed
Dec 3 14:25:29 31[NET] <77447> received packet: from 127.132.43.245[4500] to 192.168.3.5[4500] (108 bytes)
Dec 3 14:25:29 31[WSS] <77447> Initiator=127.132.43.245, message parsing failed, sending PLD_MAL
Dec 3 14:25:29 31[NET] <77447> sending packet: from 192.168.3.5[500] to 127.132.43.245[500] (76 bytes)
Dec 3 14:25:29 31[WSS] <77447> Initiator=127.132.43.245, ID_PROT request with message ID 0 processing failed
Dec 3 14:26:01 84[NET] <77448> received packet: from 127.132.43.245[500] to 192.168.3.5[500] (180 bytes)
Dec 3 14:26:01 84[CFG] <77448> looking for an ike config for 192.168.3.5...127.132.43.245
Attachments
Feedback
