Azure VPN Gateway と SRX で VPN がつながらない場合のトラブルシューティング方法

先日の Fortigate 編 に続いて、今度は @kazubu 先生にご提供いただいた SRX で VPN のトラシューのメモを。
JUNOS はまだ全く慣れてないので、だいぶ雑ですがご容赦を…。

各種ドキュメント

構成手順

ほぼ日本語 PDF の手順通りでつながったので割愛。(一か所 typo があった気がするけど忘れた。)
Azure 側の手順は旧ポータルでの記載になってるので、仔細は MS のドキュメント参照。

VPN トンネルをクリア

//peer-address を未指定にするとすべての SA がクリアされる (他拠点との接続も切れる) ので注意
clear security ipsec security-associations aa.aa.aa.aa
clear security ike security-associations aa.aa.aa.aa

パケット採取

後で確認。

VPN トンネルを確認

SA が確立されていることを確認します

> show security ipsec statistics
ESP Statistics: //接続済みであればパケットがカウントされています
  Encrypted bytes:             1976
  Decrypted bytes:          1924704
  Encrypted packets:             13
  Decrypted packets:          60147
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
5870219 UP a2a4867ce688050e 162df6175e622dbc IKEv2 aa.aa.aa.aa

> show security ike security-associations detail
IKE peer aa.aa.aa.aa, Index 5870219, Gateway Name: azure-gw
  Role: Responder, State: UP
  Initiator cookie: a2a4867ce688050e, Responder cookie: 162df6175e622dbc
  Exchange type: IKEv2, Authentication method: Pre-shared-keys
  Local: jj.jj.jj.jj:500, Remote: aa.aa.aa.aa:500
  Lifetime: Expires in 8440 seconds
  Peer ike-id: aa.aa.aa.aa
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :               771724
   Output bytes  :               771612
   Input  packets:                10141
   Output packets:                10141
  IPSec security associations: 14 created, 7 deleted
  Phase 2 negotiations in progress: 1

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: jj.jj.jj.jj:500, Remote: aa.aa.aa.aa:500
    Local identity: jj.jj.jj.jj
    Remote identity: aa.aa.aa.aa
    Flags: IKE SA is created

> show security ipsec security-associations
 Total active tunnels: 1
 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
 <131073 ESP:aes-cbc-256/sha1 88bad682 3186/ unlim - root 500 aa.aa.aa.aa
 >131073 ESP:aes-cbc-256/sha1 eaaf6166 3186/ unlim - root 500 aa.aa.aa.aa

> show security ipsec security-associations detail

ID: 131073 Virtual-system: root, VPN Name: azure-vpn
  Local Gateway: jj.jj.jj.jj, Remote Gateway: aa.aa.aa.aa
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv2
  DF-bit: clear, Bind-interface: st0.0
  Port: 500, Nego#: 415, Fail#: 0, Def-Del#: 0 Flag: 0x600a29
  Tunnel events:
    Fri Jan 19 2018 07:50:57: IPSec SA rekey successfully completed (25 times)
    Fri Jan 19 2018 02:21:10: IKE SA rekey successfully completed (2 times)
    Thu Jan 18 2018 11:09:06: IPSec SA negotiation successfully completed (1 times)
    Thu Jan 18 2018 11:09:06: IKE SA negotiation successfully completed (1 times)
    Thu Jan 18 2018 11:08:37: IPSec SAs cleared as corresponding IKE SA deleted (1 times)
    Thu Jan 18 2018 10:27:52: IPSec SA rekey successfully completed (31 times)
    Thu Jan 18 2018 07:36:23: IKE SA rekey successfully completed (3 times)
    Wed Jan 17 2018 08:48:20: IPSec SA negotiation successfully completed (1 times)
    Wed Jan 17 2018 08:48:20: IKE SA negotiation successfully completed (1 times)
    Wed Jan 17 2018 08:48:17: IPSec SA delete payload received from peer, corresponding IPSec SAs cleared (1 times)
    Wed Jan 17 2018 08:15:29: IPSec SA rekey successfully completed (72 times)
    Wed Jan 17 2018 01:53:22: IKE SA rekey successfully completed (7 times)
    Sun Jan 14 2018 20:41:14: IPSec SA negotiation successfully completed (1 times)
    Sun Jan 14 2018 20:41:14: IKE SA negotiation successfully completed (1 times)
    Sun Jan 14 2018 19:10:02: IKE SA rekey successfully completed (2 times)
    Sun Jan 14 2018 03:58:00: IKE SA negotiation successfully completed (1 times)
  Direction: inbound, SPI: 72332189, AUX-SPI: 0
    Hard lifetime: Expires in 2815 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2204 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64
  Direction: outbound, SPI: e7bae17a, AUX-SPI: 0
    Hard lifetime: Expires in 2815 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2204 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

デバッグログの有効化

monitor start kmd
monitor stop kmd
show log kmd //ログの実体は /var/log/kmd に出力される模様

PSK の不一致

