YAMAHA RTX1500 に Open Source で IPsec リモートアクセス

Linux で IPsec のリモートアクセス VPN - バイナリアンを目指して

リモートアクセス VPN を IPsec で行う場合、Tunnel Mode の Aggressive Mode で XAUTH と mode-cfg を組み合わせて利用する。(今回は L2TP は考慮していない)
Open Source の IPsec 実装の利用を前提に、前述の構成に関する情報を調べていくと、いくつか落とし穴があり、動作する構成が意外に少ないので整理しておくことにする。

どういう組み合わせなら安定して動作するのかというと、まだまだ調査中なので随時まとめていくつもりです。

という訳で、YAMAHA RTX1500 へのリモートアクセス接続に関するまとめ。
http://netvolante.jp/products/rtx1500/

結論としては、XAUTH と mode-cfg を組み合わせて接続できる構成は見つからなかった。
ただし、XAUTH だけならば racoon を利用して接続可能。

RTX1500 の設定

http://netvolante.jp/download/firmware/index.html
ファームウェアは 8.03.75。
ipsec ike payload type は OpenSWAN の場合のみ指定。

# RTX1500 Rev.8.03.75 (Tue Apr 15 11:14:13 2008)
# Reporting Date: Oct 1 12:28:06 2008
login password *
console character ascii
ip route default gateway 172.16.0.1
ip route 192.168.100.0/24 gateway tunnel 1
ip lan1 address 10.1.1.1/24
ip lan1 proxyarp on
ip lan2 address 172.16.0.254/24
tunnel select 1
ipsec tunnel 1
ipsec sa policy 1 1 esp 3des-cbc sha-hmac
ipsec ike always-on 1 off
ipsec ike encryption 1 3des-cbc
ipsec ike esp-encapsulation 1 off
ipsec ike group 1 modp1024
ipsec ike hash 1 sha
ipsec ike keepalive log 1 on
ipsec ike local address 1 172.16.0.254
ipsec ike log 1 key-info message-info payload-info
ipsec ike payload type 1 3
ipsec ike pfs 1 off
ipsec ike pre-shared-key 1 *
ipsec ike remote address 1 any
ipsec ike remote name 1 myid
ipsec ike xauth request 1 on 11
ipsec ike mode-cfg address 1 1
ipsec auto refresh 1 on
ip tunnel tcp mss limit auto
tunnel enable 1
ipsec ike mode-cfg address pool 1 10.1.1.110-10.1.1.112/32
syslog debug on
auth user 1 user1 password
auth user group 11 1-3
auth user group attribute 11 xauth=on

vpnc 0.5.1

vpnc - client for cisco vpn concentrator

vpnc - client for cisco vpn concentrator
vpnc is supposed to work with:
* Cisco VPN concentrator 3000 Series
* Cisco IOS routers
* Cisco PIX / ASA Zecurity Appliances
* Juniper/Netscreen
Supported Authentications: Pre-Shared-Key + XAUTH, Pre-Shared-Key
Supported IKE DH-Groups: dh1 dh2 dh5
Supported Hash Algo (IKE/IPSEC): md5 sha1
Supported Encryptions (IKE/IPSEC): (null) (1des) 3des aes128 aes192 aes256
Perfect Forward Secrecy: nopfs dh1 dh2 dh5

vpnc 0.5.1 では RTX1500 に接続できず。

vpnc は Cisco へのリモートアクセスにほぼ特化して実装されている。
(NetScreen 用のパッチもあたってはいるが、Cisco がメイン)

プロポーザルなどの処理は「よきに計らってくれている」ので、
設定ファイルのレベルで調整できることは、あまり無い。

よって、深追いせず。

ipsec-tools (racoon) 0.7.1

[PROJECT ABANDONED] IPsec-Tools

mode-cfg を利用しなければ、接続可能。

mode-cfg を利用すると Unexpected SET attribute INTERNAL_IP4_* となる。

2008-10-26 12:58:27: DEBUG: Configuration exchange type mode config SET
2008-10-26 12:58:27: DEBUG: Attribute INTERNAL_IP4_ADDRESS
2008-10-26 12:58:27: DEBUG: Unexpected SET attribute INTERNAL_IP4_ADDRESS
2008-10-26 12:58:27: DEBUG: Attribute INTERNAL_IP4_NETMASK
2008-10-26 12:58:27: DEBUG: Unexpected SET attribute INTERNAL_IP4_NETMASK
2008-10-26 12:58:27: DEBUG: Sending MODE_CFG ACK

racoon 0.7.1 は Set/Acknowledge での INTERNAL_IP4_* を未実装である。
(Requet/Reply のみ実装されている。)

