Fortigate と YAMAHA RTXのVPN IPsec 接続(インターネットNAT越し)

VPN IPsecFortigate,YAMAHA RTX

はじめに

前回、ローカル環境でFortigateとYAMAHA RTXのVPN接続のテストを行いました。今回は、インターネット経路の拠点間VPN接続です。
なお、前回はIKEv1で設定を行いましたが、今回はIKEv2で設定します。IKEv1で実施したところエラーを吐いたり動作が不安定だったためです。

構成と要件は下記のとおりです。

  • SiteAのFortigate 60Dは直接グローバルIPを持ち、a.example.comのFQDNを持つ。
  • SiteBのYAMAHA RTX810はグローバルIPは待たずNTTフレッツ光ONUがグローバルIPを持つ。FQDNはb.example.comとなる。
  • 両サイトのグローバルIPは動的でありドメインはダイナミックDNSでAレコードが登録されておりインターネット上から名前解決ができる状態である。
  • 両機器のVPN接続先はIPアドレス指定ではなくFQDNで指定する。
  • SiteBはONUでNATを行い、RTX810でVPN(IPsec)を終端する。
  • NTTフレッツ光ONUでは、LAN→インターネット通信時にWAN IFのグローバルIPにIPマスカレードする。また、インターネット→LAN方向で且つ宛先ポートがUDP500/UDP4500の場合、192.168.11.199(YAMAHA RTX810)に静的NAT転送する。

・VPNゲートウェイとなる機器のバージョンについて

機器OS Version
Fortigate 60Dv6.0.9
YAMAHA RTX810Rev.11.01.34

※注意
商用環境の場合は他メーカー同士のVPN接続はなるべく避け同一メーカーで組む方が賢明です。理由は、万が一VPN接続がうまく以下なった場合、他メーカー同士であるがゆえ、ベンダーもサポート出来なかったり、インターネット上にも他ーカー同士の構成での情報が少なく、想定以上の工数をかけてトライアンドエラーで対処することになりえます。どうしても他メーカー同士での接続が余儀なくされる場合は片方をCiscoにするなどナレッジが多いメーカーにすることをお勧めします。

設定内容

IPsec Proposal内容とパラメーター

IPsecを構成するパラメーターについて記載します。

・IKE SA(Phase1)パラメーター

種別内容
IKEバージョンIKEv2
暗号化アルゴリズム3DES
ハッシュアルゴリズムSHA1
Keyライフ27000秒
認証方式Pre-Shared Key
DHグループ2(MODP1024)
NATトラバーサル有効
IKEキープアライブDPD RFC4306

・CHILD SA(Phase2)パラメーター

種別内容
セキュリティプロトコルESP
暗号化アルゴリズム3DES
認証アルゴリズムSHA1
PFS有効
DHグループ2(MODP1024)
Keyライフ28800秒

NTTフレッツ光のONUがIPマスカレードをするため、ESPの転送処理に問題が生じます。そのため、経路上にNATする機器が存在する場合はNATトラバーサルを有効にします。
(ESPはTCP/UDPポート番号フィールドを暗号化しESPヘッダを付けてしまいます。そのため、ポート番号情報を必要とするNAT機器(IPマスカレード機器)を超えることができません。NATトラバーサルを有効にすることで新しくポート番号フィールドを付与しNAT機器(IPマスカレード機器)を超えられるようにします。)

また、当方の環境は両サイトともに動的グローバルIPアドレスです。グローバルIPアドレスが変化した場合、VPN装置が対向の装置を見失いVPNの接続に失敗してしまいます。
この問題を解消する為、グローバルIPアドレスが変化した場合でも、ダイナミックDNSでFQDNを追従させます。
当方のやり方は、お名前ドットコムでドメインを取得しているのですが、お名前ドットコムからダイナミックDNSでFQDNを追従させる専用ツールがあり(Windows上で動作する)常時動かしています。その為、FQDNは常に最新のグローバルIPアドレスで名前解決ができるようになっています。

Fortigate 60Dの設定

