| Description |
This article describes an expected behavior when remote users are connected to a full-tunnel IPsec VPN tunnel on the FortiGate and are trying to connect to resources on their local LAN, as well as the option on FortiClient/FortiGate for controlling this behavior (and some additional factors to keep in mind). |
| Scope | FortiGate, FortiClient. |
| Solution |
As an example for this article, consider a user at home on the 192.168.2.0/24 subnet. When they connect to the IPsec full-tunnel on the FortiGate, the default expected-behavior is that the user will no longer able to access 192.168.2.181 on the local subnet.
This behavior is due to how FortiClient handles IPsec tunnel connections specifically (both IKEv1 and IKEv2), as it intercepts user traffic and then determines which interface traffic should be routed over (e.g. local network interface vs. IPsec tunnel interface). With full-tunnel IPsec, all traffic is captured and routed over the tunnel interface, even if it would typically match to the local/connected subnet for the user.
Notably, full-tunnel SSL-VPN behaves differently and will not force all traffic over the VPN tunnel (i.e. users on full-tunnel SSL-VPN can still reach hosts on the locally-connected physical subnet, all other traffic goes over the VPN tunnel).
If a dialup IPsec user needs to be able to reach hosts on the local subnet then there are two options available:
Option 1: Utilize Split-Tunneling for IPsec With split-tunneling, the FortiGate defines a specific list of subnets that should be matched/routed over the dialup IPsec tunnel and everything else is sent out the dialup client's local network adapter. Refer to the following KB article for steps to enable split-tunnel functionality for an IPsec dialup tunnel on the FortiGate: Technical Tip: Enable split-tunnel For IPsec VPN
However, this solution may not be feasible in all scenarios (i.e. there may be security requirements to tunnel all traffic over to the FortiGate for inspection), and in those cases the option below may be considered instead.
Option #2: Enable Local LAN on the FortiClient VPN configuration If it is not possible to utilize split-tunneling for the IPsec tunnel then the Enable Local LAN option on FortiClient may be used instead.
This option (disabled by default) can be set for IPsec tunnel configurations on FortiClient and it results in FortiClient not sending traffic for a user's locally-connected subnet over the VPN tunnel (thus allowing users to access devices on their local network). There are a few methods for enabling this option:
For custom IPsec tunnels on FortiClient, the Enable Local LAN option can be set by editing the tunnel and toggling the radio checkbox under Advanced Settings -> Phase 1:
For EMS-managed FortiClients, this option can be pushed as part of the Endpoint Profile assigned to the device (under Endpoint Profiles -> Remote Access, then modify the IPsec VPN tunnel configuration and go to Basic Settings -> Phase 1).
If the option is not visible in FortiClient and EMS is not being used then it can instead be enabled in the XML configuration. Export the configuration from FortiClient VPN (the gear icon in the top-right, then Backup the configuration) and add the <enable_local_lan> element as per the FortiClient XML Reference (see: FortiClient XML Reference Guide - IPsec VPN:(
<forticlient_configuration> <vpn> <ipsecvpn> <connections> <connection> <ike_settings> <enable_local_lan>[0=disable; 1=enable]</enable_local_lan> </ike_settings> </connection> </connections> </ipsecvpn> </vpn> </forticlient_configuration>
After adding the <enable_local_lan>, the config can be restored to FortiClient and users will be able to access the locally-connected LAN subnet while on a full-tunnel dialup IPsec tunnel.
Note: One problem scenario that can occur is if the user's local subnet overlaps with a remote subnet behind the FortiGate (e.g. 192.168.2.0/24 is present on both the user's local LAN and a corporate LAN subnet).
In this scenario, it will only be possible for the user to reach the corporate LAN OR the local LAN, but not both at the same time while on the VPN. Enabling Local LAN will allow the user to reach the local LAN, but as a result they will not be able to reach the overlapped corporate LAN. To address this, a different solution is required (the following solution states site-to-site VPN but is applicable to dialup VPNs as well): FortiGate Administration Guide - Site-to-site VPN with overlapping subnets |
