[Openswan dev]
IPsec bug in Vigor2600 plus series annex A # Firmware Version :
2.5.2_H with multiple SA's
Paul Wouters
paul at xtdnet.nl
Wed Aug 11 12:05:33 CEST 2004
IPsec bug in Vigor2600 plus series annex A # Firmware Version : 2.5.2_H
with multiple SA's.
Hi,
I seem to have stumbled upon a bug in the Vigor router from Draytek. First
let me say that things have improved a lot since the older Vigor's. The
menu's work a lot better, single DES has been almost phased out and AES
has been added. The IPsec tunnels are staying up now too, instead of
being terminated often, and both initiation and repsonding now works.
So I did find a new bug. We're rolling out a few dozen Vigors and plan
to have a configuration with two IPsec tunnels. These tunnels go to the
same server, but are for two different subnets.
So I want something like:
|-------- Vigor -----| |--- Openswan------|
(10.10.10.0/24) 10.10.10.1 --- 1.2.3.4 ------------ 5.6.7.8 --- 10.0.1.1 (10.0.1.0/24)
(10.10.10.0/24) 10.10.10.1 --- 1.2.3.4 ------------ 5.6.7.8 --- 10.0.1.1 (10.0.2.0/24)
Note that in this case it is normal to re-use the same ISAKMP SA for
the second tunnel, which is why this bug might be happening.
First, if I let the Vigor initiate using the "dial" option in the
VPN Connection management menu, I see the following in the logs:
Aug 11 10:16:14 openswan pluto[29509]: "homeuser-openswan-sap" #3135: responding to Main Mode
Aug 11 10:16:14 openswan pluto[29509]: "homeuser-openswan-sap" #3135: Oakley Transform [OAKLEY_DES_CBC (0), OAKLEY_MD5, OAKLEY_GROUP_MODP768] refused due to insecure key_len and enc. alg. not listed in "ike" string
Aug 11 10:16:14 openswan pluto[29509]: "homeuser-openswan-sap" #3135: Oakley Transform [OAKLEY_DES_CBC (0), OAKLEY_SHA, OAKLEY_GROUP_MODP768] refused due to insecure key_len and enc. alg. not listed in "ike" string
Aug 11 10:16:14 openswan pluto[29509]: "homeuser-openswan-sap" #3135: transition from state (null) to state STATE_MAIN_R1
Aug 11 10:16:15 openswan pluto[29509]: "homeuser-openswan-sap" #3135: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Aug 11 10:16:17 openswan pluto[29509]: "homeuser-openswan-sap" #3135: Main mode peer ID is ID_IPV4_ADDR: '194.109.161.130'
Aug 11 10:16:17 openswan pluto[29509]: "homeuser-openswan-sap" #3135: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Aug 11 10:16:17 openswan pluto[29509]: "homeuser-openswan-sap" #3135: sent MR3, ISAKMP SA established
So we got phase 1. The Vigor shows:
Aug 11 09:16:13 10.10.10.1 Vigor: Dialing Node1 (BPB) :
Aug 11 09:16:13 10.10.10.1 Vigor: Dialing Node1 (BPB) :
Aug 11 09:16:13 10.10.10.1 Vigor: Initiating IKE Main Mode to 5.6.7.8
Aug 11 09:16:13 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x00 00 00 00 00 00 00 00 , Next Payload=ISAKMP_NEXT_SA, Exchange Type = 0x2, Message ID = 0x0
Aug 11 09:16:13 10.10.10.1 Vigor: IKE <== I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_SA, Exchange Type = 0x2, Message ID = 0x0
Aug 11 09:16:14 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_KE, Exchange Type = 0x2, Message ID = 0x0
Aug 11 09:16:14 10.10.10.1 Vigor: IKE <== I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_KE, Exchange Type = 0x2, Message ID = 0x0
Aug 11 09:16:14 10.10.10.1 Vigor: Into compute_dh_shared()
Aug 11 09:16:15 10.10.10.1 Vigor: Success! compute_dh_shared()
Aug 11 09:16:15 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_ID, Exchange Type = 0x2, Message ID = 0x0
Aug 11 09:16:15 10.10.10.1 Vigor: IKE <== I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_ID, Exchange Type = 0x2, Message ID = 0x0
Aug 11 09:16:15 10.10.10.1 Vigor: ISAKMP SA established with 5.6.7.8
So far so good. Then we start phase 2 (IKE):
Aug 11 10:16:18 openswan pluto[29509]: "homeuser-openswan" #3136: responding to Quick Mode
Aug 11 10:16:18 openswan pluto[29509]: "homeuser-openswan" #3136: transition from state (null) to state STATE_QUICK_R1
Aug 11 10:16:19 openswan pluto[29509]: "homeuser-openswan" #3136: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug 11 10:16:19 openswan pluto[29509]: "homeuser-openswan" #3136: IPsec SA established
Aug 11 09:16:15 10.10.10.1 Vigor: Start IKE Quick Mode to 5.6.7.8
Aug 11 09:16:16 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0xa0d0e8f4
Aug 11 09:16:16 10.10.10.1 Vigor: IKE <== I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0xa0d0e8f4
Aug 11 09:16:16 10.10.10.1 Vigor: Into compute_dh_shared()
Aug 11 09:16:16 10.10.10.1 Vigor: Success! compute_dh_shared()
Aug 11 09:16:16 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0xa0d0e8f4
Aug 11 09:16:16 10.10.10.1 Vigor: IPsec SA established with 5.6.7.8
So now we have one tunnel up. This is also visible in the VPN connection
management menu on the Vigor.
Now, we dial the second lan-to-lan connection:
Aug 11 09:16:24 10.10.10.1 Vigor: Dialing Node2 (BPB SAP) :
Aug 11 09:16:24 10.10.10.1 Vigor: Dialing Node2 (BPB SAP) :
Aug 11 09:16:24 10.10.10.1 Vigor: Start IKE Quick Mode to 5.6.7.8
Aug 11 09:16:26 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0xa9d4eaf5
Aug 11 09:16:26 10.10.10.1 Vigor: IKE <== I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0xa9d4eaf5
Aug 11 09:16:26 10.10.10.1 Vigor: Into compute_dh_shared()
Aug 11 09:16:26 10.10.10.1 Vigor: Local User: 10.10.10.38:123 -> 216.240.32.50:123 (UDP)
Aug 11 09:16:26 10.10.10.1 Vigor: Success! compute_dh_shared()
Aug 11 09:16:26 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0xa9d4eaf5
Aug 11 09:16:26 10.10.10.1 Vigor: IPsec SA established with 5.6.7.8
Aug 11 09:16:26 10.10.10.1 Vigor: IKE ==> I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x5, Message ID = 0x4a251209
Aug 11 09:16:26 10.10.10.1 Vigor: IKE <== I Cookie=0xff 7f bf 5f af 57 2b 15 , R Cookie=0x53 91 df 93 e8 66 9c fb , Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x5, Message ID = 0x4eb07d8
Aug 11 09:16:31 10.10.10.1 Vigor: Directed ARP request - ARP request directly directed to a host (not broadcasted)
And on the Openswan end:
Aug 11 10:16:29 homeuser pluto[29509]: "homeuser-homeuser-sap" #3137: responding to Quick Mode
Aug 11 10:16:29 homeuser pluto[29509]: "homeuser-homeuser-sap" #3137: transition from state (null) to state STATE_QUICK_R1
Aug 11 10:16:31 homeuser pluto[29509]: "homeuser-homeuser-sap" #3137: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug 11 10:16:31 homeuser pluto[29509]: "homeuser-homeuser-sap" #3137: IPsec SA established
Aug 11 10:16:31 homeuser pluto[29509]: "homeuser-homeuser-sap" #3135: received Delete SA payload: deleting IPSEC State #3136
Aug 11 10:16:31 homeuser pluto[29509]: "homeuser-homeuser-sap" #3135: received and ignored informational message
So for a brief moment we do actually have both tunnels up, but the Vigor
sends a Notify/Delete for our first IPsec SA.
If I reboot both ends for a clean state, and then let the Openswan end
initiate, things go slightly different. Both tunnels come up, but the
Vigor knows of only one. It doesn't seem to send a Notify/Delete, and
Openswan believes both tunnels are actualy up, while the VPN connection
management on the Vigor only shows one connection being active.
I hope that Draytek can fix this bug. If you need more help or information,
please do not hesitate to contact me.
Second, a small bug. It seems the Vigor still sometimes tries to use
single DES first. It would be best if it would try that last, since it is
the most insecure of the possible choices. This is for the "IKE phase 1
proposal" in the Advanced tab in a lan-to-lan profile. Currently, the
Vigor choices for phase 1 are rather strange. I can pick 3DES-SHA1-G2
or 3DES-MD5-G2, but I cannot pick both. The only combination entry
unfortunately has both G1 and 1DES, both of which should be considered
obsolete, especially in the recent developments were the NIST standards
organisation has officially declared DES unfit for use.
This is visible on the Openswan end as:
Aug 11 10:16:14 openswan pluto[29509]: "connection-2" #3135: Oakley Transform [OAKLEY_DES_CBC (0), OAKLEY_MD5, OAKLEY_GROUP_MODP768] refused due to insecure key_len and enc. alg. not listed in "ike" string
Paul Wouters
Xtended Internet
--
Broerdijk 27 Postbus 170 Tel: 31-24-360 39 19
6523 GM Nijmegen 6500 AD Nijmegen Fax: 31-24-360 19 99
The Netherlands The Netherlands info at xtdnet.nl
More information about the Dev
mailing list