FortiGate IPsec VPN for FortiClient
The easiest way to configure an IPsec VPN for FortiClient is by using the IPsec wizard available on the FortiGate GUI. The wizard applies the configuration for you based on the input provided. In this post, I will describe how to use the wizard to give the remote FortiClient user on the topology above, access to LAN and DMZ, through IPsec VPN.
The configuration will use IKEv1 as negotiation protocol. For IKEv2, see this post.
Firmware and Configuration Details
- FortiOS 6.2.3.
- FortiClient for Windows 6.2.x.
- VDOMs: disabled.
- Firewall address objects for LAN and DMZ have been pre-configured.
- VPN user bob belongs to VPN user group. Both objects have been pre-configured.
Using the IPsec Wizard
On the FortiGate GUI, we go to VPN > IPsec Wizard.
The wizard offers different IPsec VPN deployment options. The one we need is Remote Access. You also need to make sure Remote device type is set to Client-based and that FortiClient is selected. Also notice that the wizard changes the diagram located at the right side, to reflect the IPsec deployment type being configured. Next, enter the name of the IPsec VPN, which must not exceed 13 characters. This limit is due to the naming convention used by FortiGate for dialup clients. Let's set the name to FCT and move on to the next step.
Now, you need to select the Incoming Interface, which is the interface the tunnel terminates on. Per lab topology, it's port1. You also need to configure the authentication method. Two methods are available: Pre-shared Key and Signature. With Pre-shared Key, both dialup client and server must be configured with the same pre-shared key for phase 1 authentication to be successful. Signature is used when you want to use digital certificate signatures to authenticate the remote user. This time, I will select Pre-shared Key option. You must also select a user group for XAuth authentication. I already have a user group named VPN in the configuration. If you need to create a user group, you can create them through the wizard.
The next step is to select the policy and routing settings. The Local interface is the interface facing our local network, which per lab topology is port7. As Local Address, I select the firewall address object matching my local subnets. In my case, I had already configured LAN and DMZ firewall objects for 192.168.1.0/24 and 172.16.1.0/24 subnets, respectively. You also need to configure the Client Address Range, which defines the addresses that will be assigned to the remote users. I will use the 192.168.255.1- 192.168.255.31 range. You must also select the DNS Server configuration for the remote users. Selecting Use System DNS results in the remote users assigned with the same DNS servers used by FortiGate, while Specify allows you set separate DNS servers. The last two options, Enable IPv4 Split Tunnel and Allow Endpoint Registration, allow you to enable split tunneling and endpoint registration over IPsec VPN, respectively. When split tunneling is enabled, FortiClient installs routes on the local host for the remote subnets set as Local Address. This means that the remote user Internet traffic will continue to be routed directly through the local Internet connection. If you disable split tunneling, FortiClient installs a default route through the tunnel. As a result, all traffic, including Internet, is routed through the tunnel. Security wise, disabling split tunneling is a better option, as you force all traffic to pass through FortiGate. With split tunneling enabled, a compromised remote user could become a bridge between the Internet and your local network. For simplicity, I will keep split tunneling enabled. I will also keep enabled endpoint registration.
The last step is to configure Client Options for FortiClient. I will keep the default settings.
After clicking Create, the wizard displays a summary of the changes made to the configuration. From there, you can edit some of the objects configured by the wizard if needed.
Adjusting firewall policy configuration
The IPsec wizard configured a single incoming policy to allow VPN traffic to both LAN and DMZ subnets, and set port5 as the outgoing interface. This policy is correct for LAN, but not for DMZ which is behind port7. Therefore, I need to remove DMZ subnet from the policy created by the wizard and configure another policy for port7:
- On the GUI, browse to Policy & Objects > IPv4 Policy, and locate vpn_FCT_remote policy.
- Edit the policy and remove DMZ from Destination, and apply the changes.
- On Policy & Objects > IPv4 Policy, right-click on vpn_FCT_remote policy, and then click Copy.
- Right-click on the policy again, and now select Paste > Below. A cloned policy is created just below.
- Double-click on the new policy. Assign a Name to the policy, set DMZ as Destination, and then set port7 as Outgoing Interface.
- Scroll down and make sure to turn Enable this policy on to enable the policy (cloned policies are disabled by default).
I will use FortiClient 6.2 VPN version for Windows, which is available for free at www.forticlient.com.
- To configure a new VPN, right-click on the FortiClient system tray icon, and click Open FortiClient Console.
- When creating a new IPsec VPN, set the Remote Gateway to port1 address (10.1.1.10) and enter the same pre-shared key configured on FortiGate.
- Initiate the VPN connection on the remote user from FortiClient and use bob's credentials. The VPN is connected.
- When checking the routing table on the remote user, I see the two routes installed by FortiClient (split tunneling).
C:\Users\User>route print --- cut --- 172.16.1.0 255.255.255.0 192.168.255.2 192.168.255.1 1 192.168.1.0 255.255.255.0 192.168.255.2 192.168.255.1 1 --- cut ---
- I ping a host in LAN (192.168.1.10) and another in DMZ (126.96.36.199). Pings are successful.
C:\Users\User>ping 192.168.1.10 Pinging 192.168.1.10 with 32 bytes of data: Reply from 192.168.1.10: bytes=32 time=1ms TTL=63 Reply from 192.168.1.10: bytes=32 time=1ms TTL=63 Ping statistics for 192.168.1.10: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 1ms, Average = 1ms Control-C ^C C:\Users\User>ping 172.16.1.10 Pinging 172.16.1.10 with 32 bytes of data: Reply from 172.16.1.10: bytes=32 time=1ms TTL=63 Reply from 172.16.1.10: bytes=32 time=1ms TTL=63 Ping statistics for 172.16.1.10: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 1ms, Average = 1ms Control-C ^C
- Go to Monitor > IPsec Monitor, and enable the Proxy ID Destination and XAUTH User columns. The tunnel FCT_0 for bob is up. Also, bob was assigned with address 192.168.255.1.
- On the GUI, go to Monitor > Routing Monitor . A static route has been added for bob: 192.168.255.1.
- Phase 1. It's up (established).
FGT-HQ # diagnose vpn ike gateway list vd: root/0 name: FCT_0 version: 1 interface: port1 3 addr: 10.1.1.10:500 -> 10.10.10.10:500 virtual-interface-addr: 169.254.1.1 -> 169.254.1.1 created: 2320s ago xauth-user: bob assigned IPv4 address: 192.168.255.1/255.255.255.255 IKE SA: created 1/1 established 1/1 time 110/110/110 ms IPsec SA: created 1/1 established 1/1 time 30/30/30 ms id/spi: 1 e48906298987d1e9/ea8d1c57df6abd58 direction: responder status: established 2320-2320s ago = 110ms proposal: aes256-sha256 key: 785f9aac0b8d7446-80370aaf64c4b5e5-0f3c32f651ab335c-2e689ed61c0ce468 lifetime/rekey: 86400/83809 DPD sent/recv: 00000000/00000695
- Phase 2. Security associations (SAs) were negotiated. Tunnel is up.
FGT-HQ # diagnose vpn tunnel list name FCT_0 list all ipsec tunnel in vd 0 ------------------------------------------------------ name=FCT_0 ver=1 serial=c 10.1.1.10:0->10.10.10.10:0 dst_mtu=1500 bound_if=3 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/640 options=rgwy-chg frag-rfc run_state=1 accept_traffic=1 parent=FCT index=0 proxyid_num=1 child_num=0 refcnt=5 ilast=3 olast=3 ad=/0 stat: rxp=43 txp=6 rxb=5528 txb=360 dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=FCT proto=0 sa=1 ref=2 serial=1 add-route src: 0:0.0.0.0-255.255.255.255:0 dst: 0:192.168.255.1-192.168.255.1:0 SA: ref=3 options=2a6 type=00 soft=0 mtu=1438 expire=40832/0B replaywin=2048 seqno=7 esn=0 replaywin_lastseq=0000002b itn=0 qat=0 life: type=01 bytes=0/0 timeout=43189/43200 dec: spi=30512c74 esp=aes key=16 4e88e36e046870d365c4ef6091f26ab6 ah=sha1 key=20 3810fdb644fed133ca390e4c28c74f026e870462 enc: spi=b7574cc4 esp=aes key=16 866576e8e57c5327caedf8311db1627b ah=sha1 key=20 7a07c1e7f2c733920a1570cc31d76667f16b6fbc dec:pkts/bytes=43/2741, enc:pkts/bytes=6/720
- Routing table. A static route for bob (192.168.255.1) has been added.
FGT-HQ # get router info routing-table all Routing table for VRF=0 Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default S* 0.0.0.0/0 [10/0] via 10.1.1.1, port1 C 10.1.1.0/24 is directly connected, port1 C 169.254.1.1/32 is directly connected, FCT C 172.16.1.0/24 is directly connected, port7 C 192.168.1.0/24 is directly connected, port5S 192.168.255.1/32 [15/0] via 10.10.10.10, FCT
- When sniffing pings sent by remote user. ICMP requests and replies are seen.
FGT-HQ # diagnose sniffer packet any "host 192.168.1.10 and icmp" 4 0 l interfaces=[any] filters=[host 192.168.1.10 and icmp] 2020-05-05 22:50:44.199223 FCT in 192.168.255.1 -> 192.168.1.10: icmp: echo request 2020-05-05 22:50:44.199264 port5 out 192.168.1.254 -> 192.168.1.10: icmp: echo request 2020-05-05 22:50:44.199725 port5 in 192.168.1.10 -> 192.168.1.254: icmp: echo reply 2020-05-05 22:50:44.199742 FCT out 192.168.1.10 -> 192.168.255.1: icmp: echo reply 2020-05-05 22:50:45.216177 FCT in 192.168.255.1 -> 192.168.1.10: icmp: echo request 2020-05-05 22:50:45.216252 port5 out 192.168.1.254 -> 192.168.1.10: icmp: echo request 2020-05-05 22:50:45.216672 port5 in 192.168.1.10 -> 192.168.1.254: icmp: echo reply 2020-05-05 22:50:45.216698 FCT out 192.168.1.10 -> 192.168.255.1: icmp: echo reply FGT-HQ # diagnose sniffer packet any "host 172.16.1.10 and icmp" 4 0 l interfaces=[any] filters=[host 172.16.1.10 and icmp] 2020-05-05 22:51:21.119346 FCT in 192.168.255.1 -> 172.16.1.10: icmp: echo request 2020-05-05 22:51:21.119395 port7 out 172.16.1.254 -> 172.16.1.10: icmp: echo request 2020-05-05 22:51:21.119751 port7 in 172.16.1.10 -> 172.16.1.254: icmp: echo reply 2020-05-05 22:51:21.119758 FCT out 172.16.1.10 -> 192.168.255.1: icmp: echo reply 2020-05-05 22:51:22.139573 FCT in 192.168.255.1 -> 172.16.1.10: icmp: echo request 2020-05-05 22:51:22.139602 port7 out 172.16.1.254 -> 172.16.1.10: icmp: echo request 2020-05-05 22:51:22.140168 port7 in 172.16.1.10 -> 172.16.1.254: icmp: echo reply 2020-05-05 22:51:22.140184 FCT out 172.16.1.10 -> 192.168.255.1: icmp: echo reply
Feel free to download the configuration files used in this lab, as well as the output taken for some debugs during testing.
|ipsec-fct-FGT-HQ-623.conf||FortiGate HQ Configuration File||05/05/2020|
You can use the IPsec wizard to quickly configure a remote access IPsec VPN for FortiClient. I also had to make minor changes to the configuration made by the IPsec wizard to match our topology.
IPsec wizard is a great tool to configure basic IPsec VPN deployments. If you are new to FortiGate or don't have much experience with IPsec VPNs, you should consider using the IPsec wizard to configure your VPN.
A Network Security Engineer based in Canada.