|
For initial deployment, review this KB article: Technical Tip: How to configure Microsoft Entra ID SAML authentication for Dial-up IPsec VPN.
If the dial-up tunnel failed to connect, there could be multiple reasons.
- Authentication Failed Against SAML. Collect these command logs before authentication:
diagnose vpn ike log-filter dst-addr4 x.x.x.x
diag debug console timestamp enable
di de app authd 60
diag debug app fnbamd -1
diag debug app saml -1
diag debug app ike -1
diag debug application eap_proxy -1
diag debug enable
For v7.4.0 and above, there is a slight change in command as below:
diagnose vpn ike log filter rem-addr4 x.x.x.x <----- x.x.x.x is client public IP.
diag debug console timestamp enable
di de app authd 60
diag debug app fnbamd -1
diag debug app saml -1
diag debug app ike -1
diag debug application eap_proxy -1
diag debug enable
Note:
It is a best practice to clear the filter before running the debugs. To clear the filter, enter the following command:
diagnose vpn ike log-filter clear
For v7.4.0 and above,
diagnose vpn ike log filter clear
After the test, to stop the debugging, press ctrl + c, and enter 'diagnose debug disable'.
Initiate the SAML connection and review if SAML authentication passed, if logs are stuck and no IKE logs are found most cases the issue is with the remote auth timeout value:
Note:
Verify that the 'external browser' is disabled on FortiClient. IPsec dial-up does not support an external browser currently, but this support is expected to be added in upcoming versions.
samld_send_common_reply [99]: Attr: 11, 1449, https://login.microsoftonline.com/xxxxxx-
send_common_reply [119]: Sent resp:
ike shrank heap by 331776 bytes
Analyze the following output:
show full sys global | grep remoteauthtimeout
By default value is set to 5, which means 5 seconds, then requires to increase in the time according login process as SAML authentication will take more than 5 seconds.
Refer to the article for remoteauth:
- Another reason is No proposal has been Chosen. If No proposal is chosen in the IKE logs, then the issue could be because of the phase 1 or phase 2 configuration error. Confirm the configuration of phase1 and phase 2 against the FortiClient configuration.
Related articles:
Troubleshooting Tip: Understanding message 'no proposal chosen' in IKE debug log
Technical Tip: IPSec VPN diagnostics – Deep analysis
- If IKE logs stop receiving traffic from users after the following logs then the issue is caused by:
ike 0:Test-VPN:98620: remote port change 1011 -> 64916
ike 0:Test-VPN:98620: out F293D467FA21A5A3AB2AB79
BC3E06FB12E202320000000010000008024000064DEEB75FB51E17E4
CC4418F12683D471877F7194BC1E89C8ED4475012F92726A2803E0374
FB01058D224652A4D8B227FE7F91347FBC447EA441A1A9B3F8
3035F90E73C626EF7EBF9DC21CADEB7C008E533E21D10E73DE236B
DA565F7AF8D4A9FD
ike 0:Test-VPN:98620: sent IKE msg (AUTH_RESPONSE): 2.94.156.100:4500->4.4.54.100:64916, len=128, vrf=0, id=f293d467fa21a5a3/ab2ab79bc3e06fb1:00000001
- Authentication group not configured or wrong authentication group configured on either IPSEC Phase1 or Firewall Policy.
- IKE version mismatch between FortiGate and FortiClient.
- Pre-shared Key mismatch.
To review the auth user group:
show VPN ipsec phase1-interface <VPN Name>
config vpn ipsec phase1-interface
edit "TEST-VPN"
set type dynamic
set interface "port4"
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256
set eap enable
set eap-identity send-request
set authusrgrp SAML_GRP
next
end
|
