SSL VPN and IPsec VPN IP address assignments 7.0.1

When a user disconnects from a VPN tunnel, it is not always desirable for the released IP address to be used immediately.

• In SSL VPN, IP addresses can be assigned from the pool in a round robin fashion, instead of the default first-available address method.

• In IPsec VPN, IP addresses can held for the specified delay interval before being released back into the pool for assignment. The first-available address assignment method is still used.

Example topology

In these examples, two PCs connect to the VPN.

SSL VPN example

In this example, SSL VPN is configured to use round robin IP address assignment. Dual stack address assignment (both IPv4 and IPv6) is used.

After a tunnel is disconnected, freeing a low IP address, the next client that connects gets the next address in the round robin instead of the lowest address.

To configure SSL VPN with round robin and dual stack:

1. Create IPv4 and IPv6 address ranges:

   config firewall address
       edit "sslvpn_ipv4_pool"
           set type iprange
           set start-ip 173.10.1.1
           set end-ip 173.10.1.3
       next
   end

   config firewall address6
       edit "sslvpn_ipv6_pool"
           set type iprange
           set start-ip 2000::ad0a:101
           set end-ip 2000::ad0a:103
       next
   end

2. Set the address ranges as IP pools in the SSL VPN settings:

   config vpn ssl settings
       set tunnel-ip-pools "sslvpn_ipv4_pool"
       set tunnel-ipv6-pools "sslvpn_ipv6_pool"
   end

   When round-robin is used, any address pools defined in the web portal are ignored and the tunnel IPv4 and IPv6 pool addresses in the SSL VPN settings are used. Only one set of IP pool addresses can be applied.

3. Enable round-robin and dual stack in the SSL VPN settings:

   config vpn ssl settings
       set dual-stack-mode enable
       set tunnel-addr-assigned-method round-robin
   end

   By default, the IP pool assignment follows the first available rule.

4. Create two users and assign them to an SSL VPN policy:

   config user local
       edit "u1"
           set type password
           set passwd **********
       next
       edit "u2"
           set type password
           set passwd **********
       next
   end

   config firewall policy
       edit 1
           set name "sslvpnd"
           set srcintf "ssl.vdom1"
           set dstintf "link_11" "port1"
           set action accept
           set srcaddr "all"
           set dstaddr "all"
           set srcaddr6 "all"
           set dstaddr6 "all"
           set schedule "always"
           set service "ALL"
           set nat enable
           set users "u1" "u2"
       next
   end

To test the results:

1. Log in to the SSL VPN on PC1 using user u1 and then check its assigned IP address:

   # get vpn ssl monitor
   SSL-VPN Login Users:
    Index   User    Group   Auth Type      Timeout         Auth-Timeout    From     HTTP in/out    HTTPS in/out    Two-factor Auth
    0       u1             1(1)             N/A     10.1.100.145   0/0     0/0     0
   
   SSL-VPN sessions:
    Index   User    Group   Source IP      Duration        I/O Bytes       Tunnel/Dest IP
    0       u1             10.1.100.145     13      49935/35251    173.10.1.1,2000::ad0a:101

2. Log in to the SSL VPN on PC1 using user u2 and then check its assigned IP address:

   # get vpn ssl monitor
   SSL-VPN Login Users:
    Index   User    Group   Auth Type      Timeout         Auth-Timeout    From     HTTP in/out    HTTPS in/out    Two-factor Auth
    0       u1             1(1)             N/A     10.1.100.145   0/0     0/0     0
    1       u2             1(1)             N/A     10.1.100.254   0/0     0/0     0
   
   SSL-VPN sessions:
    Index   User    Group   Source IP      Duration        I/O Bytes       Tunnel/Dest IP
    0       u1             10.1.100.145     44      90126/70405    173.10.1.1,2000::ad0a:101
    1       u2             10.1.100.254     10      10563/8158     173.10.1.2,2000::ad0a:102

3. Log user u1 off of PC1, then log them back in and check that the assigned IP address is not the same as was previously assigned:

   # get vpn ssl monitor
   SSL-VPN Login Users:
    Index   User    Group   Auth Type      Timeout         Auth-Timeout    From     HTTP in/out    HTTPS in/out    Two-factor Auth
    0       u1             1(1)             N/A     10.1.100.145   0/0     0/0     0
    1       u2             1(1)             N/A     10.1.100.254   0/0     0/0     0
   
   SSL-VPN sessions:
    Index   User    Group   Source IP      Duration        I/O Bytes       Tunnel/Dest IP
    0       u1             10.1.100.145     10      50992/41159    173.10.1.3,2000::ad0a:103
    1       u2             10.1.100.254     43      30374/21860    173.10.1.2,2000::ad0a:102

IPsec VPN example

In this example, the IP address reuse delay interval is used to prevent a released address from being reused for at least four minutes. After the interval elapses, the IP address becomes available to clients again. Dual stack address assignment (both IPv4 and IPv6) is used.

To configure IPsec VPN with an IP address reuse delay interval:

1. Configure the IPsec phase1 interface, setting the IP address reuse delay interval to 240 seconds:

   config vpn ipsec phase1-interface
       edit "FCT"
           set type dynamic
           set interface "port27"
           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 wizard-type dialup-forticlient
           set xauthtype auto
           set authusrgrp "local-group"
           set ipv4-start-ip 10.20.1.1
           set ipv4-end-ip 10.20.1.100
           set dns-mode auto
           set ipv4-split-include "FCT_split"
           set ipv6-start-ip 2001::1
           set ipv6-end-ip 2001::2
           set ip-delay-interval 240
           set save-password enable
           set psksecret **********
       next
   end

2. Configure the IPsec phase2 interface:

   config vpn ipsec phase2-interface
       edit "FCT"
           set phase1name "FCT"
           set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
       next
       edit "FCT6"
           set phase1name "FCT"
           set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
           set src-addr-type subnet6
           set dst-addr-type subnet6
       next
   end

To test the results:

1. Connect to the VPN with FortiClient 1 on PC1 then check the assigned IP address:

   # diagnose vpn ike gateway list
   
   vd: root/0
   name: FCT_0
   version: 1
   interface: port27 17
   addr: 173.1.1.1:4500 -> 173.1.1.2:60417
   tun_id: 173.1.1.2
   remote_location: 0.0.0.0
   virtual-interface-addr: 169.254.1.1 -> 169.254.1.1
   created: 14s ago
   xauth-user: userc
   2FA: no
   FortiClient UID: 7C0897D80C8E4B6DAC775DD6B0F93BAA
   assigned IPv4 address: 10.20.1.1/255.255.255.255
   assigned IPv6 address: 2001::1/128
   nat: peer
   IKE SA: created 1/1  established 1/1  time 100/100/100 ms
   IPsec SA: created 2/2  established 2/2  time 0/5/10 ms
   
     id/spi: 2 66140ba3e38b9b07/b64668f110ca4a48
     direction: responder
     status: established 14-14s ago = 100ms
     proposal: aes256-sha256
     key: 356637ee6e9a9cb5-fade432c09efb8aa-54be307fc1eeeab5-6e4b9ef19f98d5fa
     lifetime/rekey: 86400/86115
     DPD sent/recv: 00000000/00000394

2. Disconnect FortiClient 1 and connect with FortiClient 2. The IP address assigned to FortiClient 1 is not released to the pool, and a different IP address is assigned to FortiClient 2:

   # diagnose vpn ike gateway list
   
   vd: root/0
   name: FCT_0
   version: 1
   interface: port27 17
   addr: 173.1.1.1:4500 -> 173.1.1.2:64916
   tun_id: 173.1.1.2
   remote_location: 0.0.0.0
   virtual-interface-addr: 169.254.1.1 -> 169.254.1.1
   created: 6s ago
   xauth-user: usera
   2FA: no
   FortiClient UID: EAF90E297393456AB546A041066C0720
   assigned IPv4 address: 10.20.1.2/255.255.255.255
   assigned IPv6 address: 2001::2/128
   nat: peer
   IKE SA: created 1/1  established 1/1  time 110/110/110 ms
   IPsec SA: created 2/2  established 2/2  time 0/5/10 ms
   
     id/spi: 3 b25141d5a915e67e/b32decdb8cf98318
     direction: responder
     status: established 6-6s ago = 110ms
     proposal: aes256-sha256
     key: 374ab753f3207ea0-83496b5cb24b5a8d-c51da1fd505cf3a4-727884839897808a
     lifetime/rekey: 86400/86123
     DPD sent/recv: 00000000/00000453

3. Wait for 240 seconds, then disconnect and reconnect FortiClient 2. The IP address previously assigned to FortiClient 1 has been released back to the pool, and is assigned to FortiClient 2:

   # diagnose vpn ike gateway list
   
   vd: root/0
   name: FCT_0
   version: 1
   interface: port27 17
   addr: 173.1.1.1:4500 -> 173.1.1.2:64916
   tun_id: 173.1.1.2
   remote_location: 0.0.0.0
   virtual-interface-addr: 169.254.1.1 -> 169.254.1.1
   created: 20s ago
   xauth-user: usera
   2FA: no
   FortiClient UID: EAF90E297393456AB546A041066C0720
   assigned IPv4 address: 10.20.1.1/255.255.255.255
   assigned IPv6 address: 2001::1/128
   nat: peer
   IKE SA: created 1/1  established 1/1  time 100/100/100 ms
   IPsec SA: created 2/2  established 2/2  time 0/0/0 ms
   
     id/spi: 4 fb1fbad0c12f5476/aa06a2de76964f63
     direction: responder
     status: established 20-20s ago = 100ms
     proposal: aes256-sha256
     key: af43f1bb876dc79c-16448592fe608dc3-f251746d71b2c35d-c848e8c03bf738e9
     lifetime/rekey: 86400/86109
     DPD sent/recv: 00000000/000000a9

   Instead of waiting for 240 seconds, you can instead use the diagnose vpn ike gateway flush command to release the previously used IP addresses back into the pool.