[Jan 19 09:11:49]---------> Received from aa.aa.aa.aa:500 to jj.jj.jj.jj:0, VR 0, length 380 on IF
[Jan 19 09:11:49]ikev2_decode_packet: [101cc00/1094c00] Received packet: HDR, IDi, AUTH, SA, TSi, TSr
[Jan 19 09:11:49]ikev2_state_dispatch: [101cc00/1094c00] Responder side IKE_AUTH
[Jan 19 09:11:49]ikev2_reply_cb_shared_key_auth_verify: [101cc00/1094c00] Error: Auth payload contents does not match
[Jan 19 09:11:49]ikev2_state_error: [101cc00/1094c00] Negotiation failed because of error Authentication failed (24)
[Jan 19 09:11:49]IKE negotiation fail for local:jj.jj.jj.jj, remote:aa.aa.aa.aa IKEv2 with status: Authentication failed
[Jan 19 09:11:49]IPSec negotiation failed for SA-CFG azure-vpn for local:jj.jj.jj.jj, remote:aa.aa.aa.aa IKEv2. status: Authentication failed

正常時のログが以下。IKE_AUTH 付近にエラーがないから良いのかな…?

[Jan 20 04:03:02]---------> Received from aa.aa.aa.aa:500 to jj.jj.jj.jj:0, VR 0, length 380 on IF
[Jan 20 04:03:02]ikev2_decode_packet: [ffd000/1094c00] Received packet: HDR, IDi, AUTH, SA, TSi, TSr
[Jan 20 04:03:02]ikev2_state_dispatch: [ffd000/1094c00] Responder side IKE_AUTH
[Jan 20 04:03:02]ikev2_select_sa_reply: [1034400/1094c00] SA selected successfully

Proposal Mismatch

//Azure から応答を受信
[Jan 20 03:18:03]---------> Received from aa.aa.aa.aa:500 to jj.jj.jj.jj:0, VR 0, length 620 on IF
[Jan 20 03:18:03]ikev2_packet_st_input_get_or_create_sa: [fff400/0] No IKE SA for packet; requesting permission to create one.
[Jan 20 03:18:03]ikev2_decode_packet: [fff400/1094c00] Received packet: HDR, SA, KE, Nonce, N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP), Vid, Vid, Vid, Vid
[Jan 20 03:18:03]ikev2_state_dispatch: [fff400/1094c00] Responder side IKE_SA_INIT

//Azure 側から受け取った proposal
[Jan 20 03:18:03]Peer's proposed IKE SA payload is SA([0](id = 1) protocol = IKE (1), AES CBC key len = 256, HMAC-SHA1-96, HMAC-SHA1 PRF, 1024 bit MODP; [1](id = 2) protocol = IKE (1), AES CBC key len = 256, HMAC-SHA256-128, HMAC-SHA256 PRF

//SRX 側の proposal
[Jan 20 03:18:03]Configured proposal is SA([0](id = 1) protocol = IKE (1), 3DES, HMAC-MD5-96, 1024 bit MODP, HMAC-MD5 PRF; )

//No proposal chosen で SRX と Azure の proposal が一致しないためエラーになっている
[Jan 20 03:18:03]P1 SA payload match failed for sa-cfg azure-vpn. Aborting negotiation local:jj.jj.jj.jj remote:aa.aa.aa.aa IKEv2.
[Jan 20 03:18:03]iked_pm_ike_spd_select_ike_sa failed. rc 1, error_code: No proposal chosen
[Jan 20 03:18:03]ikev2_select_sa_reply: [fff400/1094c00] Error: SA select failed: 14
[Jan 20 03:18:03]ikev2_state_error: [fff400/1094c00] Negotiation failed because of error No proposal chosen (14)
[Jan 20 03:18:03]IKE negotiation fail for local:jj.jj.jj.jj, remote:aa.aa.aa.aa IKEv2 with status: No proposal chosen
[Jan 20 03:18:03]IKE SA delete called for p1 sa 5870294 (ref cnt 1) local:jj.jj.jj.jj, remote:aa.aa.aa.aa, IKEv2
[Jan 20 03:18:03]iked_pm_p1_sa_destroy: p1 sa 5870294 (ref cnt 0), waiting_for_del 0x0

正常時のログは以下のような感じでした。

//SRX から Azure へ接続要求 (SA_INIT) を送付
[Jan 20 04:02:37]ikev2_udp_send_packet: [1023400/1094c00] <-------- Sending packet - length = 76 VR id 0 [Jan 20 04:02:37]---------> Received from aa.aa.aa.aa:500 to jj.jj.jj.jj:0, VR 0, length 76 on IF
[Jan 20 04:02:37]ikev2_decode_packet: [1022c00/1094c00] Received packet: HDR
[Jan 20 04:02:37]ikev2_state_dispatch: [1022c00/1094c00] Initiator side INFORMATIONAL
[Jan 20 04:02:37]iked_pm_ike_sa_delete_notify_done_cb: For p1 sa index 5870425, ref cnt 2, status: Error ok
[Jan 20 04:02:37]iked_pm_p1_sa_destroy:  p1 sa 5870425 (ref cnt 0), waiting_for_del 0xd365a0
[Jan 20 04:02:37]iked_deferred_free_inactive_peer_entry: Free 1 peer_entry(s)
[Jan 20 04:03:02]---------> Received from aa.aa.aa.aa:500 to jj.jj.jj.jj:0, VR 0, length 620 on IF
[Jan 20 04:03:02]ikev2_packet_st_input_get_or_create_sa: [1029800/0] No IKE SA for packet; requesting permission to create one.
[Jan 20 04:03:02]ikev2_decode_packet: [1029800/1094c00] Received packet: HDR, SA, KE, Nonce, N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP), Vid, Vid, Vid, Vid
[Jan 20 04:03:02]ikev2_state_dispatch: [1029800/1094c00] Responder side IKE_SA_INIT

