Description
This article describes how EAP functionality on FortiOS can match multiple groups against a remote authentication source when reading multiple groups from the firewall policy instead of the group configured under the phase 1 setting of the Dialup tunnel.
Scope
FortiGate v7.0 and later.
Solution
While configuring EAP authentication for Dialup on FortiGate, there are two ways to match the users with the proper groups:
- Match the group on the phase 1 setting with the 'set authusrgrp'.
- Match the groups on the firewall policy for the IPsec tunnel created.
With option one the group is matched to the tunnel using the authusrgrp configuration:
config vpn ipsec phase1-interface
edit “EAP-Dialup”
set eap enable
set eap-identity send-request
set authusrgrp "Dialup-EAP-1"
end
This forces the EAP to match only this group with the group information sent back by the authentication daemon (FNBAMD) resolved from the authentication source for this group:
ike 2:EAP-Dialup:2324: responder received AUTH msg
ike 2:EAP-Dialup:2324: processing notify type INITIAL_CONTACT
ike 2:EAP-Dialup:2324: processing notify type FORTICLIENT_CONNECT
ike 2:EAP-Dialup:2324: received FCT data len = 216, data = 'VER=1
FCTVER=7.0.8.0427
UID=229FFF9C465245AE89C50465329BAA6F
IP=172.17.98.29
MAC=00-15-5d-62-10-06;
HOST=DESKTOP-TN8MVD5
USER=test1
OSVER=Microsoft Windows 8.0 Professional Edition, 64-bit (build 9200)
REG_STATUS=0
'
ike 2:EAP-Dialup:2324: received FCT-UID = 229FFF9C465245AE89C50465329BAA6F
ike 2:EAP-Dialup:2324: peer identifier IPV4_ADDR 172.17.98.29
ike 2:EAP-Dialup:2324: re-validate gw ID
ike 2:EAP-Dialup:2324: gw validation OK
ike 2:EAP-Dialup:2324: responder preparing EAP identity request
ike 2:EAP-Dialup:2324: enc
ike 2:EAP-Dialup:2324: remote port change 500 -> 4500
ike 2:EAP-Dialup:2324: out
ike 2:EAP-Dialup:2324: sent IKE msg (AUTH_RESPONSE): 172.17.97.77:4500->172.17.98.29:4500, len=128, vrf=0, id=d86d633374d189ed/e970a9c56b9f5c28:00000001
ike 2: comes 172.17.98.29:4500->172.17.97.77:4500,ifindex=5,vrf=0....
ike 2: IKEv2 exchange=AUTH id=d86d633374d189ed/e970a9c56b9f5c28:00000002 len=80
ike 2: in ike 2:EAP-Dialup:2324: dec
ike 2:EAP-Dialup:2324: responder received EAP msg
ike 2:EAP-Dialup:2324: send EAP message to FNBAM
ike 2:EAP-Dialup:2324: initiating EAP authentication
ike 2:EAP-Dialup: EAP user "test1"
ike 2:EAP-Dialup: auth group Dialup-EAP-1
ike 2:EAP-Dialup: EAP 961302487 pending
In the highlighted sections above, it is shown how EAP sends the user information provided by the user and the group configured under the authusrgrp to the FNBAMD for authentication. After successful authentication by the FNBAMD daemon, the EAP receives this information back and initiates the mode config and afterward, the phase 2 negotiation:
fnbamd_dbg_hex_pnt[48] EAP msg from server (4)-03 84 00 04
[1548] fnbamd_auth_handle_radius_result-->Result for radius svr 'eap_proxy' 127.0.0.1(1) is 0
[1623] fnbam_user_auth_group_match-req id: 961302487, server: eap_proxy, local auth: 0, dn match: 0
[1581] __group_match-Group 'Dialup-EAP-1' passed group matching
[1584] __group_match-Add matched group 'Dialup-EAP-1'(20)
[292] find_matched_usr_grps-Passed group matching
[209] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 961302487, len=2544
[808] destroy_auth_session-delete session 961302487
ike 2:EAP-Dialup:2324 EAP 961302487 result FNBAM_SUCCESS
ike 2:EAP-Dialup: EAP succeeded for user "test1" group "Dialup-EAP-1" 2FA=no
[1086] fnbamd_ext_idps_destroy-
ike 2:EAP-Dialup:2324: responder preparing EAP pass through message
ike 2:EAP-Dialup:2324: enc 00000008038400040706050403020107
ike 2:EAP-Dialup:2324: out ike 2:EAP-Dialup:2324: sent IKE msg (AUTH_RESPONSE): 172.17.97.77:4500->172.17.98.29:4500, len=80, vrf=0, id=d86d633374d189ed/e970a9c56b9f5c28:00000004
ike 2: comes 172.17.98.29:4500->172.17.97.77:4500,ifindex=5,vrf=0....
ike 2: IKEv2 exchange=AUTH id=d86d633374d189ed/e970a9c56b9f5c28:00000005 len=112
ike 2: in ike 2:EAP-Dialup:2324: dec ike 2:EAP-Dialup:2324: responder received AUTH msg
ike 2:EAP-Dialup:2324: auth verify done
ike 2:EAP-Dialup:2324: responder AUTH continuation
ike 2:EAP-Dialup:2324: authentication succeeded
ike 2:EAP-Dialup:2324: responder creating new child
Therefore, the firewall policies matched afterward can only match one group and, in this case, no user group on the firewall policy is needed as the group is already matched by EAP.
Important Note:
When both of these authentication methods are in place and the user group to be authenticated is set both in the phase 1 settings and the corresponding firewall policy then the policy cannot be matched and the authentication fails with the traffic being dropped by the policy 0 and the debug flow showing the 'iprope_in_check() check failed on policy 0, drop' message.
Therefore only one of these ways needs to be set with the second one (authgroup set on policy) being the most flexible.
In certain designs, the requirement is to match different groups with different firewall policies. In that case, option 2 needs to be utilized. With option 2, EAP does not have any groups to match and the authusrgp configuration is not set.
In this case, the FNBAMD daemon will feed the groups to EAP to match.
Configuration:
config vpn ipsec phase1-interface
edit “EAP-Dialup”
set eap enable
set eap-identity send-request
<< no set authusrgrp configured>>
end
In the firewall policy, the source IP needs to be set to 'all' to trigger the authentication and successfully connect to the VPN.
As authentication takes place before IP assignment during IPsec VPN negotiation while using EAP with IKEv2, utilizing the IPsec VPN address range can lead to a discrepancy in the firewall policy causing it to be bypassed.
Diagnostics:
FCTVER=7.0.8.0427
UID=229FFF9C465245AE89C50465329BAA6F
IP=172.17.98.29
MAC=00-15-5d-62-10-06;
HOST=DESKTOP-TN8MVD5
USER=test1
OSVER=Microsoft Windows 8.0 Professional Edition, 64-bit (build 9200)
REG_STATUS=0
'
ike 2:EAP-Dialup:2354: received FCT-UID = 229FFF9C465245AE89C50465329BAA6F
ike 2:EAP-Dialup:2354: peer identifier IPV4_ADDR 172.17.98.29
ike 2:EAP-Dialup:2354: re-validate gw ID
ike 2:EAP-Dialup:2354: gw validation OK
ike 2:EAP-Dialup:2354: responder preparing EAP identity request
ike 2:EAP-Dialup:2354: enc ike 2:EAP-Dialup:2354: remote port change 500 -> 4500
ike 2:EAP-Dialup:2354: out ike 2:EAP-Dialup:2354: sent IKE msg (AUTH_RESPONSE): 172.17.97.77:4500->172.17.98.29:4500, len=128, vrf=0, id=957b6705876342b8/da0f7d93618c13eb:00000001
ike 2: comes 172.17.98.29:4500->172.17.97.77:4500,ifindex=5,vrf=0....
ike 2: IKEv2 exchange=AUTH id=957b6705876342b8/da0f7d93618c13eb:00000002 len=80
ike 2: in ike 2:EAP-Dialup:2354: dec
ike 2:EAP-Dialup:2354: responder received EAP msg
ike 2:EAP-Dialup:2354: send EAP message to FNBAM
ike 2:EAP-Dialup:2354: initiating EAP authentication
ike 2:EAP-Dialup: EAP user "test1"
ike 2:EAP-Dialup: auth candidate group 'Dialup-EAP-1' 20 --> candidate group received from firewall policy list
ike 2:EAP-Dialup: auth candidate group 'Dialup-EAP-2' 21 --> candidate group received from firewall policy list
ike 2:EAP-Dialup: EAP 961302496 pending
After reading each group from the firewall policy list, EAP then proceeds to send them back to FNBAMD for further authentication. After successful authentication, the FNBAMD sends back the matched group to EAP:
fnbamd_dbg_hex_pnt[48] EAP msg from server (4)-03 A6 00 04
[1548] fnbamd_auth_handle_radius_result --> Result for radius svr 'eap_proxy' 127.0.0.1(1) is 0.
[1623] fnbam_user_auth_group_match-req id: 961302496, server: eap_proxy, local auth: 0, dn match: 0
[1581] __group_match-Group 'Dialup-EAP-1' passed group matching
[1584] __group_match-Add matched group 'Dialup-EAP-1'(20)
[292] find_matched_usr_grps-Passed group matching
[209] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 961302496, len=2544
[808] destroy_auth_session-delete session 961302496
[1086] fnbamd_ext_idps_destroy-
ike 2:EAP-Dialup:2354 EAP 961302496 result FNBAM_SUCCESS
ike 2:EAP-Dialup: user 'test1' authenticated group 'Dialup-EAP-1' 20
ike 2:EAP-Dialup:2354: responder preparing EAP pass through message
ike 2:EAP-Dialup:2354: enc 0000000803A600040706050403020107
ike 2:EAP-Dialup:2354: out 9
As a result of the above functionality the multiple groups on the firewall policy can be used to separate, different group’s traffic from one another:
Here is an example of user test1 belonging to the Dialup-EAP-1 group matching policy ID 13:
Here is an example of user test2 belonging to the Dialup-EAP-2 matching policy ID 14:
In the above, local authentication using local users on FortiGate has been utilized which simplifies the group matching. In the following sections, the two different remote authentication sources of EAP are explained and outlined. The configuration on the phase 1 setting of the Dialup server (FortiGate) is the same across. The only difference is how the group matching occurs.
RADIUS:
Using Radius, the RADIUS server (for example NPS) needs to be configured with the proper VSA attributes to send back to the FortiGate for group matching. Then different user groups on the firewall can be used to match against different attributes. Here is one example of using a Microsoft NPS server: Technical Tip: Configuring FortiGate and Microsoft NPS (Radius with AD authentication).
SAML:
Using SAML with EAP which is supported by FortiClient v7.2.4/v7.4.0 and FortiGate v7.2.4, the process is the same as Radius with the difference that the SAMLD daemon on the firewall needs to receive the proper group attribute from the IDP and process it to FNBAMD.
The configuration for SAML and EAP is explained in the below articles. However, if multiple group matching needs to be implemented, multiple user groups on the firewall need to be matched with different group attributes with the IDP and authusrgrp configuration needs to be blank as discussed above: SAML-based authentication for FortiClient remote access dialup IPsec VPN clients.
Diagnostics:
diagnose debug app samld -1 (if SAML is used)
diagnose debug app ike -1
diagnose debug app fnbamd -1
diagnose debug app eap_proxy -1
diagnose debug console timestamp en
diagnose debug en
Related documents:
Configuring SAML SSO
Technical Tip: IKEv2 dialup IPsec tunnel with Radius server authentication and FortiClient
Troubleshooting Tip: for using Ikev2 for dialup Ipsec tunnel with radius server and Local user
