Technical Tip: Allowing internal hosts to access remote VPN FortiClient users

FortiGate, FortiClient.

A VPN tunnel configured on a FortiGate unit for remote dial-in FortiClient users will typically involve a Phase1 configured in ‘Dialup User’ Aggressive mode, and a Phase 2 that all remote VPN users will share. Below is a sample configuration:

config vpn ipsec phase1
    edit "p1"

                 set interface wan
        set type dynamic
        set dpd on-demand
        set nattraversal enable
        set proposal des-md5
        set peertype dialup
        set mode aggressive
        set psksecret sIKyXbKOdEd2On0
        set usrgrp "fcgroup"   <----- This is the user group that is supposed to be authenticated against>.
    next
end

config vpn ipsec phase2
    edit "p2"
        set pfs enable
        Nset phase1name "p1"
        set proposal des-md5
        set replay enable
    next
end

config firewall address
    edit "int-net"
        set subnet 10.103.1.0 255.255.255.0
    next
    edit "rem-net"
        set subnet 10.10.20.0 255.255.255.0
    next
end

config firewall policy
    edit 1
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "int-net"
        set dstaddr "rem-net"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

The above configuration will work to access an internal resource if all traffic originates from the remote users. A problem may occur if internally generated traffic behind the FortiGate needs to access a remotely connected VPN user.

The FortiGate unit may not be able to properly route the traffic to that individual remote user, since by default it will not create host routes for the remote FortiClient VIP (Virtual IP) clients, and will use a network route instead. This can be confirmed with the diag vpn tunnel list CLI command:

diag vpn tun list
tunnel[4]:p2_7, gateway:172.31.226.33:500, hub=, option=6
   user:user1
   Internet browsing via if 8
   eroute[2]:{[10.103.1.*]}->{[10.10.20.*]}
   channel[2]:172.31.225.205,natt=0,state=2,keepalive=0,oif=3

     sa[4]:mtu=1434, cur_bytes=0, timeout=1794

     itdb[1]:mtu=1434, cur_bytes=0, cur_packets=0, spi=3aac868f, replay=64

          DES=f2ee4622f8b2ed87
          iv=0000000000000000
          MD5_HMAC=aea26950e7d0e3badf9dcd6e93e8aff2

     otdb[1]:mtu=1434, cur_bytes=0, cur_packets=0, spi=58fcea5d, replay=64

          DES=05b3e39a108531e6
          iv=dbbd0324038578f1
          MD5_HMAC=f04ffce4802f5a0ac8c83c20e9abc26c

The solution is configuring the Phase 2 'single-source' setting via the CLI. This will create host egress routes for the individual VPN client.

config vpn ipsec phase2
    edit "p2"
        set phase1name "p1"
        set proposal des-md5
        set replay enable
        set single-source enable
    next
end

diag vpn tun list
tunnel[4]:p2_8, gateway:172.31.226.33:500, hub=, option=6
   user:user1
   eroute[2]:{[10.103.1.*]}->{[10.10.20.1]}

   channel[2]:172.31.225.205,natt=0,state=2,keepalive=0,oif=3

sa[4]:mtu=1434, cur_bytes=0, timeout=1792

     itdb[1]:mtu=1434, cur_bytes=0, cur_packets=0, spi=3aac8690, replay=64

          DES=840b78f6de8d8754
          iv=0000000000000000
          MD5_HMAC=b2e844e7d27efcf21bc12854e97a1a76

          DES=e2fb1ae14ec3e7d1
          iv=3bf883f0277d5d99
          MD5_HMAC=2a32ae9399ac58d4179dcfba55c26510

Related article:
config vpn ipsec phase2-interface