Fortigate 60Dの設定です。インタフェース等のベース部分は割愛しています。
[事前共有鍵のパスワード]の部分については任意の文字列を入力します。
「config vpn ipsec phase2-interface」にて「set src-name」と「set dst-name」をアドレスグループオブジェクトを指定していますが、このアドレスグループオブジェクト内で指定したIPアドレスのパケットがIPsecのトンネルを通る対象パケットとなります。今後、両サイト内で新しいセグメントを増やした時に簡単に追加できるようにしています。

config firewall address
    edit "ADDR_192.168.0.0/24"
        set uuid 8b733b0a-c48f-51e8-1bba-7ce099b96790
        set subnet 192.168.0.0 255.255.255.0
    next
    edit "ADDR_192.168.100.0/24"
        set uuid c3e7f5a6-9a9f-51ea-6ccc-e12643d0ba74
        set subnet 192.168.100.0 255.255.255.0
    next
end

config firewall addrgrp
    edit "ADGRP_a.example.com"
        set uuid ba6ce1a4-aca0-51ea-9030-f0d581737211
        set member "ADDR_192.168.0.0/24"
    next
    edit "ADGRP_b.example.com"
        set uuid acb1cbd2-ac6f-51ea-c3e0-7dc7f2f107c5
        set member "ADDR_192.168.100.0/24"
    next
end

config vpn ipsec phase1-interface
    edit "P1_IPSEC_RTX"
        set type ddns
        set interface "wan1"
        set ike-version 2
        set keylife 27000
        set peertype any
        set proposal 3des-sha1
        set localid "a.example.com"
        set localid-type fqdn
        set dhgrp 2
        set nattraversal forced
        set remotegw-ddns "b.example.com"
        set psksecret [事前共有鍵のパスワード]
        set dpd-retryinterval 10
    next
end

config vpn ipsec phase2-interface
    edit "P2_IPSEC_RTX"
        set phase1name "P1_IPSEC_RTX"
        set proposal 3des-sha1
        set dhgrp 2
        set src-addr-type name
        set dst-addr-type name
        set keylifeseconds 28800
        set src-name "ADGRP_a.example.com"
        set dst-name "ADGRP_b.example.com"
    next
end

config firewall policy
    edit 111
        set name "a.example.com-->b.example.com:IPsec"
        set uuid 6f1f51ba-ac6d-51ea-6131-20dd1a4e1cbc
         set srcintf "internal1"
        set dstintf "P1_IPSEC_RTX"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set fsso disable
    next
    edit 112
        set name "b.example.com-->a.example.com:IPsec"
        set uuid 6f729a5a-ac6d-51ea-51f9-331b36f82fc4
        set srcintf "P1_IPSEC_RTX"
        set dstintf "internal1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set fsso disable
    next
end

config router static
    edit 1
        set dst 192.168.100.0 255.255.255.0
        set device "P1_IPSEC_RTX"
    next
end

YAMAHA RTX810の設定

次にYAMAHA RTX810の設定です。
[事前共有鍵のパスワード]の部分については任意の文字列を入力します。

ip route default gateway 192.168.11.1
ip route 192.168.0.0/24 gateway tunnel 1
ip lan1/1 address 192.168.100.254/24
ip lan2 address 192.168.11.199/24
tunnel select 1
 ipsec tunnel 10
  ipsec sa policy 10 1 esp 3des-cbc sha-hmac
  ipsec ike version 1 2
  ipsec ike duration child-sa 1 27000
  ipsec ike duration ike-sa 1 28800
  ipsec ike encryption 1 3des-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike keepalive log 1 off
  ipsec ike keepalive use 1 on rfc4306 3 3
  ipsec ike local address 1 192.168.11.199
  ipsec ike local name 1 b.example.com fqdn
  ipsec ike nat-traversal 1 on
  ipsec ike negotiate-strictly 1 on
  ipsec ike pfs 1 on
  ipsec ike proposal-limitation 1 on
  ipsec ike message-id-control 1 on
  ipsec ike child-exchange type 1 2
  ipsec ike pre-shared-key 1 text [事前共有鍵のパスワード]
  ipsec ike remote address 1 a.example.com
  ipsec ike remote name 1 a.example.com fqdn
 ip tunnel mtu 1390
 ip tunnel tcp mss limit 1350
 tunnel enable 1
ipsec auto refresh on
ipsec ike retry 10 5
syslog debug on
dhcp service server
dns service recursive
dns server 192.168.11.1
httpd host any
sshd service on
sshd host key generate *