//Azure 側から受け取った proposal 
[Jan 20 04:03:02]Peer's proposed IKE SA payload is SA([0](id = 1) protocol = IKE (1), AES CBC key len = 256, HMAC-SHA1-96, HMAC-SHA1 PRF, 1024 bit MODP; [1](id = 2) protocol = IKE (1), AES CBC key len = 256, HMAC-SHA256-128, HMAC-SHA256 PRF

//SRX 側の proposal 
[Jan 20 04:03:02]Configured proposal is SA([0](id = 1) protocol = IKE (1), AES CBC key len = 256, HMAC-SHA1-96, 1024 bit MODP, HMAC-SHA1 PRF; )

//proposal が一致
[Jan 20 04:03:02]ikev2_select_sa_reply: [1029800/1094c00] SA selected successfully
[Jan 20 04:03:02]ikev2_state_init_responder_in_end: [1029800/0] Send reply IKE_SA_INIT packet
[Jan 20 04:03:02]ikev2_udp_send_packet: [1031800/0] <-------- Sending packet - length = 346 VR id 0 [Jan 20 04:03:02]---------> Received from aa.aa.aa.aa:500 to jj.jj.jj.jj:0, VR 0, length 380 on IF
[Jan 20 04:03:02]ikev2_decode_packet: [ffd000/1094c00] Received packet: HDR, IDi, AUTH, SA, TSi, TSr
[Jan 20 04:03:02]ikev2_state_dispatch: [ffd000/1094c00] Responder side IKE_AUTH
[Jan 20 04:03:02]ikev2_select_sa_reply: [1034400/1094c00] SA selected successfully
[Jan 20 04:03:02]Construction NHTB payload for  local:jj.jj.jj.jj, remote:aa.aa.aa.aa IKEv2 P1 SA index 5870426 sa-cfg azure-vpn
[Jan 20 04:03:02]Peer router vendor is not Juniper. Not sending NHTB payload for sa-cfg azure-vpn, p1_sa=5870426
[Jan 20 04:03:02]iked_pm_ipsec_sa_install: local:jj.jj.jj.jj, remote:aa.aa.aa.aa  IKEv2 for SA-CFG azure-vpn, rekey-ikev2:no
[Jan 20 04:03:02]iked_pm_ipsec_sa_create: encr key len 32, auth key len: 20, salt len: 0
[Jan 20 04:03:02]Added (spi=0xe913e01d, protocol=ESP dst=jj.jj.jj.jj) entry to the peer hash table
[Jan 20 04:03:02]Added (spi=0x9a0dbe24, protocol=ESP dst=aa.aa.aa.aa) entry to the peer hash table
[Jan 20 04:03:02]iked_pm_ipsec_sa_install: NHTB add passed for sa-cfg azure-vpn
[Jan 20 04:03:02]Hardlife timer started for inbound azure-vpn with 3600 seconds/0 kilobytes
[Jan 20 04:03:02]Softlife timer started for inbound azure-vpn with 3025 seconds/0 kilobytes
[Jan 20 04:03:02]In iked_ipsec_sa_pair_add Adding GENCFG msg with key; Tunnel = 131073;SPI-In = 0xe913e01d
[Jan 20 04:03:02]Added dependency on SA config blob with tunnelid = 131073
[Jan 20 04:03:02]Successfully added ipsec SA PAIR
[Jan 20 04:03:02]iked_pm_ike_sa_done: local:jj.jj.jj.jj, remote:aa.aa.aa.aa IKEv2
[Jan 20 04:03:02]IKE negotiation done for local:jj.jj.jj.jj, remote:aa.aa.aa.aa IKEv2 with status: Error ok
[Jan 20 04:03:02]IPSec  negotiation done successfully for SA-CFG azure-vpn for local:jj.jj.jj.jj, remote:aa.aa.aa.aa  IKEv2

例のごとく、各社のデバイスのコンフィグ、トラシュー方法については、各機器ベンダーまで確認しましょう。

気まぐれで追記します。

その他

Azure VPN Gateway 側でもログが取れるようになってたので、以下も併せてどうぞ。

Azure との VPN 接続がうまくいかない場合のデバッグ方法

あと、Jazug Night で登壇した際に更に詳しい話をしたので、以下のスライド P.64 – 73 や YouTube の録画 (1:03:36 – 1:18:50) もご確認ください。

Azure VPN Gateway と Fortigate で VPN がつながらない場合のトラブルシューティング方法

どこのご家庭にもある一般的な Fortigate 100E で Azure と VPN の接続検証をしてみたので、個人的なメモとして残しておきます。

各種ドキュメント

上記の公式ドキュメントにも記載がありますが、Azure 的には FortiOS 5.6 が最小要件となっています。
FortiOS 5.6 より古いファームウェアを使っている場合、VPN トンネルが張れているのにも関わらず通信が通らないなど
複数の既知の問題が確認されていますので、必ず FortiOS 5.6 以降のファームウェアに更新してから使いましょう。