src/racoon/isakmp_cfg.c: isakmp_cfg_set()

                    /*
                     * We should send ack for the attributes we accepted
                     */
                    while (tlen > 0) {
                            reply_attr = NULL;
                            type = ntohs(attr->type);

                            plog(LLV_DEBUG, LOCATION, NULL,
                                 "Attribute %s\n",
                                 s_isakmp_cfg_type(type & ~ISAKMP_GEN_MASK));

                            switch (type & ~ISAKMP_GEN_MASK) {
                            case XAUTH_STATUS:
                                    reply_attr = isakmp_xauth_set(iph1, attr);
                                    break;
                            default:
                                    plog(LLV_DEBUG, LOCATION, NULL,
                                         "Unexpected SET attribute %s\n",
                                         s_isakmp_cfg_type(type & ~ISAKMP_GEN_MASK));
                                    break;
                            }
                    }

一方で、RTX1500 では Set/Acknowledge のみ実装されている。
IPsec XAUTH 認証機能

ISAKMP Configuration Method(mode-cfg)について
* draft-dukes-ike-mode-cfg-02.txt に定義されている attribute について、
o Request/Reply 型の通知方法は使用しません。attribute を通知する場合は、必ず ISAKMP-CFG-SET メッセージに格納し、Set/Acknowledge 型の通知方法を用いて通知します。

よって、racoon で mode-cfg を利用するには、Set/Acknowledge のパッチが必要。
つまり、標準では接続できない。

racoon + iptunnel

mode-cfg 無しの構成では接続可能。
iptunnel で内部 IP を設定する。

iptunnelの設定

iptunnel add ipsec0 mode ipip remote 1.1.1.1
ifconfig ipsec0 192.168.100.30/32
route add -net 10.1.1.0/24 dev ipsec0

/etc/racoon/racoon.conf

#
# NOTE: This file will not be used if you use racoon-tool(8) to manage your
# IPsec connections. racoon-tool will process racoon-tool.conf(5) and
# generate a configuration (/var/lib/racoon/racoon.conf) and use it, instead
# of this file.
#
# Simple racoon.conf
#
#
# Please look in /usr/share/doc/racoon/examples for
# examples that come with the source.
#
# Please read racoon.conf(5) for details, and alsoread setkey(8).
#
#
# Also read the Linux IPSEC Howto up at
# http://www.ipsec-howto.org/t1.html
#
path pre_shared_key "/etc/racoon/psk.txt";
#path certificate "/etc/racoon/certs";
#path certificate "/etc/ssl/certs";
remote anonymous {
exchange_mode aggressive;
lifetime time 14400 second;
xauth_login "user1";
my_identifier fqdn "myid";
peers_identifier address "172.16.0.254";
#mode_cfg on;
#script "/etc/racoon/phase1-up.sh" phase1_up;
#script "/etc/racoon/phase1-down.sh" phase1_down;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method xauth_psk_client;
#authentication_method pre_shared_key;
dh_group modp1024;
}
#generate_policy off;
}
#
sainfo anonymous {
pfs_group modp1024;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}

/etc/racoon/psk.txt

172.16.0.254 PSKEY1
user1 password

/etc/ipsec-tools.conf

#!/usr/sbin/setkey -f
# NOTE: Do not use this file if you use racoon with racoon-tool
# utility. racoon-tool will setup SAs and SPDs automatically using
# /etc/racoon/racoon-tool.conf configuration.
#
## Flush the SAD and SPD
#
flush;
spdflush;
## Some sample SPDs for use racoon
#
spdadd 192.168.100.30 10.1.1.0/24 any -P out ipsec
esp/tunnel/192.168.1.132-172.16.0.254/require;
#
spdadd 10.1.1.0/24 192.168.100.30 any -P in ipsec
esp/tunnel/172.16.0.254-192.168.1.132/require;
#

OpenSWAN 2.6.16

Openswan website

XAUTH, mode-cfg 無しでは接続できた。
しかしユーザ認証は行いたいので、具体的設定例はここでは例示しない。

調べた限り、OpenSWAN と YAMAHA とは Aggressive Mode の最後のパケットなど、仕様の解釈が違うようだ。

openswan-2.6.16/programs/pluto/ikev1_aggr.c : aggr_inR1_outI2_tail()

    /* RFC2408 says we must encrypt at this point */

上記コメントは RFC 2408 4.7 の、この記述を指していると思われる。

In the third (3) message, the initiator transmits the results of the
agreed upon authentication function. This information is transmitted
under the protection of the common shared secret.

もう少し広く引用。

RFC2408 4.7 Aggressive Exchange

RFC2408