設定は以上です。

ステータス確認

Fortigate 60Dのステータス確認

「diagnose vpn ike gateway list」でIKEの状態を確認できます。IKEの接続が行われていないと表示されません。

FGT60D # diagnose vpn ike gateway list

vd: root/0
name: P1_IPSEC_RTX
version: 2
interface: wan1 5
addr: 61.26.68.197:4500 -> 125.30.91.195:4500
created: 239s ago
nat: peer
IKE SA: created 1/1  established 1/1  time 20/20/20 ms
IPsec SA: created 1/1  established 1/1  time 0/0/0 ms

  id/spi: 31 27b7216dc6a8853f/c19a14661ab4d170
  direction: responder
  status: established 239-239s ago = 20ms
  proposal: 3des-sha1
  child: no
  SK_ei: 1a85972b06df2f05-463b532a1b2f0d0b-9750ca520c1cfc0f
  SK_er: 39c278eeb14aa605-a7256e1cd803845b-abe4ca0c6fd65dbc
  SK_ai: e186efd0ce6a0fa9-f91455d20c38a4a3-4b2f609b
  SK_ar: 82053c9b79cfc7c3-de456b47c3c1fa7e-ee1326b1
  PPK: no
  message-id sent/recv: 0/82
  lifetime/rekey: 27000/26490
  DPD sent/recv: 00000000/00000000

FGT60D #

「diagnose vpn tunnel list」でSAの状態を確認します。前回と違い今回はNATトラバーサル構成のため、4行目にFromとToのIPアドレス:ポート番号の箇所がNATトラバーサル時に使用する4500番になっています。また、9行目が『natt: mode=silent』となっていることが確認できます。(非NAT環境では『natt: mode=none』)

FGT60D # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=P1_IPSEC_RTX ver=2 serial=3 61.26.68.197:4500->125.30.91.195:4500
bound_if=5 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=46 ilast=1 olast=1 ad=/0
stat: rxp=129 txp=257 rxb=136 txb=103
dpd: mode=on-demand on=1 idle=3000ms retry=3 count=0 seqno=5
natt: mode=silent draft=0 interval=10 remote_port=0
proxyid=P2_IPSEC_RTX proto=0 sa=1 ref=2 serial=1
  src: 0:192.168.0.0/255.255.255.0:0
  dst: 0:192.168.100.0/255.255.255.0:0
  SA:  ref=45 options=10226 type=00 soft=0 mtu=1438 expire=28282/0B replaywin=1024
       seqno=10a esn=0 replaywin_lastseq=00000080 itn=0
  life: type=01 bytes=0/0 timeout=28531/28800
  dec: spi=58c54de0 esp=3des key=24 33aa3162ae3700a033b8577cedb65e64ec4817ffe1799bea
       ah=sha1 key=20 8eed219f1632c4b42c85a930a12c5a79310507f1
  enc: spi=f1d3addb esp=3des key=24 1d1766192608d2973c6bc1e102fc7c98de1d0f359ef4277d
       ah=sha1 key=20 843546e60b36d18cc70af4c89ab2c272e706f31e
  dec:pkts/bytes=129/75, enc:pkts/bytes=362/24072
  npu_flag=03 npu_rgwy=125.30.91.195 npu_lgwy=61.26.68.197 npu_selid=0

FGT60D #

「get router info routing-table all」でルーティング設定を確認します。一番下の『S 192.168.100.0/24 [10/0] is directly connected, P1_IPSEC_RTX』がインストールされていることを確認します。

FGT60D # get router info routing-table all
<省略>
S*      0.0.0.0/0 [5/0] via 61.26.68.129, wan1
C       61.26.68.128/25 is directly connected, wan1
C       192.168.0.0/24 is directly connected, internal1
S       192.168.100.0/24 [10/0] is directly connected, P1_IPSEC_RTX

FGT60D #

