Enforcing security posture tag match before dial-up IPsec VPN connection

IPsec dial-up VPN configurations can enforce a ZTNA security posture tag match before clients can establish a VPN tunnel. When a tag is defined on an IKEv2 IPsec tunnel, only the client IP addresses resolved by the tag can establish connection to the tunnel. When multiple tags are used, tags are checked sequentially until a match is made. If no tags match, then the client cannot establish a VPN connection.

config vpn ipsec phase1-interface
    edit <name>
        set ike-version 2
        set remote-gw-match {any | ipmask | iprange | geography | ztna}
        set remote-gw-ztna-tags <IPv4 ZTNA posture tags>
    next
end

When set remote-gw-match ztna is enabled, remote-gw-ztna-tags can be configured.

Example

A PC (172.16.200.242) makes a connection to the dial-up VPN gateway (172.16.200.4). The following example configuration and outputs show a successful connection with a matching ZTNA security posture tag (EMS1_ZTNA_all_registered_clients) and an unsuccessful connection when a ZTNA security posture tag cannot be matched.

It is assumed that the following mandatory pre-configurations are complete before configuring VPN:

• FortiGate has established a connection with FortiClient EMS and has synchronized the ZTNA security posture tags, including the EMS1_ZTNA_all_registered_clients tag.

• FortiClient is registered to EMS and has the ZTNA security posture tag (EMS1_ZTNA_all_registered_clients).

In this example, the VPN Wizard is used in the GUI to configure the IPsec tunnel and use the ZTNA tag EMS1_ZTNA_all_registered_clients. This requires that IKEv2 is enabled. The example mostly uses the default settings in the wizard, but these can be modified as required by your use case.

To configure the VPN gateway with the GUI:

1. Go to VPN > VPN Wizard.

2. Enter the Tunnel name, such as dialup.

3. Set Select a Template to Remote Access then click Begin.

4. Configure the VPN tunnel:

   

   VPN client type	FortiClient
   Authentication method	Pre-shared key
   Pre-shared key	Enter the pre-shared key.
   IKE	Version 2
   Transport	Auto
   NAT traversal	Enable
   EAP peer identification	EAP identity request
   User authentication method	Phase1 interface Select a user group for user authentication from the drop-down list.
   DNS Server	Use System DNS
   Enable IPv4 Split Tunnel	Enable

5. Click Next.

6. Configure the Remote endpoint:

   

   Addresses to assign to connected endpoints	Enter the VPN IP address range that needs to be assigned to VPN endpoints: 10.212.134.200-10.212.134.254
   Subnet for connected endpoints	255.255.255.255
   Security posture gateway matching	Enable
   Security posture tags	Add one or more ZTNA Tags, for example: IP TAG all_registered_clients
   EMS SN verification	Enable
   Save password	Enable
   Auto Connect	Disable
   Always up (keep alive)	Disable

7. Click Next.

8. Configure the Local FortiGate:

   

   Incoming interface that binds to tunnel	Select the WAN Interface. In this example, that is the interface with IP address 172.16.200.4.
   Create and add interface to zone	Enable
   Local interface	Select the LAN interface. In this example, that is the interface that is connected to PC4.
   Local Address	Select a local address to allow access from the VPN. In this example, that is the IP address of PC4.

9. Click Next.

10. Review the configuration. If everything looks correct, click Submit.

To configure the VPN gateway with the CLI:

config vpn ipsec phase1-interface
    edit "dialup"
        set type dynamic
        set interface "port1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal aes128-sha256 aes256-sha256 aes128gcm-prfsha256 aes256gcm-prfsha384 chacha20poly1305-prfsha256
        set eap enable
        set eap-identity send-request
        set authusrgrp "local-group"
        set ems-sn-check enable
        set transport auto
        set remote-gw-match ztna		
        set ipv4-start-ip 10.1.1.1
        set ipv4-end-ip 10.1.1.254
        set dns-mode auto
        set ipv4-split-include "dialup_split"
        set save-password enable
        set psksecret xxxxxxxx
        set remote-gw-ztna-tags "EMS1_ZTNA_all_registered_clients"
    next
end
config vpn ipsec phase2-interface
    edit "DY"
        set phase1name "dialup"
        set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305
    next
end

Results

When a client (172.16.200.242) has the appropriate ZTNA security posture tag, it is synchronized to FortiClient EMS and FortiGate.

To view the IP address that is resolved to tag:

# diagnose firewall dynamic list EMS1_ZTNA_all_registered_clients
 
CMDB name: EMS1_ZTNA_all_registered_clients
TAG name: all_registered_clients
EMS1_ZTNA_all_registered_clients: ID(6)
        ADDR(172.16.200.242)
Total IP dynamic range blocks: 0.
Total IP dynamic addresses: 1.

The address resolves to the IP address that is configured on the client endpoint. It does not resolve to the NAT’d public IP address when the client is behind NAT. In other words, the address resolves to the IP Address in the following output, and not the Public IP Address:

# diagnose endpoint ec-shm list
 
Record #0:
                IP Address = 172.16.200.242
                MAC Address = **:**:**:**:67:74
                MAC list =
                VDOM = root (0)
                TOKEN VDOM =  (-1)
                EMS serial number: FCTEMS***********
                EMS tenant id: *************1EDB589FBC4626
                Client cert SN: *************60ACA9FE283DEEC3B
                Public IP address: *************
                Quarantined: no
                Online status: online
                Registration status: registered
                On-net status: on-net
                Gateway Interface: port1
                FortiClient version: 7.2.4
                …
                Number of Routes: (1)
                        Gateway Route #0:
                                - IP:172.16.200.242, MAC: **:**:**:**:67:74, VPN: no
                                - Interface:port1, VDOM:root (0), SN: FG5H*************

From the PC1 client, establish a tunnel with the FortiGate VPN gateway. When enabled, the following debug information displays the output when the security posture tag is matched:

# diagnose debug application ike -1
… 
ike V=root:0:DY:155: received FCT-UID : 6108A9179A5C40D7BD57504E15114C1F
ike V=root:0:DY:155: received EMS SN : FCTEMS***********
ike V=root:0:DY:155: received EMS tenant ID : *************1EDB589FBC4626
ike V=root:0:DY:155: peer identifier IPV4_ADDR 172.16.200.242
ike V=root:0:DY:155: re-validate gw ID
ike V=root:0:DY:155: gw validation OK
ike V=root:0:DY:155: responder preparing EAP identity request
…
ike V=root:0:FCT:22: responder received AUTH msg
ike V=root:0:FCT:22: peer identifier IPV4_ADDR 172.16.200.242
ike V=root:0:FCT:22: auth verify done 
ike V=root:0:FCT:22: responder AUTH continuation
ike V=root:0:FCT:22: authentication succeeded
ike V=root:0:FCT:22: EMS SN check passed
ike V=root:0:FCT:22: EMS ZTNA tags check success ZTNA_all_registered_clients
ike V=root:0:FCT:22: responder creating new child 

The following tunnel output indicates a dial-up tunnel has been established:

# diagnose vpn ike gateway list 
vd: root/0
name: dialup_0
version: 2
interface: port1 9
addr: 172.16.200.4:500 -> 172.16.200.242:500
tun_id: 10.212.134.200/::10.0.0.5
remote_location: 0.0.0.0
network-id: 0
transport: UDP
created: 34s ago
eap-user: userc
2FA: no
peer-id: 172.16.200.242
peer-id-auth: no
FortiClient UID: 6108A9179A5C40D7BD57504E15114C1F
assigned IPv4 address: 10.212.134.200/255.255.255.255
pending-queue: 0
PPK: no
IKE SA: created 1/1  established 1/1  time 10/10/10 ms
IPsec SA: created 1/1  established 1/1  time 0/0/0 ms
…
 
# diagnose vpn tunnel list 
list all ipsec tunnel in vd 0
------------------------------------------------------
name=dialup ver=2 serial=1 172.16.200.4:0->0.0.0.0:0 nexthop= tun_id=10.0.0.1 tun_id6=::10.0.0.1 status=up dst_mtu=0 weight=1
bound_if=9 real_if=0 lgwy=static/1 tun=intf mode=dialup/2 encap=none/552 options[0228]=npu frag-rfc  role=primary accept_traffic=1 overlay_id
=0
 
proxyid_num=0 child_num=1 refcnt=3 ilast=42978277 olast=42978277 ad=/0
stat: rxp=1290 txp=40 rxb=65588 txb=34472
dpd: mode=on-demand on=0 status=ok idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
fec: egress=0 ingress=0
------------------------------------------------------
name=dialup_0 ver=2 serial=5 172.16.200.4:0->172.16.200.242:0 nexthop=172.16.200.242 tun_id=10.212.134.200 tun_id6=::10.0.0.5 status=up dst_mtu=1
500 weight=1
bound_if=9 real_if=9 lgwy=static/1 tun=intf mode=dial_inst/3 encap=none/74408 options[122a8]=npu rgwy-chg frag-rfc  run_state=0 role=primary
accept_traffic=1 overlay_id=0
 
parent=dialup index=0
…

In the scenario where a client without a matching tag tries to establish a tunnel, the following debug information indicates that the tunnel cannot match the remote IP of the client.

ike V=root:0:FCT:23: responder received AUTH msg
ike V=root:0:FCT:23: peer identifier IPV4_ADDR 172.16.200.242
ike V=root:0:FCT:23: auth verify done
ike V=root:0:FCT:23: responder AUTH continuation
ike V=root:0:FCT:23: authentication succeeded
ike V=root:0:FCT:23: EMS SN check passed
ike V=root:0:FCT:23: EMS ZTNA tags check failure, abort
ike V=root:FCT Negotiate SA Error: EMS ZTNA tags check failed
ike V=root:0:FCT:23: sending IKE_AUTH ZTNA TAGS check failure notification response