Enforcing security posture tag match before dial-up IPsec VPN connection NEW
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_clientstag. -
FortiClient is registered to EMS and has the ZTNA security posture tag (
EMS1_ZTNA_all_registered_clients).
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 remote-gw-match ztna
set remote-gw-ztna-tags "EMS1_ZTNA_all_registered_clients"
set psksecret xxxxxxxx
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 …
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.
# diagnose debug application ike -1 ike :shrank heap by 159744 bytes ike V=root:0: comes 172.16.200.242:500->172.16.200.4:500,ifindex=9,vrf=0,len=456.... ike V=root:0: IKEv2 exchange=SA_INIT id=8044739046585b1a/0000000000000000 len=456 … ike V=root:0:8044739046585b1a/0000000000000000:164: responder received SA_INIT msg … ike V=root:0:8044739046585b1a/0000000000000000:164: incoming proposal: ike V=root:0:8044739046585b1a/0000000000000000:164: proposal id = 1: ike V=root:0:8044739046585b1a/0000000000000000:164: protocol = IKEv2: ike V=root:0:8044739046585b1a/0000000000000000:164: encapsulation = IKEv2/none ike V=root:0:8044739046585b1a/0000000000000000:164: type=ENCR, val=AES_CBC (key_len = 128) ike V=root:0:8044739046585b1a/0000000000000000:164: type=INTEGR, val=AUTH_HMAC_SHA2_256_128 ike V=root:0:8044739046585b1a/0000000000000000:164: type=PRF, val=PRF_HMAC_SHA2_256 ike V=root:0:8044739046585b1a/0000000000000000:164: type=DH_GROUP, val=MODP1536. ike V=root:0:8044739046585b1a/0000000000000000:164: proposal id = 2: ike V=root:0:8044739046585b1a/0000000000000000:164: protocol = IKEv2: ike V=root:0:8044739046585b1a/0000000000000000:164: encapsulation = IKEv2/none ike V=root:0:8044739046585b1a/0000000000000000:164: type=ENCR, val=AES_CBC (key_len = 256) ike V=root:0:8044739046585b1a/0000000000000000:164: type=INTEGR, val=AUTH_HMAC_SHA2_256_128 ike V=root:0:8044739046585b1a/0000000000000000:164: type=PRF, val=PRF_HMAC_SHA2_256 ike V=root:0:8044739046585b1a/0000000000000000:164: type=DH_GROUP, val=MODP1536. ike V=root:dialup: match remote ip failed ike V=root:0:8044739046585b1a/0000000000000000:164: my proposal, gw dialup: ike V=root:0:8044739046585b1a/0000000000000000:164: proposal id = 1: ike V=root:0:8044739046585b1a/0000000000000000:164: protocol = IKEv2: …