念の為ですがデバッグログを確認し想定外のログが出力されていないかをチェックします。
以下は当方の環境で問題なくIPsecが張れいている状態のデバッグメッセージで、ログの内容はキープアライブ関連です。
もし両機器で問題がある場合、「negotiation failure」等のエラー分やミスマッチ情報が出力されます。デバッグは大量のメッセージが吐かれ読み解くだけで一苦労ですがIPsecが張れなかったり接続が不安定だった場合はデバッグで調査し原因を探ってみてください。
なお、張れない原因の多くが、プロポーザル(IPsecのパラメーターを提案しネゴシエーションすること)での間違いです。その場合デバッグの出力に対向のVPN装置(今回で言うとRTX810)のプロポーザル内容とFortigateのプロポーザル内容が表示されるのでパラメーターが一致していない箇所を見つけ、コンフィグを修正していく、という方法で解決していきます。

FGT60D # diagnose debug console timestamp enable
FGT60D # diagnose debug application ike -1
FGT60D # diagnose debug enable

FGT60D #
2020-06-12 21:58:48.582422 ike 0: comes 125.30.91.195:4500->61.26.68.197:4500,ifindex=5....
2020-06-12 21:58:48.582722 ike 0: IKEv2 exchange=INFORMATIONAL id=27b7216dc6a8853f/c19a14661ab4d170:0000005f len=180
2020-06-12 21:58:48.582794 ike 0: in 27B7216DC6A8853FC19A14661AB4D1702E2025080000005F000000B400000098266516EE576104C5F431FD3AC4CE5BDED8841843C7BF0A3720ABE4928EE318050371B72B400D51E61AC5A69DDB1D0511E367E2ABE31FEA0D5A7612E8170F64B881361CA5D8722B6D1F5E3900F1B84017E5BD0207FC4586DBFBF9492B7925FFFD9FD03676CBEF74C9665AE9942CB778106BC8E4EB5ECEC85B18263CC8C3FABECB07C74574AB03928E9FC6A7E506A5F82F320CFDB4
2020-06-12 21:58:48.583204 ike 0:P1_IPSEC_RTX:31: dec 27B7216DC6A8853FC19A14661AB4D1702E2025080000005F0000002000000004
2020-06-12 21:58:48.583282 ike 0:P1_IPSEC_RTX:31: received informational request
2020-06-12 21:58:48.583418 ike 0:P1_IPSEC_RTX:31: enc 0706050403020107
2020-06-12 21:58:48.583618 ike 0:P1_IPSEC_RTX:31: out 27B7216DC6A8853FC19A14661AB4D1702E2025200000005F0000003C00000020B43F1DB6DF9D942BE9E4F4A7188613CE4CECBDB4C68447E75B1205F4
2020-06-12 21:58:48.583890 ike 0:P1_IPSEC_RTX:31: sent IKE msg (INFORMATIONAL_RESPONSE): 61.26.68.197:4500->125.30.91.195:4500, len=60, id=27b7216dc6a8853f/c19a14661ab4d170:0000005f
2020-06-12 21:58:51.585063 ike 0: comes 125.30.91.195:4500->61.26.68.197:4500,ifindex=5....
2020-06-12 21:58:51.585290 ike 0: IKEv2 exchange=INFORMATIONAL id=27b7216dc6a8853f/c19a14661ab4d170:00000060 len=180
2020-06-12 21:58:51.585358 ike 0: in 27B7216DC6A8853FC19A14661AB4D1702E20250800000060000000B40000009828CB911E8321A60E02BC86E210CA46FD2B59C0A4CEF901DB9260E705631184CBEE3B0BE182AA8B03980877154963D0857AE2A45C72800F1DBC882BF63CEC47A66334D5C5F411513F3563CF6EDF15E4602F3BBB657D8D639118B98E796BB266DA7492269A20A6783963687EF48BA854B70842C91DBAC0E2E265C640C67300820E360C79FA21A3F97B49140579AF7C4F2B9C6A3E0B
2020-06-12 21:58:51.585763 ike 0:P1_IPSEC_RTX:31: dec 27B7216DC6A8853FC19A14661AB4D1702E202508000000600000002000000004
2020-06-12 21:58:51.585842 ike 0:P1_IPSEC_RTX:31: received informational request
2020-06-12 21:58:51.585979 ike 0:P1_IPSEC_RTX:31: enc 0706050403020107
2020-06-12 21:58:51.586180 ike 0:P1_IPSEC_RTX:31: out 27B7216DC6A8853FC19A14661AB4D1702E202520000000600000003C00000020E8DEF3B3B2018519428EF2F32FBA8DDA3E261F05017DD1F808549BC2
2020-06-12 21:58:51.586452 ike 0:P1_IPSEC_RTX:31: sent IKE msg (INFORMATIONAL_RESPONSE): 61.26.68.197:4500->125.30.91.195:4500, len=60, id=27b7216dc6a8853f/c19a14661ab4d170:00000060
2020-06-12 21:58:54.589066 ike 0: comes 125.30.91.195:4500->61.26.68.197:4500,ifindex=5....
2020-06-12 21:58:54.589299 ike 0: IKEv2 exchange=INFORMATIONAL id=27b7216dc6a8853f/c19a14661ab4d170:00000061 len=180
2020-06-12 21:58:54.589367 ike 0: in 27B7216DC6A8853FC19A14661AB4D1702E20250800000061000000B40000009870842A0F4B8916ABD5A09D8263B72DC2B1A988027EC34D92C4FA12A4BF419791DDD964BAEA722A052FDF3076BBE52AF66390789B0540C169920FDC22E934B14C389D2DA4891B43FF875C02FEA2430D58C106BBDDB2EEA975955C4CDF2CEFDA7B093FD6E04814E4EFE695DEB6C0FF2066C2D6B1ED51DAA26E28178AAE9D89BDED0B2E4DB749607998D11F9A266DFE7AB4415DA33E
2020-06-12 21:58:54.589775 ike 0:P1_IPSEC_RTX:31: dec 27B7216DC6A8853FC19A14661AB4D1702E202508000000610000002000000004
2020-06-12 21:58:54.589857 ike 0:P1_IPSEC_RTX:31: received informational request
2020-06-12 21:58:54.589988 ike 0:P1_IPSEC_RTX:31: enc 0706050403020107
2020-06-12 21:58:54.590187 ike 0:P1_IPSEC_RTX:31: out 27B7216DC6A8853FC19A14661AB4D1702E202520000000610000003C00000020CA06060DF902B48E341616A18023FBDD810F95BDDE60F1FA7EF9CE55
2020-06-12 21:58:54.590452 ike 0:P1_IPSEC_RTX:31: sent IKE msg (INFORMATIONAL_RESPONSE): 61.26.68.197:4500->125.30.91.195:4500, len=60, id=27b7216dc6a8853f/c19a14661ab4d170:00000061