4.7 Aggressive Exchange
The Aggressive Exchange is designed to allow the Security
Association, Key Exchange and Authentication related payloads to be
transmitted together. Combining the Security Association, Key
Exchange, and Authentication-related information into one message
reduces the number of round-trips at the expense of not providing
identity protection. Identity protection is not provided because
identities are exchanged before a common shared secret has been
established and, therefore, encryption of the identities is not
possible. Additionally, the Aggressive Exchange is attempting to
establish all security relevant information in a single exchange.
The following diagram shows the messages with possible payloads sent
in each message and notes for an example of the Aggressive Exchange.

Maughan, et. al. Standards Track [Page 55]

RFC 2408 ISAKMP November 1998

AGGRESSIVE EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange
(2) <= HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
In the first message (1), the initiator generates a proposal it
considers adequate to protect traffic for the given situation. The
Security Association, Proposal, and Transform payloads are included
in the Security Association payload (for notation purposes). There
can be only one Proposal and one Transform offered (i.e. no choices)
in order for the aggressive exchange to work. Keying material used
to arrive at a common shared secret and random information which is
used to guarantee liveness and protect against replay attacks are
also transmitted. Random information provided by both parties SHOULD
be used by the authentication mechanism to provide shared proof of
participation in the exchange. Additionally, the initiator transmits
identification information.
In the second message (2), the responder indicates the protection
suite it has accepted with the Security Association, Proposal, and
Transform payloads. Keying material used to arrive at a common
shared secret and random information which is used to guarantee
liveness and protect against replay attacks is also transmitted.
Random information provided by both parties SHOULD be used by the
authentication mechanism to provide shared proof of participation in
the exchange. Additionally, the responder transmits identification
information. All of this information is transmitted under the
protection of the agreed upon authentication function. Local
security policy dictates the action of the responder if no proposed
protection suite is accepted. One possible action is the
transmission of a Notify payload as part of an Informational
Exchange.

Maughan, et. al. Standards Track [Page 56]

RFC 2408 ISAKMP November 1998

In the third (3) message, the initiator transmits the results of the
agreed upon authentication function. This information is transmitted
under the protection of the common shared secret. Local security
policy dictates the action if an error occurs during these messages.
One possible action is the transmission of a Notify payload as part
of an Informational Exchange.

一方で IKEv1 では、Aggressive Mode の最後のパケットの暗号化は任意となっている。

RFC 2409

RFC2409

The first two messages negotiate policy,
exchange Diffie-Hellman public values and ancillary data necessary
for the exchange, and identities. In addition the second message
authenticates the responder. The third message authenticates the
initiator and provides a proof of participation in the exchange. The
XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY
NOT be sent under protection of the ISAKMP SA allowing each party to

Harkins & Carrel Standards Track [Page 8]

RFC 2409 IKE November 1998

postpone exponentiation, if desired, until negotiation of this
exchange is complete. The graphic depictions of Aggressive Mode show
the final payload in the clear; it need not be.

5.4 ではパケットの暗号化については触れていない

5.4 Phase 1 Authenticated With a Pre-Shared Key
A key derived by some out-of-band mechanism may also be used to
authenticate the exchange. The actual establishment of this key is
out of the scope of this document.
When doing a pre-shared key authentication, Main Mode is defined as
follows:
Initiator Responder
---------- -----------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R
Aggressive mode with a pre-shared key is described as follows:
Initiator Responder
----------- -----------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
When using pre-shared key authentication with Main Mode the key can
only be identified by the IP address of the peers since HASH_I must
be computed before the initiator has processed IDir. Aggressive Mode
allows for a wider range of identifiers of the pre-shared secret to
be used. In addition, Aggressive Mode allows two parties to maintain
multiple, different pre-shared keys and identify the correct one for
a particular exchange.

パケットの観察による仮説

OpenSWAN 2.6.16
- ISAKMP の実装を引きずっており、Aggressive Mode の最後のメッセージを暗号化する
YAMAHA RTX1500
- IKEv1 の仕様に基づき、Aggressive Mode の最後のメッセージを暗号化していないことを期待している
  - 暗号化したパケットが届くと "payload malformed : no message" になり SA が確立しない

この第3パケットの問題は、ipsec ike payload type 3 でとりあえず回避できた。

しかし、XAUTH と mode-cfg を利用すると、続くパケットで結局 MALFORMED になる。

仕様の解釈の相違がまだあるようで、相互接続は難しそうである。

まとめ

YAMAHA RTX1500 に XAUTH と mode-cfg を組み合わせて接続するオープンソース実装として
vpnc, ipsec-tools, OpenSWAN を調査したが接続できなかった。

mode-cfg をあきらめれば、ipsec-tools (racoon) で接続可能。

RTX シリーズにリモートアクセス接続するには YMS-VPN1 を購入するのが無難なようだ。

http://netvolante.jp/products/option/yms-vpn1.html

ひょっとすると最新の RTX1200 では状況が違っているかも・・・
YAMAHA さんの中の人に期待 :-)