また、Fortigate とは IKEv2 で接続するので、Azure 側はルートベースのゲートウェイを作りましょう。

構成手順

Cookbook の通りに設定すればつながったので省略。

VPN トンネルをクリア

diagnose vpn ike restart
diagnose vpn ike gateway clear

パケット採取

とりあえずパケット採取から。100E はストレージを積んでないので、CLI でキャプチャして、fgt2eth で pcap に変換すれば良さそう。

FG100E # diagnose sniffer packet any "" 6
fgt2eth.exe -in <上記でキャプチャしたテキスト ファイル> -out packet.pcap

VPN トンネルを確認

まず初めに、トンネルの一覧を取得して現状を確認。以下は接続できていない場合の例です。

FG100E # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=Azure ver=2 serial=1 ff.ff.ff.ff:0->aa.aa.aa.aa:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=9 ilast=0 olast=0 ad=/0 itn-status=a1
stat: rxp=0 txp=0 rxb=0 txb=0 //切断状態なので、TX/RX ともに 0 になっています
dpd: mode=on-idle on=0 idle=20000ms retry=3 count=0 seqno=129956
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=Azure proto=0 sa=0 ref=1 serial=1
 src: 0:0.0.0.0/0.0.0.0:0
 dst: 0:0.0.0.0/0.0.0.0:0

正常に接続出来ている状態だと、以下のような結果になるはず。

FG100E # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=Azure ver=2 serial=1 xx.xx.xx.xx:0->yy.yy.yy.yy:0
bound_if=7 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=12 ilast=6 olast=3 ad=/0 itn-status=a2
stat: rxp=3 txp=2 rxb=312 txb=168 //接続済みであればパケットがカウントされています
dpd: mode=on-idle on=1 idle=20000ms retry=3 count=0 seqno=129979
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=Azure proto=0 sa=1 ref=3 serial=1
 src: 0:0.0.0.0/0.0.0.0:0
 dst: 0:0.0.0.0/0.0.0.0:0

 //先ほどまで表示されていなかった SA の情報が追加で出ています
 SA: ref=6 options=10026 type=00 soft=0 mtu=1438 expire=26584/0B replaywin=1024
 seqno=3 esn=0 replaywin_lastseq=00000003 itn=0
 life: type=01 bytes=0/0 timeout=26731/27000
 dec: spi=101af04b esp=aes key=32 47f48f9be216cd73b0583d192569138e2a44480dfca10e7b41a833f2b565bb3c
 ah=sha1 key=20 8da6cf572039a77cc454e39d294d47842f4fa71c
 enc: spi=b9c6a7b0 esp=aes key=32 d8361980da39eab24e49527f2b1c08ac0583114d7b94228d98b465e1c3366dce
 ah=sha1 key=20 88442398c9fb9fff1d76f6d0fc029ccdf9b50763
 dec:pkts/bytes=3/96, enc:pkts/bytes=2/304
 npu_flag=03 npu_rgwy=aa.aa.aa.aa npu_lgwy=ff.ff.ff.ff npu_selid=0 dec_npuid=1 enc_npuid=1

デバッグログの有効化

トンネルが正しく張れていない場合などは、IKE のデバッグ ログを有効化してみましょう。

トラブルシューティング ガイドには 2 パターン書かれていますが、それぞれ何が違うんだろう・・・。(Phase 1, 2 ?)

diag vpn ike log 
diag debug app ike -1
diag debug enable

デバッグ ログを止める場合は以下のコマンドで。(以降の手順でも同様)

diagnose debug reset
diagnose debug disable

PSK の不一致

PSK が間違っている場合、以下のように明確に pre-shared key mismatch のログが出ます。

ike 0:Azure:230: PSK auth failed: probable pre-shared key mismatch
ike Negotiate SA Error: ike ike [6253]

Proposal Mismatch

SA の Proposal が一致しない (mismatch) 場合、以下のようなログが出ます。

//Fortigate から Azure へ接続要求 (SA_INIT) を送付
ike 0:Azure:781: sent IKE msg (SA_INIT): ff.ff.ff.ff:500->aa.aa.aa.aa:500, len=252, id=c9b9112fd4614416/0000000000000000
ike 0: comes aa.aa.aa.aa:500->ff.ff.ff.ff:500,ifindex=7....
ike 0: IKEv2 exchange=SA_INIT_RESPONSE id=c9b9112fd4614416/d00184a2a68d4b91 len=36
ike 0: in C9B9112FD4614416D00184A2A68D4B91292022200000000000000024000000080000000E

