| Description | This article describes an issue where an IPsec tunnel will remain ‘up’ even when the binding interface is disabled. |
| Scope | FortiGate. |
| Solution |
In this example, both FortiGates reach the Internet through port 1. The IPsec tunnel is bound to port1.
If port1 is disabled on FGT-A in the tunnel remaining up while the tunnel goes down on FGT-B.
To check the status of an interface on the CLI:
FGT-A # diagnose hardware deviceinfo nic port1 | grep -i state State: down
To check the IPsec tunnel status in the GUI, view the IPsec monitor widget. By default, this can be found under Dashboard -> Network. Select the IPsec monitor widget to expand it.
To check the IPsec tunnel status, use the CLI command 'diag vpn tunnel list name <phase1 name>'.
FGT-A # diagnose vpn tunnel list name S2S-IPsec list ipsec tunnel by names in vd 0 ------------------------------------------------------ name=S2S-IPsec ver=1 serial=1 10.9.12.55:0->10.9.11.193:0 nexthop=0.0.0.0 tun_id=10.9.11.193 tun_id6=::10.9.11.193 status=up dst_mtu=65535 weight=1 bound_if=3 real_if=3 lgwy=static/1 tun=intf mode=auto/1 encap=none/552 options[0228]=npu frag-rfc run_state=0 role=primary accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=4 ilast=776 olast=776 ad=/0 stat: rxp=0 txp=0 rxb=0 txb=0 dpd: mode=off natt: mode=none draft=0 interval=0 remote_port=0 fec: egress=0 ingress=0 proxyid=S2S-IPsec proto=0 sa=1 ref=2 serial=1 src: 0:10.1.1.1-10.1.1.1:0 dst: 0:10.2.2.2-10.2.2.2:0 SA: ref=3 options=30202 type=00 soft=0 mtu=65470 expire=42652/0B replaywin=2048 seqno=1 esn=0 replaywin_lastseq=00000000 qat=0 rekey=0 hash_search_len=1 life: type=01 bytes=0/0 timeout=42929/43200 dec: spi=f5bcde31 esp=aes key=16 c453b3d23ebbe18270920676e6a367f3 ah=sha1 key=20 8a0cb4363c9c80835dcd9c2c6590da4b13217e76 enc: spi=ed6a5fef esp=aes key=16 1e7a6ac7ab59662d7b8c1b69d209080b ah=sha1 key=20 c01bb4ff857f67ca9be03c0283e0817d37950f6b dec:pkts/bytes=0/0, enc:pkts/bytes=0/0 npu_flag=00 npu_rgwy=10.9.11.193 npu_lgwy=10.9.12.55 npu_selid=0 dec_npuid=0 enc_npuid=0
In the output, SA=1 indicates that phase2 of the tunnel is still ‘up’ and the encryption keys of the SA are visible.
This problem occurs when DPD is disabled on the IPsec tunnel. To check this setting in the GUI, browse to VPN -> IPsec Tunnels, select the tunnel, and select the 'Edit' button, then in the Network settings, select the 'Edit' button.
To check the settings on the CLI:
config vpn ipsec phase1-interface edit "S2S-IPsec" set dpd disable next end
DPD is a mechanism used to detect when the remote peer of an IPsec tunnel is unreachable. Due to DPD being disabled, the tunnel interface is never able to detect that it should be down and remains up. The solution to this is to configure DPD as either 'on idle' or 'on demand'.
The configuration options on the CLI:
config vpn ipsec phase1-interface edit "S2S-IPsec" set dpd [disable | on-idle | on-demand] next end
For an explanation of the differences between 'on-idle' and 'on-demand', see: Technical Tip: Explanation of IPsec VPN DPD Options and On-Idle tunnel flushing process.
The DPD probes can be observed with the IKE debug:
diagnose debug application ike -1 diagnose debug console timestamp enable diagnose debug enable
To disable the debug:
diagnose debug disable diagnose debug reset
In the debug output, it can be observed that the remote gateway is unreachable, and the IPsec SA has been deleted:
ike V=root:0:S2S-IPsec: link is idle 3 10.9.12.55->10.9.11.193:0 dpd=2 seqno=2 rr=0 ike V=root:0:S2S-IPsec:695: send IKEv1 DPD probe, seqno 2 ike 0:S2S-IPsec:695: enc 321B8C49D9D00516C9FBB3D7061 C4184081005016F964FD9000000600B000024ED68663115FC0CD 0D2F6A0FFEE1CCBCD515A40777212C95C756FEFA2BA82C63B000 000200000000101108D28321B8C49D9D00516C9FBB3D7061C418 400000002 ike 0:S2S-IPsec:695: out 321B8C49D9D00516C9FBB3D7061 C4184081005016F964FD90000 006C7D9D728BCD79F32CF1F3FDB6C9CE23FE49E1B017B7D23BEF 31ED06602F47EDA95F092B20B4F4BE5BB6C76B41EB29B6035E12 CB38E63C4C75649E0BA2F58FE2833E278F50FA82EA55DBA78504 BADB5A2D ike V=root:0:S2S-IPsec:695: could not send IKE Packet(R-U-THERE):10.9.12.55:500->10.9.11.193:500, len=108 vrf=0: error 101:Network is unreachable ike V=root:0:S2S-IPsec: link is idle 3 10.9.12.55->10.9.11.193:0 dpd=2 seqno=2 rr=0 ike V=root:0:S2S-IPsec:695: send IKEv1 DPD probe, seqno 2 ike 0:S2S-IPsec:695: enc 321B8C49D9D00516C9FBB3D7061C 4184081005013B0285E400000 0600B0000247A676FD367DC45AD2271CF28677603FE7AA7AAB6866 FB77B4AC194C3D2799F01000000200000000101108D28321B8C49D 9D00516C9FBB3D7061C418400000002 ike 0:S2S-IPsec:695: out 321B8C49D9D00516C9FBB3D7061C41 84081005013B0285E40000006 C94AEAC6C26E61ED196893651CD6FEC04C2F03FDC6AC11FFE2F6798 5F43689E1B466C1615A498AA0269FBA65FE5A0D9056FDBBA4B6EB7B A751E95F53EE0834750E9B9B3B9902026E71337960E0F942A0E ike V=root:0:S2S-IPsec:695: could not send IKE Packet(R-U-THERE):10.9.12.55:500->10.9.11.193:500, len=108 vrf=0: error 101:Network is unreachable ike V=root:0:S2S-IPsec: link is idle 3 10.9.12.55->10.9.11.193:0 dpd=2 seqno=2 rr=0 ike V=root:0:S2S-IPsec:695: send IKEv1 DPD probe, seqno 2 ike 0:S2S-IPsec:695: enc 321B8C49D9D00516C9FBB3D7061C41 840810050134DED3FE0000006 00B00002401BE2148189788A59B5A636C6EF2934D347F2EF0192557 E25D21A3280FA31DDE000000200000000101108D28321B8C49D9D00 516C9FBB3D7061C418400000002 ike 0:S2S-IPsec:695: out 321B8C49D9D00516C9FBB3D7061C41 840810050134DED3FE0000006C 01B89581B13ACBFB6CF5B55FA4CA5BAF3EBF48B4E6795822AF4E05D 08F5D9126B6D3BC14CA6C9EB7DC0E4231F64596E4735C6AF52C6AD7 4D953F8836E86C2134C096D89BB9538732102010C351E660FF ike V=root:0:S2S-IPsec:695: could not send IKE Packet(R-U-THERE):10.9.12.55:500->10.9.11.193:500, len=108 vrf=0: error 101:Network is unreachable ike V=root:0:S2S-IPsec: link fail 3 10.9.12.55->10.9.11.193:0 dpd=2 ike V=root:0:S2S-IPsec: link down 3 10.9.12.55->10.9.11.193:500 ike V=root:0:S2S-IPsec: going to be deleted ike V=root:0:S2S-IPsec: flushing ike V=root:0:S2S-IPsec: deleting IPsec SA with SPI ed6a5ff1 ike V=root:0:S2S-IPsec:S2S-IPsec: deleted IPsec SA with SPI ed6a5ff1, SA count: 0 |
