Hi @marfr 

Thanks for posting in our business forum.

Do you have any RADIUS config on the switch?

Hi @Clive_A

thanks for the response.

I exported the configuration and trimmed everything not related to 802.1x

This is what remains:

!SG3452XP
#
dot1x system-auth-control
no dot1x handshake
dot1x vlan-assignment
#
radius-server host <NPS-RADIUS-IP> auth-port 1812 acct-port 1813 timeout 9 retransmit 3 nas-id "<identifier>" key 0 <Radius Secret>

interface gigabitEthernet 1/0/3
  switchport general allowed vlan <unauthenticatedVLAN-ID> untagged
  no switchport general allowed vlan 1
  dot1x
  dot1x port-method port-based
  dot1x max-req 9
  dot1x timeout quiet-period 1
  dot1x timeout supp-timeout 9
  
  no lldp tlv-select management-address
  no lldp tlv-select link-aggregation
  loopback-detection config process-mode vlan-based recovery-mode auto
  loopback-detection

end
 

I hope this helps.

Best regards

Hi @marfr 

Thanks for posting in our business forum.

marfr wrote

Hi @Clive_A

 

thanks for the response.

 

I exported the configuration and trimmed everything not related to 802.1x

 

This is what remains:

 

!SG3452XP
#
dot1x system-auth-control
no dot1x handshake
dot1x vlan-assignment
#
radius-server host <NPS-RADIUS-IP> auth-port 1812 acct-port 1813 timeout 9 retransmit 3 nas-id "<identifier>" key 0 <Radius Secret>

interface gigabitEthernet 1/0/3
  switchport general allowed vlan <unauthenticatedVLAN-ID> untagged
  no switchport general allowed vlan 1
  dot1x
  dot1x port-method port-based
  dot1x max-req 9
  dot1x timeout quiet-period 1
  dot1x timeout supp-timeout 9
  
  no lldp tlv-select management-address
  no lldp tlv-select link-aggregation
  loopback-detection config process-mode vlan-based recovery-mode auto
  loopback-detection

end
 

 

I hope this helps.

 

Best regards

This looks legit. Just seems to be the client did not reply, instead of the router failing to forward. 

Do you have a diagram with the IP marked out? And your switch and RADIUS server IP.

  Hi @Clive_A,

The diagramm would be extremely simple. The switch is currently at my desk for evaluation before buying more of the omada line. It has one port as an uplink to the rest of the network and one port where I connect my notebook to test 802.1X. Switch and Radius servers are part of Class-B RFC 1918 Addresses. So there's no conflict potential with anyting externally. The Radius server is just one hop away, different subnet/vlan but same location.

From the packet capture it seems that the communication betwen switch and NPS/Radius is working.

The missing reply you mentioned is because the switch never forwarded the challenge from the radius server to the client. Packet 16 from the capture is exactly that challenge. And this challenge should be forwarded to the client so that it can process it and send back the response. But there is no packet from "TpLinkPte_ab:..." to "Client MAC". The content of packet 16 data is nothing too usefull for debugging because it's already part of the TLS session (packet 10 is the tls start request and packet 11 is the TLS Client Hello from the client)

Best regards

Hi @marfr 

Thanks for posting in our business forum.

marfr wrote

  Hi @Clive_A,

 

The diagramm would be extremely simple. The switch is currently at my desk for evaluation before buying more of the omada line. It has one port as an uplink to the rest of the network and one port where I connect my notebook to test 802.1X. Switch and Radius servers are part of Class-B RFC 1918 Addresses. So there's no conflict potential with anyting externally. The Radius server is just one hop away, different subnet/vlan but same location.

 

From the packet capture it seems that the communication betwen switch and NPS/Radius is working.

 

The missing reply you mentioned is because the switch never forwarded the challenge from the radius server to the client. Packet 16 from the capture is exactly that challenge. And this challenge should be forwarded to the client so that it can process it and send back the response. But there is no packet from "TpLinkPte_ab:..." to "Client MAC". The content of packet 16 data is nothing too usefull for debugging because it's already part of the TLS session (packet 10 is the tls start request and packet 11 is the TLS Client Hello from the client)

 

Best regards

 

I think a diagram with IP VLAN specified would still be helpful. Just want to make sure that we are on the right track and rule out the config issue. So far, they look good but just the diagram is unknown.

I have informed the team regarding this.

Hi  @Clive_A ,

sorry for the delay:

The network configuration looks like the following diagramm:

The SG3452XP can open up a connection to the RADIUS Server via the existing Switch as seen in the wireshark capture. So I suspect that it's not a lower level issue between the RADIUS Server and the Switch.

Best regards

Hi  @Clive_A ,

do you need any further information to check this issue?

Has "the team" you mentioned said anything about this?

Thanks in advance and best regards.

  @marfr 

marfr wrote

Hi  @Clive_A ,

 

do you need any further information to check this issue?

Has "the team" you mentioned said anything about this?

 

Thanks in advance and best regards.

 

No.

There is a new firmware out for this model.

Upgrade to it and check if there is a difference. Note has mentioned RADIUS fixes. 

Hi  @Clive_A,

thanks for the update. Do you have a link to the update and the release notes? Everything in the early access posts was not for the SG3452XP and the official firmware download page doesn't list a new firmware in comparison to the one already on the switch.

Thanks and best regards

Hi @Clive_A ,

could you please post a link to the firmware you mentioned.

Everywhere I searched, I only found the version that's already on the device or firmware for other devices and this doesn't help me.

The switch is still sitting on my desk for evaluation and was turned off for the last weeks. We can't progress further without the fix for this issue.

Best regards