//Azure から応答を受信
ike 0:Azure:781: initiator received SA_INIT response
ike 0:Azure:781: processing notify type NO_PROPOSAL_CHOSEN
ike 0:Azure:781: malformed message
ike 0: comes aa.aa.aa.aa:500->ff.ff.ff.ff:500,ifindex=7....
ike 0: IKEv2 exchange=SA_INIT id=d4455f39cff0dd02/0000000000000000 len=620
ike 0: in D4455F39CFF0DD02000000000000000021202208000000000000026C220001040200002C010100040300000C0100000C800E01000300000803000002030000080200000200000008040000020200002C020100040300000C0100000C800E0100030000080300000C030000080200000500000008040000020200002C030100040300000C0100000C800E00800300000803000002030000080200000200000008040000020200002C040100040300000C0100000C800E0080030000080300000C030000080200000500000008040000020200002805010004030000080100000303000008030000020300000802000002000000080400000200000028060100040300000801000003030000080300000C0300000802000005000000080400000228000088000200004191FDF37EC6B68E1EFC9C40EDCE63919DE238DCD0A45B2B165EE30D6B0050953F4D4617E4449B4E96D455DEB34660FBA90308D82D11F29726B1BE27DB39DDC1605A2AC986F00D7F150649C954FA56ECC0183F1020FEFBCDA895F5A8EF33D959F0C1685C81AE533F1FE4904E2F8E9C4A300E8CD7795D1232910E68C852CAD9DE2900003499BE0BCCC36A0A9785CD1A2648ACB60B6E04D55DD3164797685AA6B06722E13D17CDACB1039FA8C7F01A697901B453442900001C000040048BF34E42B5DCB2F629EA1E8D91A7C71CB30388ED2B00001C00004005727E19E5CC569747EC22A6DD9CC63D94AA49EE642B0000181E2B516905991C7D7C96FCBFB587E461000000092B000014FB1DE3CDF341B7EA16B7E5BE0855F1202B00001426244D38EDDB61B3172A36E3D0CFB8190000001801528BBBC00696121849AB9A1C5B2A5100000002
ike 0:d4455f39cff0dd02/0000000000000000:782: responder received SA_INIT msg
ike 0:d4455f39cff0dd02/0000000000000000:782: received notify type NAT_DETECTION_SOURCE_IP
ike 0:d4455f39cff0dd02/0000000000000000:782: received notify type NAT_DETECTION_DESTINATION_IP

//Azure 側から受け取った proposal
ike 0:d4455f39cff0dd02/0000000000000000:782: incoming proposal:
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 1:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_SHA_96
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_SHA
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 2:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_SHA2_256
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 3:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=AES_CBC (key_len = 128)
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_SHA_96
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_SHA
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 4:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=AES_CBC (key_len = 128)
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_SHA2_256
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 5:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=3DES_CBC
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_SHA_96
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_SHA
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 6:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=3DES_CBC
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_SHA2_256
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.

//Fortigate 側の proposal
ike 0:d4455f39cff0dd02/0000000000000000:782: my proposal, gw Azure:
ike 0:d4455f39cff0dd02/0000000000000000:782: proposal id = 1:
ike 0:d4455f39cff0dd02/0000000000000000:782:   protocol = IKEv2:
ike 0:d4455f39cff0dd02/0000000000000000:782:      encapsulation = IKEv2/none
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=ENCR, val=DES_CBC
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=INTEGR, val=AUTH_HMAC_MD5_96
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=PRF, val=PRF_HMAC_MD5
ike 0:d4455f39cff0dd02/0000000000000000:782:         type=DH_GROUP, val=MODP1024.

//no proposal chosen で Fortigate と Azure の proposal が一致しないためエラーになっている
ike 0:d4455f39cff0dd02/0000000000000000:782: lifetime=28800
ike 0:d4455f39cff0dd02/0000000000000000:782: no proposal chosen
ike Negotiate SA Error: ike ike  [9697]

正常な場合のログは以下。

//Fortigate から Azure へ接続要求 (SA_INIT) を送付
ike 0:Azure:815: sent IKE msg (SA_INIT): ff.ff.ff.ff:500->aa.aa.aa.aa:500, len=340, id=a773817d787e06a4/0000000000                                                                                                                        000000
ike 0: comes aa.aa.aa.aa:500->ff.ff.ff.ff:500,ifindex=7....
ike 0: IKEv2 exchange=SA_INIT_RESPONSE id=a773817d787e06a4/5d4182e9c4e71157 len=364
ike 0: in A773817D787E06A45D4182E9C4E7115721202220000000000000016C220000300000002C010100040300000C0100000C800E0100030                                                                                                                        000080300000203000008020000020000000804000002280000880002000041168ABAA25B349FEF74B97112D464ACBDD24E9D415DB600ADA95C48                                                                                                                        F9FB09DD63388A7C14FDBF75EA926F25A97DFED9BDE66FD5E614A7B3FA0E6E72C4D25F018B709EFECFCDCADD3D3407B3821658A63EC9B9396EDCC                                                                                                                        AAFC79B68362928275364452E4513CD12AAD700846D45E52A8C91B3DF1168BE4A28BFCCCA1030949CAD29000034C2C8CB225C4F02C82BA41D222F                                                                                                                        C47318C9BB968E42109586814018DD44781D172DA7821374A5C71FF61120A6D5D8ADE92900001C0000400412B129D9A38E93680D50A89633A517B                                                                                                                        C0DF692582B00001C0000400572B08CE048FE1A5A0644D512093F674262CDEACE2B0000181E2B516905991C7D7C96FCBFB587E461000000090000                                                                                                                        0014FB1DE3CDF341B7EA16B7E5BE0855F120

//Azure から応答を受信
ike 0:Azure:815: initiator received SA_INIT response
ike 0:Azure:815: processing notify type NAT_DETECTION_SOURCE_IP
ike 0:Azure:815: ignoring unauthenticated notify payload (NAT_DETECTION_SOURCE_IP)
ike 0:Azure:815: processing notify type NAT_DETECTION_DESTINATION_IP
ike 0:Azure:815: ignoring unauthenticated notify payload (NAT_DETECTION_DESTINATION_IP)

