Hello,
I am experiencing an issue with the dot1x configuration on FortiNAC.
I am using FortiNAC 700F, version 7.2.8.0149.
I have followed all the steps shown in this video:
https://www.youtube.com/watch?v=7pRg2-SVipo
The problem is that I don’t have the "EAP-Type-Name" option.
I still followed the entire video and applied the instructions, but when I connect a PC to the switch port where dot1x auto-registration is enabled, the PC shows "authentication failed."
On the FortiNAC side, I don’t see any activity logs.
Here is the switch configuration:
interface GigabitEthernet0/17
switchport access vlan 2
switchport mode access
switchport voice vlan 150
srr-queue bandwidth share 1 30 35 5
priority-queue out
authentication host-mode multi-host
authentication port-control auto
authentication periodic
authentication timer reauthenticate 180
mab
snmp trap mac-notification change added
snmp trap mac-notification change removed
mls qos trust device cisco-phone
mls qos trust cos
dot1x pae authenticator
dot1x timeout quiet-period 3
dot1x timeout server-timeout 10
dot1x timeout tx-period 10
dot1x timeout supp-timeout 6
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY
end
aaa new-model
!
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
!
aaa nas port extended
!
radius-server host 172.16.180.104 auth-port 1645 acct-port 1646 key 7 encryptedpassword
radius-server vsa send authentication
I also tried configuring:
radius-server host 172.16.180.104 auth-port 1812 acct-port 1813 key
But it didn’t make any difference.
Thank you in advance for your help!
Best regards,
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
The request is being sourced from 172.27.1.98. Is the switch added with this IP in FortiNAC? FortiNAC will ignore RADIUS requests when these are not coming from a Source IP it has in the inventory view.
Enable following debugs in FortiNAC:
diagnose debug plugin enable RadiusAccess
diagnose debug plugin enable RadiusManager
diagnose debug plugin enable BridgeManager
diagnose tail -F output.master
Then recreate again the issue. Ouptut.master logs should show how the request is being processed.
Additionally double check that "radius" and "radius-local" services are allowed on port1.
show system interface
config system interface
edit port1
set ip 10.10.10.6/24
set allowaccess http https-adminui nac-agent nac-ipc netflow ping radius radius-acct radius-local radius-local-radsec snmp ssh
end
To troubleshoot the issue with dot1x configuration on FortiNAC, where the "eap-type-name" option is missing and PCs show "authentication failed" when connected to the switch port, follow these steps:
1. Verify the FortiNAC configuration for any missing settings related to EAP types.
2. Check the switch configuration to ensure all dot1x settings are correctly applied, including the authentication method and RADIUS server details.
3. Confirm that the RADIUS server is properly configured with the correct ports and shared key.
4. Review the logs on both the switch and FortiNAC for any error messages or authentication failures.
In this case, the "EAP-Type-Name" option is just a filter you apply in the User&Host profile in order to match the host and apply the Network access configuration. It is not mandatory and you can remove that filter and use something else.
However this part is relevant after the host is registered. In your case this has not happened yet due to authentication failing. After the host successfuly registers through 802.1x successful auth, then the NAC policy is applied.
This is explained here: https://community.fortinet.com/t5/FortiNAC-F/Technical-Tip-State-based-Control-concept-and-VLAN-chan...
First check why auth is failing by going to Network->Radius and enable debugging to High.
Check the Service Logs and track the Username/MAC attempting the authentication. You will be provided with a possible reason of why this is failing.
In addition, the Authentication policy configuration (method RADIUS) shown in the video is misleading. Firstly is not needed, in this case there is already a RADIUS authentication in place. This authentication policy will trigger a 2nd authentication request to the end user via the Portal or Persistent agent which doesn't make sense if the user has to provide the same credentials that are already configured in the Supplicant. Also the 'Forced Authentication' doesn't appear enforced at the port level which means that the host will not match it.
The User/Host profile potential is better used when there are conditions based on Host and User attributes like groups or roles. Having a general RADIUS attribute check is not that granular.
As mentioned enabling RADIUS logs or a simple packet capture for the RADIUS traffic will give more insights about the authentication failure:
# execute tcpdump port 1812 and host x.x.x.x -vX
*(replace x.x.x.x with the IP of the switch)
Hi,
Here are the RADIUS logs:
Service Status:
* radiusd.service - FreeRADIUS multi-protocol policy server (Persistent)
Loaded: loaded (/lib/systemd/system/radiusd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/radiusd.service.d
└─radiusd.service.conf
Active: active (running) since Mon 2024-12-02 15:26:38 CET; 25s ago
Process: 1333535 ExecStartPre=/bin/chown -R radiusd.radiusd /run/radiusd (code=exited, status=0/SUCCESS)
Process: 1333536 ExecStartPre=/usr/sbin/radiusd $FREERADIUS_OPTIONS -Cx -lstdout (code=exited, status=0/SUCCESS)
Main PID: 1333538 (radiusd)
Tasks: 1 (limit: 115696)
Memory: 5.7M
CGroup: /system.slice/radiusd.service
└─[0;38;5;245m 1333538 /usr/sbin/radiusd -d /etc/raddb -f -X -l /var/log/radius/radius.log
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: lifetime = 0
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: idle_timeout = 30
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: }
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: }
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: listen {
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: type = "auth"
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: ipaddr = 127.0.0.1
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: port = 18120
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: }
Dec 02 15:26:38 fortinac radiusd[1333536]: Mon Dec 2 15:26:38 2024 : Debug: Configuration appears to be OK
SERVICE LOGS:
Listening on auth address * port 1645
Listening on auth address :: port 1645
Listening on auth address 127.0.0.1 port 18120
Ready to process requests
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
BlastRADIUS check: Received packet without Message-Authenticator.
Setting "require_message_authenticator = false" for client localhost
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
UPGRADE THE CLIENT AS YOUR NETWORK IS VULNERABLE TO THE BLASTRADIUS ATTACK.
Once the client is upgraded, set "require_message_authenticator = true" for client localhost
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
BlastRADIUS check: Received packet without Proxy-State.
Setting "limit_proxy_state = true" for client localhost
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The packet does not contain Message-Authenticator, which is a security issue.
UPGRADE THE CLIENT AS YOUR NETWORK MAY BE VULNERABLE TO THE BLASTRADIUS ATTACK.
Once the client is upgraded, set "require_message_authenticator = true" for client localhost
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(0) Received Access-Request Id 135 from 127.0.0.1:50599 to 127.0.0.1:1645 length 87
(0) User-Name = "nonExistUser"
(0) CHAP-Password = 0x83675f7933fd6842e01c601c066441e826
(0) CHAP-Challenge = 0xcf9ecff242be84157c118b13cb06e6e9
(0) NAS-Identifier = "fortinac"
(0) NAS-IP-Address = 172.16.180.104
(0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(0) Failed to authenticate the user
(0) Using Post-Auth-Type Reject
(0) Post-Auth-Type sub-section not found. Ignoring.
(0) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [nonExistUser] (from client localhost port 0)
(0) Delaying response for 1.000000 seconds
Waking up in 0.3 seconds.
Waking up in 0.6 seconds.
(0) Sending delayed response
(0) Sent Access-Reject Id 135 from 127.0.0.1:1645 to 127.0.0.1:50599 length 38
Waking up in 3.9 seconds.
(0) Cleaning up request packet ID 135 with timestamp +5 due to cleanup_delay was reached
Ready to process requests
It's like it doesn't accept its own requests..
There are no service logs related to the MAC address clients..
Which of the two commands is correct for the Cisco switch: proxy ports or FortiNAC default ports?
radius-server host 172.16.180.104 auth-port 1645 acct-port 1646 key 7 encryptedpassword
radius-server host 172.16.180.104 auth-port 1812 acct-port 1813 key
FortiNAC is currently listening to 1645 as per your configuration:
SERVICE LOGS:
Listening on auth address * port 1645
Listening on auth address :: port 1645
So you should be using 1645 as auth port in your Switch configuration.
The problem in this case is that the Switch is not sending an Radius Access-Request at all.
That radius access request with "User-Name = "nonExistUser"" is the test request sent when the Switch tries to validate if it can reach the radius server. That part seems ok.
Now you need to check if the switch is actually sending the Access Request for your supplicant at the correct IP and port. At the moment FortiNAC is ready to process requests but has not yet received anything.
Enable a tcpdump or packet capture in the Switch itself. It should confirm where are the Radius requests going if any.
Since there is no trace of authentication request coming for the interface, make sure that you have also enabled dot1x globally in the switch configuration:
dot1x system-auth-control
Verify also that the 'Wired AutoConfig' service is running and the supplicant is properly configured in the end host, technically the switch will just proxy this EAPoL requests.
Good morning, I managed to get a test switch on which I can operate autonomously.
Here is the complete configuration I applied to the switch:
aaa new-model
!
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
!
aaa nas port extended
!
dot1x system-auth-control
!
interface GigabitEthernet1/0/1
switchport access vlan 201
switchport mode access
switchport voice vlan 150
authentication host-mode single-host
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication timer reauthenticate 180
snmp trap mac-notification change added
snmp trap mac-notification change removed
dot1x pae authenticator
dot1x timeout quiet-period 3
dot1x timeout server-timeout 10
dot1x timeout tx-period 5
dot1x timeout supp-timeout 6
auto qos trust
macro description cisco-desktop
spanning-tree bpduguard enable
service-policy input AutoQos-4.0-Trust-Cos-Input-Policy
service-policy output AutoQos-4.0-Output-Policy
!
radius-server host 172.16.180.104 auth-port 1645 acct-port 1646 key password
When running some debugging on the switch, I see:
A-TEST#show authentication sessions
Interface MAC Address Method Domain Status Fg Session ID
Gi1/0/1 d45d.646c.d656 N/A DATA Unauth AC1B016200000FCA09C1ABAC
AA-TEST#terminal monitor
AA-TEST#debug dot1x all
All Dot1x debugging is on
AA-TEST#
Dec 5 11:08:34.683: dot1x-ev:[Gi1/0/1] Interface state changed to UP
Dec 5 11:08:34.924: dot1x_auth Gi1/0/1: initial state auth_initialize has enter
Dec 5 11:08:34.924: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: initialising
Dec 5 11:08:34.924: dot1x_auth Gi1/0/1: during state auth_initialize, got event 0(cfg_auto)
Dec 5 11:08:34.924: @@@ dot1x_auth Gi1/0/1: auth_initialize -> auth_disconnected
Dec 5 11:08:34.924: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: disconnected
Dec 5 11:08:34.925: dot1x_auth Gi1/0/1: idle during state auth_disconnected
Dec 5 11:08:34.925: @@@ dot1x_auth Gi1/0/1: auth_disconnected -> auth_restart
Dec 5 11:08:34.925: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: entering restart
Dec 5 11:08:34.925: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Sending create new context event to EAP for 0x18000019 (d45d.646c.d656)
Dec 5 11:08:34.925: dot1x_auth_bend Gi1/0/1: initial state auth_bend_initialize has enter
Dec 5 11:08:34.925: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: entering init state
Dec 5 11:08:34.925: dot1x_auth_bend Gi1/0/1: initial state auth_bend_initialize has idle
Dec 5 11:08:34.925: dot1x_auth_bend Gi1/0/1: during state auth_bend_initialize, got event 16383(idle)
Dec 5 11:08:34.925: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_initialize -> auth_bend_idle
Dec 5 11:08:34.925: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering idle state
Dec 5 11:08:34.925: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Created a client entry (0x18000019)
Dec 5 11:08:34.925: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Dot1x authentication started for 0x18000019 (d45d.646c.d656)
Dec 5 11:08:34.926: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting !EAP_RESTART on Client 0x18000019
Dec 5 11:08:34.926: dot1x_auth Gi1/0/1: during state auth_restart, got event 6(no_eapRestart)
Dec 5 11:08:34.926: @@@ dot1x_auth Gi1/0/1: auth_restart -> auth_connecting
Dec 5 11:08:34.926: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:enter connecting state
Dec 5 11:08:34.926: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: restart connecting
Dec 5 11:08:34.926: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting RX_REQ on Client 0x18000019
Dec 5 11:08:34.926: dot1x_auth Gi1/0/1: during state auth_connecting, got event 10(eapReq_no_reAuthMax)
Dec 5 11:08:34.926: @@@ dot1x_auth Gi1/0/1: auth_connecting -> auth_authenticating
Dec 5 11:08:34.926: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: authenticating state entered
Dec 5 11:08:34.927: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:connecting authenticating action
Dec 5 11:08:34.927: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting AUTH_START for 0x18000019
Dec 5 11:08:34.927: dot1x_auth_bend Gi1/0/1: during state auth_bend_idle, got event 4(eapReq_authStart)
Dec 5 11:08:34.927: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_idle -> auth_bend_request
Dec 5 11:08:34.927: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering request state
Dec 5 11:08:34.927: dot1x-ev:[Gi1/0/1] Sending EAPOL packet to group PAE address
Dec 5 11:08:34.927: dot1x-registry:registry:dot1x_ether_macaddr called
Dec 5 11:08:34.927: dot1x-ev:[Gi1/0/1] Sending out EAPOL packet
Dec 5 11:08:34.927: dot1x-packet:EAPOL pak Tx - Ver: 0x3 type: 0x0
Dec 5 11:08:34.927: dot1x-packet: length: 0x0005
Dec 5 11:08:34.927: dot1x-packet:EAP code: 0x1 id: 0x1 length: 0x0005
Dec 5 11:08:34.927: dot1x-packet: type: 0x1
Dec 5 11:08:34.927: dot1x-packet:[d45d.646c.d656, Gi1/0/1] EAPOL packet sent to client 0x18000019
Dec 5 11:08:34.928: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:idle request action
Dec 5 11:08:35.021: dot1x-packet:[d45d.646c.d656, Gi1/0/1] queuing an EAPOL pkt on Auth Q
Dec 5 11:08:35.022: dot1x-packet:EAPOL pak rx - Ver: 0x1 type: 0x1
Dec 5 11:08:35.022: dot1x-packet: length: 0x0000
Dec 5 11:08:35.022: dot1x-ev:[Gi1/0/1] Dequeued pkt: Int Gi1/0/1 CODE= 0,TYPE= 0,LEN= 0
Dec 5 11:08:35.022: dot1x-ev:[Gi1/0/1] Received pkt saddr =d45d.646c.d656 , daddr = 0180.c200.0003, pae-ether-type = 888e.0101.0000
Dec 5 11:08:35.022: dot1x-packet:[d45d.646c.d656, Gi1/0/1] Received an EAPOL-Start packet
Dec 5 11:08:35.022: dot1x-packet:EAPOL pak rx - Ver: 0x1 type: 0x1
Dec 5 11:08:35.022: dot1x-packet: length: 0x0000
Dec 5 11:08:35.022: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting EAPOL_START on Client 0x18000019
Dec 5 11:08:35.022: dot1x_auth Gi1/0/1: during state auth_authenticating, got event 4(eapolStart)
Dec 5 11:08:35.022: @@@ dot1x_auth Gi1/0/1: auth_authenticating -> auth_aborting
Dec 5 11:08:35.022: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:exiting authenticating state
Dec 5 11:08:35.022: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: entering aborting state
Dec 5 11:08:35.023: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting AUTH_ABORT for 0x18000019
Dec 5 11:08:35.023: dot1x_auth_bend Gi1/0/1: during state auth_bend_request, got event 1(authAbort)
Dec 5 11:08:35.023: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_request -> auth_bend_initialize
Dec 5 11:08:35.023: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: entering init state
Dec 5 11:08:35.023: dot1x_auth_bend Gi1/0/1: idle during state auth_bend_initialize
Dec 5 11:08:35.023: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_initialize -> auth_bend_idle
Dec 5 11:08:35.023: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering idle state
Dec 5 11:08:35.023: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting !AUTH_ABORT on Client 0x18000019
Dec 5 11:08:35.023: dot1x_auth Gi1/0/1: during state auth_aborting, got event 20(no_eapolLogoff_no_authAbort)
Dec 5 11:08:35.023: @@@ dot1x_auth Gi1/0/1: auth_aborting -> auth_restart
Dec 5 11:08:35.024: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:exiting aborting state
Dec 5 11:08:35.024: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: entering restart
Dec 5 11:08:35.024: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Resetting the client 0x18000019
Dec 5 11:08:35.024: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Sending create new context event to EAP for 0x18000019 (d45d.646c.d656)
Dec 5 11:08:35.024: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:restart action for aborting state
Dec 5 11:08:35.024: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting !EAP_RESTART on Client 0x18000019
Dec 5 11:08:35.024: dot1x_auth Gi1/0/1: during state auth_restart, got event 6(no_eapRestart)
Dec 5 11:08:35.024: @@@ dot1x_auth Gi1/0/1: auth_restart -> auth_connecting
Dec 5 11:08:35.024: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:enter connecting state
Dec 5 11:08:35.024: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: restart connecting
Dec 5 11:08:35.025: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting RX_REQ on Client 0x18000019
Dec 5 11:08:35.025: dot1x_auth Gi1/0/1: during state auth_connecting, got event 10(eapReq_no_reAuthMax)
Dec 5 11:08:35.025: @@@ dot1x_auth Gi1/0/1: auth_connecting -> auth_authenticating
Dec 5 11:08:35.025: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019: authenticating state entered
Dec 5 11:08:35.025: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:connecting authenticating action
Dec 5 11:08:35.025: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting AUTH_START for 0x18000019
Dec 5 11:08:35.025: dot1x_auth_bend Gi1/0/1: during state auth_bend_idle, got event 4(eapReq_authStart)
Dec 5 11:08:35.025: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_idle -> auth_bend_request
Dec 5 11:08:35.025: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering request state
Dec 5 11:08:35.025: dot1x-ev:[Gi1/0/1] Sending EAPOL packet to group PAE address
Dec 5 11:08:35.025: dot1x-registry:registry:dot1x_ether_macaddr called
Dec 5 11:08:35.025: dot1x-ev:[Gi1/0/1] Sending out EAPOL packet
Dec 5 11:08:35.025: dot1x-packet:EAPOL pak Tx - Ver: 0x3 type: 0x0
Dec 5 11:08:35.025: dot1x-packet: length: 0x0005
Dec 5 11:08:35.026: dot1x-packet:EAP code: 0x1 id: 0x1 length: 0x0005
Dec 5 11:08:35.026: dot1x-packet: type: 0x1
Dec 5 11:08:35.026: dot1x-packet:[d45d.646c.d656, Gi1/0/1] EAPOL packet sent to client 0x18000019
Dec 5 11:08:35.026: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:idle request action
Dec 5 11:08:35.046: dot1x-packet:[d45d.646c.d656, Gi1/0/1] Queuing an EAPOL pkt on Authenticator Q
Dec 5 11:08:35.047: dot1x-packet:EAPOL pak rx - Ver: 0x1 type: 0x0
Dec 5 11:08:35.047: dot1x-packet: length: 0x001E
Dec 5 11:08:35.047: dot1x-ev:[Gi1/0/1] Dequeued pkt: Int Gi1/0/1 CODE= 2,TYPE= 1,LEN= 30
Dec 5 11:08:35.047: dot1x-ev:[Gi1/0/1] Received pkt saddr =d45d.646c.d656 , daddr = 0180.c200.0003, pae-ether-type = 888e.0100.001e
Dec 5 11:08:35.047: dot1x-packet:EAPOL pak rx - Ver: 0x1 type: 0x0
Dec 5 11:08:35.047: dot1x-packet: length: 0x001E
Dec 5 11:08:35.047: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting EAPOL_EAP for 0x18000019
Dec 5 11:08:35.047: dot1x_auth_bend Gi1/0/1: during state auth_bend_request, got event 6(eapolEap)
Dec 5 11:08:35.047: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_request -> auth_bend_response
Dec 5 11:08:35.047: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering response state
Dec 5 11:08:35.047: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Response sent to the server from 0x18000019
Dec 5 11:08:35.047: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:request response action
Dec 5 11:08:36.675: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up
Dec 5 11:08:37.673: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
Dec 5 11:08:45.044: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting A_WHILE_EXPIRE on 0x18000019
Dec 5 11:08:45.044: dot1x_auth_bend Gi1/0/1: during state auth_bend_response, got event 9(aWhile_expire)
Dec 5 11:08:45.044: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_response -> auth_bend_timeout
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:exiting response state
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering timeout state
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:response timeout action
Dec 5 11:08:45.045: dot1x_auth_bend Gi1/0/1: idle during state auth_bend_timeout
Dec 5 11:08:45.045: @@@ dot1x_auth_bend Gi1/0/1: auth_bend_timeout -> auth_bend_idle
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering idle state
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] Posting AUTH_TIMEOUT on Client 0x18000019
Dec 5 11:08:45.045: dot1x_auth Gi1/0/1: during state auth_authenticating, got event 14(authTimeout)
Dec 5 11:08:45.045: @@@ dot1x_auth Gi1/0/1: auth_authenticating -> auth_authc_result
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:exiting authenticating state
Dec 5 11:08:45.045: dot1x-sm:[d45d.646c.d656, Gi1/0/1] 0x18000019:entering authc result state
Dec 5 11:08:45.045: %DOT1X-5-FAIL: Authentication failed for client (d45d.646c.d656) on Interface Gi1/0/1 AuditSessionID AC1B016200000FD409DFEA04
Dec 5 11:08:45.046: dot1x-packet:[d45d.646c.d656, Gi1/0/1] Added username in dot1x
Dec 5 11:08:45.046: dot1x-packet:[d45d.646c.d656, Gi1/0/1] Dot1x did not receive any key data
Dec 5 11:08:45.046: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Processing client delete for hdl 0x18000019 sent by Auth Mgr
Dec 5 11:08:45.046: dot1x-ev:[d45d.646c.d656, Gi1/0/1] d45d.646c.d656: sending canned failure due to method termination
Dec 5 11:08:45.046: dot1x-ev:[Gi1/0/1] Sending EAPOL packet to group PAE address
Dec 5 11:08:45.047: dot1x-registry:registry:dot1x_ether_macaddr called
Dec 5 11:08:45.047: dot1x-ev:[Gi1/0/1] Sending out EAPOL packet
Dec 5 11:08:45.047: dot1x-packet:EAPOL pak Tx - Ver: 0x3 type: 0x0
Dec 5 11:08:45.047: dot1x-packet: length: 0x0004
Dec 5 11:08:45.047: dot1x-packet:EAP code: 0x4 id: 0x1 length: 0x0004
Dec 5 11:08:45.047: dot1x-packet:[d45d.646c.d656, Gi1/0/1] EAPOL canned status packet sent to client 0x18000019
Dec 5 11:08:45.047: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Deleting client 0x18000019 (d45d.646c.d656)
Dec 5 11:08:45.048: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Delete auth client (0x18000019) message
Dec 5 11:08:45.048: dot1x-ev:Auth client ctx destroyed
On the FortiNAC side, I’m not receiving anything meaningful:
Ready to process requests
(34) Received Access-Request Id 171 from 127.0.0.1:42291 to 127.0.0.1:1645 length 87
(34) User-Name = "nonExistUser"
(34) CHAP-Password = 0xf8e8a743f3129985d4669b900c7caad52d
(34) CHAP-Challenge = 0x9cb50f404c7e4d878f620269977e3bd4
(34) NAS-Identifier = "fortinac"
(34) NAS-IP-Address = 172.16.180.104
(34) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(34) Failed to authenticate the user
(34) Using Post-Auth-Type Reject
(34) Post-Auth-Type sub-section not found. Ignoring.
(34) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [nonExistUser] (from client localhost port 0)
(34) Delaying response for 1.000000 seconds
Waking up in 0.3 seconds.
Waking up in 0.6 seconds.
(34) Sending delayed response
(34) Sent Access-Reject Id 171 from 127.0.0.1:1645 to 127.0.0.1:42291 length 38
Waking up in 3.9 seconds.
(34) Cleaning up request packet ID 171 with timestamp +1090 due to cleanup_delay was reached
Ready to process requests
Let me know if you spot anything missing or misconfigured!
Following debugs could be an indication of the problem:
Dec 5 11:08:45.046: dot1x-packet:[d45d.646c.d656, Gi1/0/1] Added username in dot1x
Dec 5 11:08:45.046: dot1x-packet:[d45d.646c.d656, Gi1/0/1] Dot1x did not receive any key data
Dec 5 11:08:45.046: dot1x-ev:[d45d.646c.d656, Gi1/0/1] Processing client delete for hdl 0x18000019 sent by Auth Mgr
Dec 5 11:08:45.046: dot1x-ev:[d45d.646c.d656, Gi1/0/1] d45d.646c.d656: sending canned failure due to method termination
Since you are using 802.1x, how is the supplicant configured? Which EAP-Method is in place? Is that EAP-Method also enabled in the RADIUS configuration in FortiNAC?
Check this doc for an example of Supplicant Configuration with Mschapv2. This requires FortiNAC to be domain joind to your AD and have winbind enabled.
This article can help with this: https://community.fortinet.com/t5/FortiNAC/Technical-Tip-MSCHAPv2-authentication-join-FortiNAC-in-do...
Created on 12-05-2024 03:59 AM Edited on 12-05-2024 03:59 AM
FortiNAC is already domain-joined:
fortinac:~$ wbinfo -a DOMAIN\\user
plaintext password authentication succeeded
On the FortiNAC side, I have enabled all EAP types except FAST and allowed the Winbind domain.
On the client side, I configured Microsoft PEAP (Protected EAP) with user authentication, replacing the credentials with the format user@domain.com.
I removed the server identity verification using a certificate.
The authentication method is EAP-MSCHAP v2.
Could this be an issue with outdated algorithms? The switch is old:
Model SW Version
----- ----------
WS-C3650-24PS 03.06.06E
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1733 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.