YAMAHA RTX810のステータス確認

「show status tunnel [tunnel_num]」でトンネルインタフェースの状態を確認します。正常であれば『トンネルインタフェースは接続されています』と表示されます。

# show status tunnel 1
TUNNEL[1]:
説明:
  インタフェースの種類: IPsec
  トンネルインタフェースは接続されています
  開始: 2020/06/12 21:53:35
  通信時間: 3分25秒
  受信: (IPv4) 226 パケット [28696 オクテット]
        (IPv6) 0 パケット [0 オクテット]
  送信: (IPv4) 206 パケット [27978 オクテット]
        (IPv6) 0 パケット [0 オクテット]
  IKEキープアライブ:
           [タイプ]: rfc4306
             [状態]: OK
         [次の送信]: 2 秒後
#

「show ipsec sa」でSA状態を確認します。SAは『esp send』と『esp recv』の3種類が生成されます。

# show ipsec sa
Total: isakmp:1 send:1 recv:1

sa   sgw isakmp connection   dir  life[s] remote-id
-----------------------------------------------------------------------------
1     1    -    ike          -    28589   61.26.68.197
2     1    1    tun[001]esp  send 26789   61.26.68.197
3     1    1    tun[001]esp  recv 26789   61.26.68.197

#

「show ipsec sa gateway [gateway_id] detail」でSAの詳細を参照できます。

# show ipsec sa gateway 1 detail
SA[1] 状態: 確立済  寿命: 28583秒
プロトコル: IKEv2
ローカルホスト: 192.168.11.199:37905
リモートホスト: 61.26.68.197:37905
暗号アルゴリズム: 3DES               PRF       : HMAC_SHA1
認証アルゴリズム: HMAC_SHA1_96       DHグループ: MODP_1024
SPI: 27 b7 21 6d c6 a8 85 3f c1 9a 14 66 1a b4 d1 70
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[2] 状態: 確立済  寿命: 26783秒
送受信方向: 送信
プロトコル: ESP (モード: tunnel)
ローカルID: b.example.com (FQDN)
リモートID: a.example.com (FQDN)
暗号アルゴリズム: 3DES
認証アルゴリズム: HMAC_SHA1_96       ESN: DISABLE
始点トラフィック セレクタ (タイプ / プロトコル / ポート / アドレス)
 IPv4-range / any / 0-65535     / 192.168.100.0-192.168.100.255
