Skip to main content
bup
New Member
February 19, 2026
Question

Firewall policy match based on IPSec user (PKI)

  • February 19, 2026
  • 4 replies
  • 448 views

Hi everyone,

 

after a lot of trial and error, I managed to set up a working IPSec VPN configuration based on certificates (server and client auth) that works for the FortiClient and also for strongswan (on Linux). Now I would like to extend our firewall policies, so that we can limit access for individual users to what services they actually need. Since user matching is already part of the IPSec authentication, I assumed that this would be fairly easy, but it doesn't work. As soon as I select the group containing the authenticated user for the policy, it doesn't match anymore and traffic is dropped.

 

Here are the relevant excerpts of the configuration:

 

# PKI user:

config user peer
edit "vpnphip"
set ca "CA_Cert_2"
set subject "CN = vpn-bup"
next
end

 

(I first tried with "set cn vpn-bup", with the same result)

 

# PKI group:

config user peergrp
edit "vpnadmin"
set member "vpnphip"
next
end

 

# Normal user group:

config user group
edit "vpngroup"
set member "vpnphip"
next
end

 

# IPSec:

config vpn ipsec phase1-interface
edit "swi-vpn"
set type dynamic
set interface "WAN"
set ike-version 2
set authmethod signature
set peertype peergrp
set net-device disable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256 aes128gcm-prfsha256 aes256gcm-prfsha384 chacha20poly1305-prfsha256
set dpd on-idle
set dhgrp 20 21
set wizard-type dialup-forticlient
set transport udp
set certificate "1.2.3.4"
set peergrp "vpnadmin" # <-- PKI peer group
set ipv4-start-ip 10.9.0.2
set ipv4-end-ip 10.9.0.254
set ipv4-split-include "swi-vpn_split"
set save-password enable
set dpd-retrycount 10
next
end

 

# Firewall policy:

config firewall policy
edit 3
set name "vpn_swi-vpn_local_allow"
set srcintf "vpn_swi-vpn_zone"
set dstintf "SWI-SRV"
set action accept
set srcaddr "swi-vpn_range"
set dstaddr "swi-vpn_split"
set schedule "always"
set service "ALL"
set nat enable
set groups "vpngroup" # <-- Normal user group containing vpnphip
next
end

 

 

When I debug the IKE traffic, I see that the user is correctly authenticated using the certificate as PKI user "vpnphip":

 

...
ike V=root:0:swi-vpn:120: responder received AUTH msg
ike V=root:0:swi-vpn:120: processing notify type INITIAL_CONTACT
ike V=root:0:swi-vpn:120: processing notify type MOBIKE_SUPPORTED
ike V=root:0:swi-vpn:120: processing notify type ADDITIONAL_IP4_ADDRESS
ike V=root:0:swi-vpn:120: processing notify type ADDITIONAL_IP4_ADDRESS
ike V=root:0:swi-vpn:120: processing notify type ADDITIONAL_IP4_ADDRESS
ike V=root:0:swi-vpn:120: processing notify type EAP_ONLY_AUTHENTICATION
ike V=root:0:swi-vpn:120: processing notify type MESSAGE_ID_SYNC_SUPPORTED
ike V=root:0:swi-vpn:120: received peer identifier DER_ASN1_DN 'CN = vpn-bup'
ike V=root:0:swi-vpn:120: re-validate gw ID
ike V=root:0:swi-vpn:120: gw validation OK
ike V=root:0:swi-vpn:120: received peer certreq 'xxx'
ike V=root:0:swi-vpn:120: Validating X.509 certificate
ike V=root:0:swi-vpn:120: peer cert, subject='vpn-bup', issuer='CA1'
ike V=root:0:swi-vpn:120: peer ID verified
ike V=root:0:swi-vpn:120: building fnbam peer candidate list
ike V=root:0:swi-vpn:120: FNBAM_GROUP_NAME candidate 'vpnphip'
ike V=root:0:swi-vpn:120: certificate validation pending
...
[731] fnbamd_cert_check_group_list-checking group with name 'vpnphip'
[544] __check_add_peer-check 'vpnphip'
[551] __check_add_peer-'vpnphip' check ret:good
[666] __peer_user_clear_unmatched-Clear all user(s) other than 'vpnphip'
[687] __peer_user_clear_unmatched-
[200] __get_default_ocsp_ctx-def_ocsp_ctx=(nil), no_ocsp_query=0, ocsp_enabled=0
[804] fnbamd_cert_check_group_list-Peer users
[807] fnbamd_cert_check_group_list- 'vpnphip' ('N/A','N/A','N/A')
...
[1329] fnbamd_cert_auth_copy_cert_status-Matched peer user 'vpnphip'
[912] fnbamd_cert_check_matched_groups-checking group with name 'vpnphip', peer_ctx->peer_user->setting.name:vpnphip
...
ike V=root:0:swi-vpn:120: fnbam reply 'vpnphip' # <-- Looks good
...
[138] fnbamd_peer_ctx_free-Freeing peer ctx 'vpnphip'
ike V=root:0:swi-vpn:120: certificate validation succeeded
ike V=root:0:swi-vpn:120: signature verification succeeded
ike V=root:0:swi-vpn:120: auth verify done
ike V=root:0:swi-vpn:120: responder AUTH continuation
ike V=root:0:swi-vpn:120: authentication succeeded
...

 

 

However, the policy isn't matched and the traffic is dropped when the group is configured there; access works if I remove the group from the policy configuration. Interestingly, the system logs show that the user is authenticated, but they never refer to the "vpnphip" name, but instead list it as "CN = vpn-bup":

 

 

Local IP a.b.c.d
Source Country/Region XXXX
FortiClient ID N/A
User CN = vpn-bup
Group vpnadmin

 

 

What do I need to do to make this matching work? Is there some setting to tell the firewall to properly handle PKI users (as opposed to "normal" system users) in firewall policies? Or does the name of the PKI user matter? Do I need to do a mapping of PKI users to "normal" users instead and put those into the policy source group?

 

I'm testing on a #FortiGate 60F, in case this matters.

 

EDIT: I've enabled logging for the "Implicit deny" rule and when I now check the traffic log, I see that those dropped requests don't include any user in the "Source" part:

 

Source10.9.0.2
Source Country/RegionReserved
Source Interface
swi-vpn

 

So it appears as if the firewall "forgets" from which authenticated user this traffic came. Is there some configuration needed so that the authentication information is properly attached to the actual traffic/sessions?

 

Thanks and best regards.

4 replies

funkylicious
SuperUser
SuperUser
February 19, 2026
bup
bupAuthor
New Member
February 19, 2026

Not so much, this is about username+password XAUTH authentication, not with a certificate.

funkylicious
SuperUser
SuperUser
February 19, 2026

if its certificate based only, it only means that you cannot differentiate between users if no identity is provided.

i dont think you can achieve want you want with the current configuration.

"jack of all trades, master of none"
Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.