Hello everyone,
It was a real nightmare to configure a tunnel between a DIR-330 and a DFL-860E across PPPoE behind the DIR-330. I finally got it to work correctly, but the following is very weird:
1) There are 3 VPN tunnels defined on the DFL-860E, and all 3 are established normally.
The 127.127.127.127 fake IP is a DIR-330 that was configured and running in 30 seconds.
The 042.042.042.042 fake IP is a Cisco RV042 that took some time to get to work, but the tunnel is stable.
The 330.330.330.330 fake IP is another DIR-330, that seems to be causing all the problems.
Notice that tunnel 2 and 3 are for the same local net (I had to add an IP in that range in the DFL-860E ARP table).
DFL-860E:/> ipsecstats -ipsec
--- Active IPsec SAs:
Displaying one line per SA-bundle
IPsec Tunnel Local Net Remote Net Remote Endpoint
------------------ ------------------ ------------------ ------------------
AD_VPN_127 192.168.16.0/24 192.168.27.0/24 127.127.127.127
DNS_VPN_StLaurent 10.10.0.0/16 10.1.0.0/16 042.042.042.042
DNS_VPN_Ottawa 10.10.0.0/16 10.4.0.0/24 330.330.330.330
2) The DIR-330 is configured with Main mode, DH group 2, and IKE proposal list 1 to 4 with 3DES/MD5 only. When I look at the status of the IPsec connection on the DFL-860E web UI, I see this. Notice the protocol, aes-cdc, when only 3DES was in the IKE Proposal List:
Remote Gateway Local Net Remote net Protocol
330.330.330.330 10.10.0.0/16 10.4.0.0/24 [b]aes-cbc[/b]
2) The tunnel is established, communication flows correctly inside the tunnel, and the DFL-860E still reports IPSEC negotiation errors as if the tunnel was not established.
The following is from the log of the DFL-860E.
2012-02-12 15:18:44 Warning IPSEC 1800106 ike_invalid_payload
local_ip=860.860.860.860 remote_ip=330.330.330.330 cookies= reason="IKE_INVALID_COOKIE"
2012-02-12 15:18:34 Info IPSEC 1802708 ike_sa_destroyed
ike_sa_killed
ike_sa=" Initiator SPI ESP=0x30389952, AH=0x4e876072, IPComp=0x5f96928"
2012-02-12 15:18:34 Warning IPSEC 1802022 ike_sa_failed
no_ike_sa
statusmsg="Invalid payload type" local_peer="860.860.860.860 ID No Id" remote_peer="330.330.330.330 ID No Id" initiator_spi="ESP=0x30389952, AH=0x4e876072, IPComp=0x5f969289"
2012-02-12 15:18:34 Warning IPSEC 1802715 event_on_ike_sa
side=Responder msg="failed" int_severity=6
2012-02-12 15:18:34 Warning IPSEC 1800106 ike_invalid_payload
local_ip=860.860.860.860 remote_ip=330.330.330.330 cookies=303899524e8760725f9692892e7ffe8a reason="Invalid payload type in encrypted payload chain, possibly because of different pre-shared keys"
3) ikesnoop on the DFL-860E during the same timframe shows some negociation taking place from the DIR-330, but there is only 1 VPN defined on the DIR-330, and as I said, it's properly established and working...
DFL-860E:/> ikesnoop -on -verbose 330.330.330.330
Ike snooping is active - verbose mode; snooping address 330.330.330.330
2012-02-12 15:17:54: IkeSnoop: Received IKE packet from 330.330.330.330:500
2012-02-12 15:17:54: IkeSnoop: IKE packet belongs to unknown IKE SA
2012-02-12 15:18:34: IkeSnoop: Received IKE packet from 330.330.330.330:500
Exchange type : Identity Protection (main mode)
ISAKMP Version : 1.0
Flags :
Cookies : 0x303899524e876072 -> 0x00000000
Message ID : 0x00000000
Packet length : 100 bytes
# payloads : 2
Payloads:
SA (Security Association)
Payload data length : 48 bytes
DOI : 1 (IPsec DOI)
Proposal 1/1
Protocol 1/1
Protocol ID : ISAKMP
SPI Size : 0
Transform 1/1
Transform ID : IKE
Life type : Seconds
Life duration : 28800
Encryption algorithm : 3DES-cbc
Hash algorithm : MD5
Authentication method : Pre-Shared Key
Group description : MODP 1024
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : af ca d7 13 68 a1 f1 c9 6b 86 96 fc 77 57 01 00
Description : draft-ietf-ipsec-dpd-00
2012-02-12 15:18:34: IkeSnoop: Sending IKE packet to 330.330.330.330:500
Exchange type : Identity Protection (main mode)
ISAKMP Version : 1.0
Flags :
Cookies : 0x303899524e876072 -> 0x5f9692892e7ffe8a
Message ID : 0x00000000
Packet length : 260 bytes
# payloads : 10
Payloads:
SA (Security Association)
Payload data length : 48 bytes
DOI : 1 (IPsec DOI)
Proposal 1/1
Protocol 1/1
Protocol ID : ISAKMP
SPI Size : 0
Transform 1/1
Transform ID : IKE
Life type : Seconds
Life duration : 28800
Encryption algorithm : 3DES-cbc
Hash algorithm : MD5
Authentication method : Pre-Shared Key
Group description : MODP 1024
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 8f 9c c9 4e 01 24 8e cd f1 47 59 4c 28 4b 21 3b
Description : SSH Communications Security QuickSec 2.1.0
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 27 ba b5 dc 01 ea 07 60 ea 4e 31 90 ac 27 c0 d0
Description : draft-stenberg-ipsec-nat-traversal-01
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 61 05 c4 22 e7 68 47 e4 3f 96 84 80 12 92 ae cd
Description : draft-stenberg-ipsec-nat-traversal-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 44 85 15 2d 18 b6 bb cd 0b e8 a8 46 95 79 dd cc
Description : draft-ietf-ipsec-nat-t-ike-00
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : cd 60 46 43 35 df 21 f8 7c fd b2 fc 68 b6 a4 48
Description : draft-ietf-ipsec-nat-t-ike-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f
Description : draft-ietf-ipsec-nat-t-ike-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56
Description : draft-ietf-ipsec-nat-t-ike-03
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 4a 13 1c 81 07 03 58 45 5c 57 28 f2 0e 95 45 2f
Description : RFC 3947
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : af ca d7 13 68 a1 f1 c9 6b 86 96 fc 77 57 01 00
Description : draft-ietf-ipsec-dpd-00
2012-02-12 15:18:34: IkeSnoop: Received IKE packet from 330.330.330.330:500
Exchange type : Identity Protection (main mode)
ISAKMP Version : 1.0
Flags :
Cookies : 0x303899524e876072 -> 0x5f9692892e7ffe8a
Message ID : 0x00000000
Packet length : 180 bytes
# payloads : 2
Payloads:
KE (Key Exchange)
Payload data length : 128 bytes
NONCE (Nonce)
Payload data length : 16 bytes
2012-02-12 15:18:34: IkeSnoop: Sending IKE packet to 330.330.330.330:500
Exchange type : Identity Protection (main mode)
ISAKMP Version : 1.0
Flags :
Cookies : 0x303899524e876072 -> 0x5f9692892e7ffe8a
Message ID : 0x00000000
Packet length : 180 bytes
# payloads : 2
Payloads:
KE (Key Exchange)
Payload data length : 128 bytes
NONCE (Nonce)
Payload data length : 16 bytes
2012-02-12 15:18:34: IkeSnoop: Received IKE packet from 330.330.330.330:500
2012-02-12 15:18:34: IkeSnoop: Sending IKE packet to 330.330.330.330:500
Exchange type : Informational
ISAKMP Version : 1.0
Flags :
Cookies : 0x303899524e876072 -> 0x5f9692892e7ffe8a
Message ID : 0xf41679ba
Packet length : 173 bytes
# payloads : 1
Payloads:
N (Notification)
Payload data length : 141 bytes
Protocol ID : ISAKMP
Notification : Invalid payload type
Notification data:
Notify message version: 1
Offending payload type: Unknown payload type
Error text: "Incorrect pre-shared key (Invalid next payload value)"
Offending message ID: 0x00000000
ikesnoop -off
So the questions are:
a) Why was the tunnel established using AES instead of 3DES?
b) Where do the IPsec negociation retries come from and how do we stop them?
Thanks in advance!
Author
Topic: DFL-860E logging IPSec error on a tunnel correctly established (Read 11186 times)