終点トラフィック セレクタ (タイプ / プロトコル / ポート / アドレス)
 IPv4-range / any / 0-65535     / 192.168.0.0-192.168.0.255
SPI: 58 c5 4d e0
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[3] 状態: 確立済  寿命: 26783秒
送受信方向: 受信
プロトコル: ESP (モード: tunnel)
ローカルID: b.example.com (FQDN)
リモートID: a.example.com (FQDN)
暗号アルゴリズム: 3DES
認証アルゴリズム: HMAC_SHA1_96       ESN: DISABLE
SPI: f1 d3 ad db
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------

#

「show ip route」で4行目の『192.168.1.0/24 – TUNNEL[1] static』がインストールされていることを確認します。

# show ip route
宛先ネットワーク    ゲートウェイ     インタフェース  種別  付加情報
default             192.168.11.1           LAN2    static
192.168.0.0/24      -                 TUNNEL[1]    static
192.168.11.0/24     192.168.11.199         LAN2  implicit
192.168.100.0/24    192.168.100.254      LAN1/1  implicit
#

最後にRTX810でもログを確認しVPN関連で想定外のメッセージが出力されていないことを確認します。まず「syslog debug on」を設定しデバッグレベルのメッセージを出力するようにします。そのうえで『show log』を参照します。正常であればエラーを示すログは出力されていないはずです。
確認が終わったら「syslog debug off」に戻すことをお勧めします。(キープアライブのログでログバッファが埋まってしまうことを避けます。)

# syslog debug on
# show log

以上でステータス確認を終えます。

疎通テスト

ここでは簡易な疎通テストを実施します。(pingとtraceroute)

・SiteA(192.168.0.81)→SiteB(192.168.100.18)に対しての通信です。
pingの実行結果は問題ありません。tracerouteは2ホップ目が見えていませんがVPNトンネルを経由していると推測できます。
(pingの応答時間が数十ミリ秒と遅めですが確認したのがインターネットの混雑時間帯だからです。AM2時頃に実施すると10ミリ秒前後です。)

MBP13:~ root# ifconfig
<省略>
	inet 192.168.0.81 netmask 0xffffff00 broadcast 192.168.0.255
<省略>
MBP13:~ root# 
MBP13:~ root# 
MBP13:~ root# 
MBP13:~ root# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags        Netif Expire
default            192.168.0.254      UGSc           en0       
<省略>
MBP13:~ root# 
MBP13:~ root# 
MBP13:~ root# 
MBP13:~ root# ping 192.168.100.18 -c 4
PING 192.168.100.18 (192.168.100.18): 56 data bytes
64 bytes from 192.168.100.18: icmp_seq=0 ttl=62 time=32.613 ms
64 bytes from 192.168.100.18: icmp_seq=1 ttl=62 time=86.697 ms
64 bytes from 192.168.100.18: icmp_seq=2 ttl=62 time=48.055 ms
64 bytes from 192.168.100.18: icmp_seq=3 ttl=62 time=45.901 ms

--- 192.168.100.18 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.613/53.317/86.697/20.159 ms
MBP13:~ root# 
MBP13:~ root# 
MBP13:~ root# 
MBP13:~ root# traceroute 192.168.100.18   
traceroute to 192.168.100.18 (192.168.100.18), 64 hops max, 52 byte packets
 1  192.168.0.254 (192.168.0.254)  13.681 ms  4.801 ms  8.636 ms
 2  * * *
 3  192.168.100.18 (192.168.100.18)  33.640 ms  42.291 ms  36.229 ms
MBP13:~ root# 

・SiteB(192.168.100.18)→SiteA(192.168.0.81)に対しての通信です。こちらもpingの実行結果は問題ありません。tracerouteは2ホップ目にFortigate 60DのWAN側インタフェースのIPアドレスが確認できますが、結果からVPNトンネルを経由していることが分かります。