//Azure 側から受け取った proposal
ike 0:Azure:815: incoming proposal:
ike 0:Azure:815: proposal id = 1:
ike 0:Azure:815:   protocol = IKEv2:
ike 0:Azure:815:      encapsulation = IKEv2/none
ike 0:Azure:815:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:Azure:815:         type=INTEGR, val=AUTH_HMAC_SHA_96
ike 0:Azure:815:         type=PRF, val=PRF_HMAC_SHA
ike 0:Azure:815:         type=DH_GROUP, val=MODP1024.

//Fortigate 側と一致した proposal
ike 0:Azure:815: matched proposal id 1
ike 0:Azure:815: proposal id = 1:
ike 0:Azure:815:   protocol = IKEv2:
ike 0:Azure:815:      encapsulation = IKEv2/none
ike 0:Azure:815:         type=ENCR, val=AES_CBC (key_len = 256)
ike 0:Azure:815:         type=INTEGR, val=AUTH_HMAC_SHA_96
ike 0:Azure:815:         type=PRF, val=PRF_HMAC_SHA
ike 0:Azure:815:         type=DH_GROUP, val=MODP1024.

//INITIAL-CONTACT を送付
ike 0:Azure:815: lifetime=28800
ike 0:Azure:815: IKE SA a773817d787e06a4/5d4182e9c4e71157 SK_ei 32:936D0D524FBD63007463875227CCF5EBF8E57329DEB3CAA91E                                                                                                                        3E2EB2E888CD10
ike 0:Azure:815: IKE SA a773817d787e06a4/5d4182e9c4e71157 SK_er 32:47962985DA68DEB918F4046430BE910B47081089B99EF38507                                                                                                                        1C0B517A3B0AAA
ike 0:Azure:815: IKE SA a773817d787e06a4/5d4182e9c4e71157 SK_ai 20:289FE8FA93A7F8428E837BFBAF9C0DEAB3315E65
ike 0:Azure:815: IKE SA a773817d787e06a4/5d4182e9c4e71157 SK_ar 20:CCA087CA7FFBC1F6F89A56A6EF762EEDA60EA9D4
ike 0:Azure:815: initiator preparing AUTH msg
ike 0:Azure:815: sending INITIAL-CONTACT

あ、当然ですが Fortigate のコンフィグとかトラブルシューティングは Fortinet 社に確認してくださいね。MS から各社の VPN デバイスについて正式な回答とかできるはずもないので、その辺は是非とも空気読んでくださいませ。

また気が向いたら追記します。

その他

Azure VPN Gateway 側でもログが取れるようになってたので、以下も併せてどうぞ。

Azure との VPN 接続がうまくいかない場合のデバッグ方法

あと、Jazug Night で登壇した際に更に詳しい話をしたので、以下のスライド P.64 – 73 や YouTube の録画 (1:03:36 – 1:18:50) もご確認ください。

Azure VPN Gateway の死活監視

VPN Gateway をどうしても死活監視したい場合は、ドキュメントの隅にこっそり書いてある healthprobe の URL を使いましょう。

https://<VPN GW の IP>:8081/healthprobe

 

手順 7.Azure ゲートウェイの正常性プローブを確認する
1. 正常性プローブに移動します。
2. 証明書の警告を無視して続行します。応答を受け取った場合、VPN ゲートウェイは正常であると考えられます。
3. 応答を受け取らない場合、ゲートウェイが正常な状態にないか、またはゲートウェイ サブネット上の NSG が問題の原因になっている可能性があります。応答のサンプル テキストを次に示します。
<?xml version="1.0"?> Primary Instance: GatewayTenantWorker_IN_1 GatewayTenantVersion: 14.7.24.6</string>

そもそも VPN Gateway は内部で二台構成になっていて、片系が死んでも他方に切り替わるので、監視する意味は殆どないですけどね。(PaaS のクラウド サービスになれた人だと、「GatewayTenantWorker_IN_1」というのでピンときますよね。)

二台とも死んだ場合でないと、こちらの URL を監視しても意味はないので、おとなしく VPN のトンネル (Main Mode SA, Quick Mode SA) が張れているかを確認したり、VPN 経由で疎通できるかという観点で監視をしましょう。

healthprobe はあくまでも VPN Gateway のインスタンスが生きているかの確認しかできないですし、Port が 8081 なことからもお察しのように、IKE (UDP/500) の通信自体をチェックできるわけではありません。SA の rekey に失敗した等で VPN が切れた際とかは当然検知できませんので、これはあくまでも VPN Gateway の Active なインスタンスが OS として正常かのチェック用途にどうぞ。

2 台とも死んでいて healthprobe に応答がないなんて事が万が一あった場合は、VPN Gateway のリセットを 2 回と、サイズ変更 (Basic -> Standard -> Basic 等) をして、復旧するか確認しましょう

  • VPN Gateway のリセット
    https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-resetgw-classic

 

Azure の仮想ネットワークが削除出来ない件

