Technical Tip: iPhone and iPad Dialup User IPsec VPN sample configuration

Description

This article provides an example IPsec VPN configuration for use with the built-in/native VPN client on iPhone and iPad.

The configuration was originally written for FortiOS v4.0 MR3, v5.0, v5.2 and v5.4 (since it differed from the configuration required for previous firmware versions), but it is still relevant for FortiOS v6.x and v7.x. The related article section further below provides a configuration guide for earlier firmware versions (FortiOS firmware version 4.0 MR2 and earlier), as well as a guide for IKEv2-based IPsec connections from iPhone/iPadOS clients to the FortiGate.

Important Note: This article documents a legacy VPN configuration based on the native Apple iOS IPsec client using IKEv1 Aggressive Mode. For new iOS/iPadOS VPN deployments, IKEv2 is the recommended protocol. This article should be used only when compatibility requirements necessitate IKEv1.

For the IKEv2 deployment guidance, refer to the latest documentation for iOS VPN configurations using IKEv2, as added below.

Note that in later FortiOS versions, an IPsec Wizard utility was added that allows admins to deploy a VPN based on a pre-made template (i.e. using settings matching vendor documentation). See the following FortiGate Admin Guide section for more information: iOS device as dial-up client.

Scope

FortiGate IPsec; iPhone/iPad clients using the built-in/native IPsec client.

This example is intended for a dial-up VPN network that requires connections from iPhone or iPad clients.

Solution

It should be noted that the VPN is configured as route-based, otherwise known as interface-based. The configuration requires a peer ID ('apple' in this case) as well as a user group. It is best to configure this VPN using the CLI as some of the required settings are not available in the web interface.

Additionally, the following configuration is built around Apple's native (aka Cisco) IPsec settings. Refer to the following documentation from Apple for the supported VPN settings (i.e. IKEv1 Aggressive mode, Phase1 and Phase 2 settings, etc.): Cisco IPsec VPN setup for Apple devices.

Set up a User, User Group, and Firewall Addresses:

config user local
    edit "testuser"
        set status enable
        set type password
        set passwd <password>
end

config user group
    edit "AppleVPNUsers"
        set member "test"
end

config firewall address
    edit "internal1subnet"
        set subnet <IP here, subnet here> 
    next
    edit "appleVPNsubnet"
        set subnet 10.3.3.0 255.255.255.0
end

 
Example value for 'set subnet': '192.168.29.0 255.255.255.0'.

Phase 1 settings:

config vpn ipsec phase1-interface
    edit "AppleVPN"
        set type dynamic
        set interface "wan1"
        set dhgrp 2
        set peertype one
        set xauthtype auto
        set mode aggressive
        set mode-cfg enable
        set proposal aes256-md5 aes256-sha1
        set peerid "apple"
        set authusrgrp "AppleVPNUsers"
        set ipv4-start-ip 10.3.3.1
        set ipv4-end-ip 10.3.3.254
        set ipv4-netmask 255.255.255.0
        set psksecret <tunnel password here>
end

Optional DNS Phase 1 settings:

set domain <domain suffix here>
set ipv4-dns-server1 <DNS server IP here>
set ipv4-dns-server2 <DNS server IP here>
set ipv4-dns-server3 <DNS server IP here>

Applying a domain here allows the VPN client to append a DNS suffix whenever it tries to resolve for a hostname, rather than the fully-qualified domain name (i.e. set domain 'domain.local' means DNS lookups for 'hostname' will automatically become hostname.domain.local).

Note: If IKEv1 is used along with Xauth, then "set domain <domain>" option will be available only if "set unity-support" is enabled. 

Phase 2 settings:

config vpn ipsec phase2-interface
    edit "AppleVPNp2"
        set keepalive enable
        set pfs disable
        set phase1name "AppleVPN"
        set proposal aes256-md5 aes256-sha1
end 

Configure Firewall Policies:

Under VPN -> LAN:

config firewall policy
    edit <unique firewall policy ID here>
        set srcintf "AppleVPN"
        set dstintf "internal1"
        set srcaddr "appleVPNsubnet"
        set dstaddr "internal1subnet"
        set action accept
        set schedule "always"
        set service "ANY"
    next 

 
Under LAN -> VPN:

edit <unique firewall policy ID here>
    set srcintf "internal1"
    set dstintf "AppleVPN"
    set srcaddr "internal1subnet"
    set dstaddr "appleVPNsubnet"
    set action accept
    set schedule "always"
    set service "ANY"
end 

If VPN clients will be accessing the Internet while connected (i.e. if this is a full-tunnel VPN), then create another firewall policy from the VPN tunnel out of the WAN interface (note that Source NAT is enabled in this policy):

config firewall policy
    edit <unique firewall policy ID here>
        set srcintf "AppleVPN"
        set dstintf "wan1"
        set srcaddr "appleVPNsubnet"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ANY"
        set nat enable
end

Static route-to-route traffic for tunnel clients back out of the tunnel:

config router static
    edit <unique route ID>
        set device "AppleVPN"
        set dst 10.3.3.0 255.255.255.0
end

Configuration required on the iPad/iPhone Cisco VPN Client:

• description: FortiGate VPN.

• server: IP of the FortiGate WAN interface that is configured for VPN (interface: wan1 in this case).

• account: testuser (a user account on the FortiGate).

• password: As configured previously.

• Use certificate: off.

• group name: apple. Corresponds to the Local ID (Local Identifier) of the FortiGate VPN (Phase 1).

• secret: Pre-shared key for the tunnel, from the phase one step.

Note: On the iPad or iPhone Cisco IPsec VPN client side, it is not required to configure any Phase 1 or Phase 2 parameters.

Troubleshooting:

If the access is still not working, verify if the DNS query is coming from the client end by performing sniffer or Packet Capture:

diagnose sniffer packet any "host <client private IP over SSLVPN> and port 53" 4 200 l

If there is no DNS query from the client, verify that the domain is configured correctly. If the DNS query is not being replied to, verify further if it is allowed by FortiGate by debugging the packet flow.

If a DNS query is being replied to, SYN is sent to the resolved domain, but it is not being replied to; verify if NAT is required on the policy being used.

Related articles:

• Technical Tip: FortiGate-to-iPhone IPSec VPN configuration guide (Japanese and English version)

• Technical Tip: Apple IOS native VPN using IKEv2 connection for IPSEC-VPN from FortiGate v5.4 to v5.6