[root@centos7lb-01 ~]# ifconfig
ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.100.18  netmask 255.255.255.255  broadcast 192.168.100.18
<省略>

[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]# ip route
default via 192.168.100.254 dev ens192 proto static metric 100
192.168.100.18 dev ens192 proto kernel scope link src 192.168.100.18 metric 100
192.168.100.254 dev ens192 proto static scope link metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]# ping 192.168.0.81 -c 4
PING 192.168.0.81 (192.168.0.81) 56(84) bytes of data.
64 bytes from 192.168.0.81: icmp_seq=1 ttl=62 time=58.1 ms
64 bytes from 192.168.0.81: icmp_seq=2 ttl=62 time=74.6 ms
64 bytes from 192.168.0.81: icmp_seq=3 ttl=62 time=84.3 ms
64 bytes from 192.168.0.81: icmp_seq=4 ttl=62 time=61.6 ms

--- 192.168.0.81 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 58.130/69.705/84.380/10.468 ms
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]#
[root@centos7lb-01 ~]# traceroute 192.168.0.81 -n
traceroute to 192.168.0.81 (192.168.0.81), 30 hops max, 60 byte packets
 1  192.168.100.254  0.290 ms  0.401 ms  0.433 ms
 2  61.26.68.197  52.045 ms  52.023 ms  51.980 ms
 3  192.168.0.81  56.319 ms  56.312 ms  56.342 ms
[root@centos7lb-01 ~]#

まとめ

VPN IPsecの説明は以上です。今回対応したことをまとめます。

  • Fortigate 60DとYAMAHA RTX810によるインターネット越しでのVPN IPsec接続を行いました。
  • 動的IPアドレスのためダイナミックDNSを利用したドメイン指定によるIPsec接続をしました。(DNSのAレコード設定やダイナミックDNS自体の設定説明は割愛しました。)
  • SiteBにはIPマスカレードと静的NATを行うNTTフレッツ光のONUが存在するため、両機器をNATトラバーサルで動作させました。また、ステータス確認からNATトラバーサル特有のUDP4500が使用されていることを確認しました。(ONUのIPマスカレード設定やNAT設定は割愛しました。)
  • 各種ステータスの確認と最後に疎通確認を両サイトから行い問題なく通信ができることを確認しました。

構築時に参考にしたサイトやコマンドのまとめ

最後に、FortigateとRTXのIPsecを構築するにあたり参考にしたサイトとコマンドを残しときます。
参考サイトの2つ目の『IKEv2(YAMAHA)』はIKEv2を初めて理解するのに大変参考にさせていただきました。RTXでIKEv2を初めて実装する人にはおすすめです。

■参考サイト
・FortiGate to YAMAHA RTX1200 Configuration(Fortinet)
https://kb.fortinet.com/kb/documentLink.do?externalID=13885

・IKEv2(YAMAHA)
http://www.rtpro.yamaha.co.jp/RT/docs/ipsec/ike2.html

・Microsoft AzureとのIPsec接続(IKEv2) 設定例(YAMAHA)
http://www.rtpro.yamaha.co.jp/RT/docs/windows_azure/index_ikev2.html

・IPsec NATトラバーサル 外部仕様書(YAMAHA)
http://www.rtpro.yamaha.co.jp/RT/docs/ipsec/nat-traversal.html

・VPN(IPsec)接続ができない
https://network.yamaha.com/setting/router_firewall/ts_router/vpn_connect(YAMAHA)

■Fortigateのコマンド

<IPsec状態確認>
diagnose vpn ike gateway list
diagnose vpn tunnel list

<SA削除>
diagnose vpn ike restart
diagnose vpn ike gateway clear

<デバッグモード有効>
diagnose debug console timestamp enable
diagnose debug application ike -1
diagnose debug enable

■YAMAHA RTX810のコマンド

<IPsec状態確認>
show status tunnel [tunnel_num]
show ipsec sa
show ipsec sa gateway [gateway_id] detail

<NATテーブル確認>
show nat descriptor address

<SA削除>
ipsec sa delete all
ipsec refresh sa

<ログ確認>
syslog debug on ←こちらは設定です。onにした状態で下記のshow logで確認します。
show log