|
In the CLI, open the configuration for the client to the IPsec tunnel. Configure the following:
- Enable 'idle-timeout'.
- Specify the desired timeout duration, in minutes, with the 'idle-timeoutinterval' parameter.
For example:
FGT # config vpn ipsec phase1-interface
edit "fclinet"
set type dynamic
set interface "port5"
set mode aggressive
set peertype any
set net-device disable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set dpd disable
set comments "VPN: fclinet (Created by VPN wizard)"
set xauthtype auto
set authusrgrp "client"
set idle-timeout enable
set idle-timeoutinterval 20
set ipv4-start-ip 10.100.10.1
set ipv4-end-ip 10.100.10.5
set dns-mode auto
set save-password enable
set client-auto-negotiate enable
set client-keep-alive enable
set psksecret o0thdM783Nd fZA3cXGzHloa3qeRT2pXCjGc/Hocz4S2i9yS+G6wD5frvgievfa6l9gqFzA==
next
end
In this example, the VPN will automatically go down 20 minutes after the last connection is made.
Note:
The default value of 'idle-timeoutinterval' is 15 minutes. Values can range from 5 to 43200 minutes (30 days).
The following debug output from FortiGate shows details about the VPN after the VPN connection:
FGT # diagnose vpn ike routes list
vd: root/0
vrf: 0
dst: 10.100.10.1/255.255.255.255
next-hop: 10.136.3.113
interface: fclinet/31
distance: 15
priority: 0
overlap: use-new
virtual: false
ha-only: false
count: 1
After 20 minutes, the tunnel (phase1) goes down:
FGT # diagnose debug reset
FGT # diagnose debug console time enable
FGT # diagnose vpn ike log-filter name fclinet
FGT # diagnose vpn ike log-filter dst-addr4 10.136.3.113
FGT # diagnose debug enable
FGT # diagnose debug application ike -1
Note:
In v7.4.0, the 'diagnose vpn ike log-filter dst-addr4' command has been changed to 'diagnose vpn ike log-filter rem-addr4' and Starting from FortiOS 7.4.1, the 'diagnose vpn ike log-filter rem-addr4' command has been changed to 'diagnose vpn ike log filter rem-addr4'.
To stop the debug, run the following commands:
diagnose debug disable
diagnose debug reset
FGT # 2022-10-19 12:08:13.089412 ike 0: in 86D71F91A7693FD74D589BA9844E7CB708100501BE26CC090000006C1EF
3A2A2D3584E9719A6105E566029BAA0F23855
B15D07054CC07FBEF2A67F9A5F29C80EA59E2AB8EBA4DA1497554AACE3294724194F482DABD5A0DC7B69E83532931CF
58D7D55C47EB94B2F31AEA6E9
2022-10-19 12:08:15.510344 ike 0: comes 10.136.3.113:500->10.109.16.152:500,ifindex=9....
2022-10-19 12:08:15.510372 ike 0: IKEv1 exchange=Informational
id=86d71f91a7693fd7/4d589ba9844e7cb7:8246e566 len=92
2022-10-19 12:08:15.510400 ike 0: in 86D71F91A7693FD74D589BA9844E7CB7081005018246E
5660000005CB4086BDD93A6B5AE3135EBE6072710606E880B0E304C03DC32AD
2A1FAC128D05FE7FF5ECF1A3C97201D5EDAFB228211FEFE993154170142CD73E526C9C3EBBED
2022-10-19 12:08:15.510412 ike 0:
no established IKE SA for exchange-type Informational from
10.136.3.113:500->10.109.16.152 9 cookie 86d71f91a7693fd7/4d589ba9844e7cb7, drop <-----
2022-10-19 12:08:15.510746 ike 0: comes 10.136.3.113:500->10.109.16.152:500,ifindex=9....
2022-10-19 12:08:15.510759 ike 0: IKEv1 exchange=Informational
id=86d71f91a7693fd7/4d589ba9844e7cb7:d514f7c6 len=92
2022-10-19 12:08:15.510766 ike 0: in 86D71F91A7693FD74D589BA9844E7CB708100501D514F7C60000005CCAFD
387F06603E8C1F3ED5EC8D8DCE932E1CD988E06A129A59012A8D946D0FD1BF24E
8253DAF760E8B7A56FF8AB73B2195174C6BE65AC86FDEED6CE4B2D86AD8
2022-10-19 12:08:15.510776 ike 0: no established IKE SA for exchange-type Informational from 10.136.3.113:500->10.109.16.152 9 cookie 86d71f91a7693fd7/4d589ba9844e7cb7, drop <-----
2022-10-19 12:08:15.510944 ike 0: comes 10.136.3.113:500->10.109.16.152:500,ifindex=9....
Since the FortiGate is always acting as a responder in a C2S IPsec tunnel, the client can connect to the VPN again. The tunnel will be down until the client connects to the VPN again.
In case the timeout does not occur, run a sniffer to check what traffic is traversing the tunnel. The value of 'x.x.x.x' is the IP assigned to the remote device after connecting to the dial-up tunnel.
diagnose sniffer packet any 'host x.x.x.x' 4 0 l
To consider the tunnel as idle, the result of the sniffer above must be empty for the duration of the configured idle-timeoutinterval.
In the majority of instances, there are DNS queries that are traversing the tunnel, and this will reset the idle-timeout counter. Other messages from Windows service,s such as SSDP and mDNS/LLMNR, can send traffic over the active NIC. To disable, refer to this article. Technical Tip: SSL VPN Idle-timeout not working
Related documents:
Phase 1 configuration
IPsec VPN tunnels
|