クラシック環境の仮想ネットワーク (VNET) が消せないというのを定期的に見かけるので、ありがちなパターンをまとめておきます。

  • この仮想ネットワークは使用中であるため、削除できません。リソースを最近削除した場合は、仮想ネットワークが更新されるまで時間がかかることがあります。
  • 操作 ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ が失敗しました: ”test’ の使用中に仮想ネットワークを削除または変更することはできません。’。
  • リソース グループ xxxxx を削除できませんでした: 識別子 ‘Microsoft.ClassicNetwork/virtualNetworks/xxxx’ のリソースを削除できなかったため、リソース グループ ‘xxxxx’ の削除に失敗しました。このリソース グループのプロビジョニング状態はロールバックされます。追跡 ID は ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ です。詳細については、監査ログを参照してください。 (コード: ResourceGroupDeletionBlocked) 操作 ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ が失敗しました: ”test’ の使用中に仮想ネットワークを削除または変更することはできません。’。 (コード: OperationFailed)
  • リソース グループ xxxxx を削除できませんでした: 識別子 ‘Microsoft.ClassicNetwork/virtualNetworks/xxx’ のリソースを削除できなかったため、リソース グループ ‘xxxxx’ の削除が許容時間内に完了しませんでした。このリソース グループのプロビジョニング状態はロールバックされます。追跡 ID は ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’ です。詳細については、監査ログを参照してください。 (コード: ResourceGroupDeletionTimeout) 操作 ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ が失敗しました: ”test’ の使用中に仮想ネットワークを削除または変更することはできません。’。 (コード: OperationFailed)

基本的には、ポータルから見えない何らかのリソースのゴミが残っているパターンが殆どなので消しましょう。

  • VM / Cloud Service のインスタンスが残存 (さすがにこれは気づくはず…)
  • VPN 用の仮想ネットワーク ゲートウェイが残存
  • ExpressRoute 用の仮想ネットワーク ゲートウェイが残存
  • Application Gateway が残存
  • Azure RemoteApp が残存
  • AppService Environment が残存

Azure PowerShell で以下を実行して何が残っているのかを確認し、不要なリソースは削除しましょう。
あと、クラシックは依存関係が強いので、残存リソースの削除後は少し待ってから VNET を消すのをお勧めします。

# Azure PowerShell をインストールしていない場合は、最新版の msi を入れてください
# https://github.com/Azure/azure-powershell/releases?after=clu-2016012142

# ログイン
Add-AzureAccount

# サブスクリプション選択
# 参考: https://blogs.msdn.microsoft.com/dsazurejp/2013/12/06/id-id/
Select-AzureSubscription -SubscriptionId "サブスクリプション ID"

# 残存している VPN Gateway を確認
Get-AzureVirtualNetworkGateway

<#
GatewayId : d360f9a9-3c1a-454e-ae5f-d9e2677fb165 <== 削除時に指定する GatewayId
GatewayName : Default
LastEventData :
GatewayType : DynamicRouting
LastEventTimeStamp : 2018/01/15 23:44:42
LastEventMessage : Successfully configured the gateway.
LastEventID : 23005
State : Provisioned <== NotProvisioned は無視してよいので、Provisioned のものを探す
VIPAddress : 52.230.68.115
DefaultSite :
GatewaySKU : Standard
Location : Southeast Asia
VnetId : d360f9a9-3c1a-454e-ae5f-d9e2677fb165
SubnetId :
EnableBgp : False
Asn : 0
BgpPeeringAddress :
PeerWeight : 0
OperationDescription :
OperationId :
OperationStatus :
#>

# VPN Gateway が残存している場合は削除
Remove-AzureVirtualNetworkGateway -GatewayId "上記で確認した GatewayId"

# ExpressRoute Gateway を確認
([xml](Get-AzureVNetConfig).XMLConfiguration).NetworkConfiguration.VirtualNetworkConfiguration.VirtualNetworkSites.VirtualNetworkSite.name | foreach{echo "VNetName: $_"; Get-AzureVNetGateway -VNetName $_}

<#
VNetName: test
LastEventData :
LastEventTimeStamp : 2018/01/16 10:12:26
LastEventMessage : Successfully created a gateway for the following virtual network: test
LastEventID : 23002 State : Provisioned
VIPAddress : 13.73.17.147
DefaultSite : 
GatewaySKU : Default
OperationDescription : Get-AzureVNetGateway
OperationId : ab493757-5fa3-3a92-a173-50b82e73279a
OperationStatus : Succeeded
#>
# ExpressRoute Gateway が残存している場合は削除
Remove-AzureVNetGateway -VNetName "上記で確認した VNET 名"

# Application Gateway を確認
Get-AzureApplicationGateway

# Application Gateway が残存している場合は削除
Remove-AzureApplicationGateway -Name "上記で確認した AppGW 名"
# Azure RemoteApp のコレクションを確認
Get-AzureRemoteAppCollection | select Name

# Azure RemoteApp が残存している場合は削除
Remove-AzureRemoteAppCollection -CollectionName "コレクション名"

# ASE は詳しくないので割愛

それから、ARM への移行操作中もエラーになった気がします。Validate や Prepare したままのリソースは、Abort してから削除しましょう。

Move-AzureNetworkSecurityGroup -NetworkSecurityGroupName "NSG 名" -Abort
Move-AzureReservedIP -ReservedIPName "Reserved IP 名" -Abort
Move-AzureRouteTable -RouteTableName "UDR 名" -Abort
Move-AzureService -ServiceName "クラウド サービス名" -DeploymentName "VM 名" -Abort
Move-AzureStorageAccount -StorageAccountName "ストレージ アカウント名" -Abort
Move-AzureVirtualNetwork -VirtualNetworkName "VNET 名" -Abort

