ROS IPsec configures radius authentication, set it according to MikroTik 2019 MUM expert’s tutorial, Radius Server I am using Windows Server 2016 NPS, during the authentication process, the certificate authentication is passed, the account authentication can not be passed, I do not know why, and then the Radius Server Change to TekRADIUS, still the same result.
I asked for technical support and got a reply :
Emīls Z.29/Apr/21 8:08 AM
Hello,
We suspect it is an issue with the RADIUS server that includes the EAP MSK message in Access-Accept message which should not be there.
Jan/24/2021 18:59:46 received Access-Accept with id 10 from 172.18.168.8:1812
Jan/24/2021 18:59:46 Signature = 0x09251f87403d76208c62a457ac3a9b2c
Jan/24/2021 18:59:46 User-Name = “itest1”
Jan/24/2021 18:59:46 EAP-Message = 0x03030004
Jan/24/2021 18:59:46 Message-Authenticator = 0x882193fa948795e83d227c95221fcbcd
Jan/24/2021 18:59:46 received reply for 55:0b
Jan/24/2021 18:59:46 => EAP MSK (size 0x0)"
For more screenshots of related questions, please search for the post with the same title in the Microsoft Q&A community.
Since Emīls has declared a clear suspicion regarding the root cause, my first step would be to verify that suspicion.
First, sniff the packet exchange between Mikrotik and the Radius server, and check (using Wireshark) that the MSK information element is actually present in the Access-Accept message the RADIUS server sends, i.e. that it is not an error of RouterOS parsing of the message. If it does, check whether it is the same case while using TekRADIUS instead of the WS2016 NPS.
Since you don’t obfuscate any identifiers (MAC addresses, IP addresses), posting the .pcap files would have been more useful than posting an incomplete set of screenshots.
In the analysis of Emīls, there is an Access-Accept message, whereas on your screenshots from both the TekRADIUS and the NPS, there are only Access-Reject messages.
How is that possible? Can you restore the settings you’ve used when generating the supout.rif you’ve sent to support so that we could compare apples to apples?
Since it is an open forum, please provide your personal email address, and I will provide the login information for the test router to facilitate your analysis of the fault.
It’s a forum, and I’m a fellow user, not a member of Mikrotik support staff. So I can give you advice, and I can analyse the data you collect, but I have enough else to do, so I won’t spend my time by the routine of data collection.
I’ve only tried to turn your attention to the fact that there is a severe mismatch between what your screenshots shows and what Emīls’ analysis shows.
Wireshark tells you exactly what has happened, but it rarely tells you why it has happened - to find out the why, you need logs from both sides (and the developers must have made the logs’ contents useful of course).
Although the IKEv2 negotiation fails in both cases, there is a big difference between getting an Access-Reject from the RADIUS and getting an Access-Accept but with an AVP that should not be there. Access-Reject may indicate a mere typo in password; if you can get an Access-Accept from the TekRADIUS, there is a good chance that it won’t contain the MSK AVP (which actually seems to me to be some misinterpretation, because not only that it is present in the message where it should not be, but on top of it it has a zero length).
So ideally you’d have the RouterOS log and Wireshark capture from the very same attempt, to compare them and see whether the zero-length MSK AVP was actually there or whether the RADIUS packet was malformed in some other way.
ROS cooperated with Windows Server 2016 NPs authentication, no access accept message was found in packet capture, only access reject message;ROS cooperates with TekRADIUS authentication, and Access Accept messages are found in the packet capture.
OK. So could it be that you’ve sent to support only the supout.rif from the TekRADIUS case?
To conclude whether the MSK AVP is really present in the packet or it is a parsing error at RouterOS side, I need the .pcap file or a hexdump of the frame carrying the Access-Accept - right click the row in the packet list and choose Copy > …as Hex Dump, then paste the output here between [code] and [/code] tags. And before taking the capture, start also the logging of radius exchange on the Mikrotik, so that the capture and the log contain the very same packet.
Regarding the NPS, it seems to be a completely separate issue. Since the setup at Mikrotik side is sufficient to get an Access-Accept from the TekRADIUS, it is probably correct, so look again what may be wrong in the NPS configuration.
I’ve told you exactly how to get a hex dump of the packet data from Wireshark and you’ve nevertheless posted a screenshot
Also the log can be obtained in text form, which is much more useful for analysis:
run /log print follow-only file=some-name
do the action that needs to be logged
press Ctrl-C to stop the command above
download some-name.txt
Nevertheless - there is no such information element as EAP-MSK anywhere in the Access-Accept message (I’ve copy-typed the packet hex dump from your screenshot to a text file manually); on top of that, the log message => EAP MSK (size 0x0) has not been written by the radius stack but by the ipsec one. I was wondering all the time why an information element should be defined for transport of EAP MSK, given that EAP MSK is the shared secret that should never be sent across the network; this clarifies that a bit. So it rather seems that in the previous EAP messages, there is not enough information from which RouterOS could cryptographically derive the EAP-MSK, and hence it shows a zero length, or there is a bug in RouterOS and the handover of the information from the RADIUS layer and the IPsec layer has failed.
I’m no security protocol expert, so at this point I can only recommend you to repeat the test while sniffing, create a new supout.rif, attach it together with the .pcap (not a screenshot of a single packet) to the support ticket and ask Mikrotik (Emīls) to have another look. And maybe add a link to this post.
Before Mikrotik responds, you may want to investigate the logs at Microsoft side to see why the NPS doesn’t return Access-Accept.
Sorry, I did not find the option you mentioned on the Wireshark software interface. I apologize for the inconvenience caused. Thank you for your patience.
Here, Offset Hex is the right choice (or Offset Hex Text, but it has no advantage for this purpose). What makes you use such an old release of Wireshark, the operating system is too old to be supported by contemporary Wireshark releases?