移行については以下も参照。

クラシック ポータルもリタイアしたことですし、これを機にクラシックの VM は全部 ARM に移して掃除しましょう。

そもそもクラシック環境は IaaS を前提に作られていないですし。(Azure は PaaS から始まっているのを知らない人も増えたんだろうなぁ…。)

vPro 対応の NUC7i5DNHE を買ってみた

どうも、NUC マニアです。久々にマシンが増えました。

Intel 先生が 2 世代に一度くらいのペースでしかリリースしてくれない貴重な vPro / AMT 対応 NUC です。型番は NUC7i5DNHE (NUC7i5DNKE もありますが、国内未発売っぽい) で、アキバの Ark さんのみ取り扱いを確認。

ちなみに、過去に vPro / AMT 対応だった DC53427HYE と NUC5i5MYHE も 4 台ずつ積みあがってます。

で、今回の構成はこちら。大体 1 セット 13 万くらい?

付属品はこんな感じ。

電源コードは相変わらず 3 pin のミッキーでした。
今回はケーブルもちゃんと同梱されているものの、ケーブル長が 50 cm しかないので短めです。

電源ボタンは上部から正面に移ったので、これからは NUC を大量に積み重ねても安心!

miniDP から HDMI x2 になったのも個人的にはうれしい限りです。
あと、lid 用のスロットも健在なので、拡張ボードもさせる模様。(この辺とか)

ちゃんとケンジントンロックもあります。

SATA と電源のケーブルが短いので、外さないと開腹ができない感じです。
今回から vPro NUC にも WiFi / BT が標準搭載されました。(個人的には不要なので安くしてほしい。)

メモリと SSD を搭載。

 

で、OS をインストールするわけなんですが、NVMe のおかげで 3 分で完了。
組み上げて OS を入れるまで 30 分かからないくらいで終わりました。

 

以下、雑なベンチ結果とか貼っておきます。

  • CINEBENCH
  • CrystalDiskMark 6.0.0
    (SSD 自体はもうちょっと性能出そうな気がする…)

    ———————————————————————–
    CrystalDiskMark 6.0.0 x64 (C) 2007-2017 hiyohiyo
    Crystal Dew World : https://crystalmark.info/
    ———————————————————————–
    * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
    * KB = 1000 bytes, KiB = 1024 bytesSequential Read (Q= 32,T= 1) : 1838.118 MB/s
    Sequential Write (Q= 32,T= 1) : 1617.923 MB/s
    Random Read 4KiB (Q= 8,T= 8) : 1025.103 MB/s [ 250269.3 IOPS]
    Random Write 4KiB (Q= 8,T= 8) : 1054.540 MB/s [ 257456.1 IOPS]
    Random Read 4KiB (Q= 32,T= 1) : 679.381 MB/s [ 165864.5 IOPS]
    Random Write 4KiB (Q= 32,T= 1) : 631.597 MB/s [ 154198.5 IOPS]
    Random Read 4KiB (Q= 1,T= 1) : 46.962 MB/s [ 11465.3 IOPS]
    Random Write 4KiB (Q= 1,T= 1) : 190.586 MB/s [ 46529.8 IOPS]Test : 1024 MiB [C: 4.5% (21.0/465.2 GiB)] (x5) [Interval=5 sec]
    Date : 2018/01/14 14:59:36
    OS : Windows Server 2016 Datacenter (Full installation) [10.0 Build 14393] (x64)
  • デバイス マネージャー
    Windows Server 2016 を入れた直後の状態がこちら。TPM 2.0 を積んでるので、BitLocker とかも安心。
    (ちなみに、メーカー的には Windows 10 系のみサポートらしいので要注意。)

    あと、有線 NIC は認識するものの、WiFi/BT は Windows Server は「ワイヤレス LAN サービス」の機能を有効化して、個別にドライバー入れないとダメでした。(一個だけ不明なデバイス扱いで残りましたが、MS_BTHPAN なので Bluetooth の PAN 関連と思われ、別に不要なので放置。未検証ですが、Windows 10 なら多分すんなり入るんじゃないかな。)
  • msinfo32

 

AMT もブート時に Ctrl + P でログインして IP とかを設定したら、無事につながりました。
これで VNC 経由でコンソールをとれるようになるので、リモート管理も楽チンですわ。

一か月くらい検証して、問題なければあと 3 台買い増す予定。

Azure の IP アドレスかを PowerShell でチェックする

Azure の IP アドレスに含まれるか (+ どこのリージョンか) を表示してくれるスクリプトです。
以前つくったあとブログを書いてなかった気がするので、だいぶ今更ですが。

Azure の Datacenter IP Ranges は以下で公開されていますが、Details 欄に記載の通り変更される事があるので、都度最新の xml を拾ってくる作りにしています。

PS> Check-AzureIpAddress.ps1 -IpAddress 13.78.0.1
13.78.0.1 is in Azure japaneast region.

PS> Check-AzureIpAddress.ps1 -IpAddress 203.0.113.1
203.0.113.1 is not in Azure.

2019/01/16: Azure の IP ではない場合は、dbip のリンクを開くようにしました