Upgrade to 2.4.5 broke 802.1x RADIUS WiFi over VPN
-
Not really. You will need to restart any OpenVPN servers after assigning them as an interface though.
Also to actually make use of it make sure traffic is passed on the assigned interface firewall rules and not the 'OpenVPN' rules.
Steve
-
Hi there, I am running 2.5.1 on 2 sites, with a site2site openvpn.
I would like to get radius to work in both directions in order to have fall-back NPS for Wifi.
Right now there is a rule in the openvpn interface which allows all.
There is also one for opt3 which is not handling any traffic though.
Would it be enough to disable the rule in openvpn if to get the traffic handled by the opt3 if?
I would need to do that on both sites I guess, to have it working in both directions? -
Yes, if you disable a rule on the group OpenVPN interface traffic will hit rules on the assigned interfaces and get the required reply-to tags.
Steve
-
@stephenw10 Hey there, I was brave and tested to change those settings from remote :)
Nothing broke. Traffic is being handled by the interface specific rule now.
But still I don't get any request on the RADIUS server on the other tunnel end. Always bad UDP checksum... -
@ogghi said in Upgrade to 2.4.5 broke 802.1x RADIUS WiFi over VPN:
Always bad UDP checksum...
In a packet capture?
That's expected if you have checksum offloading enabled on the capture interface.You're not seeing the radius traffic arrive at the server at all?
Steve
-
@stephenw10 nothing arrives on the radius server from over the vpn connection.
That's the weird thing. At least nothing is logged in the windows service... -
Hmm, well I'd pcap on the server to be sure. I'd also pcap at each interface in the route to see where it's failing.
We have seen issues with large UDP packets not fragmenting correctly across the tunnel. You would see that in a pcap if you are hitting that or something similar.Steve
-
@stephenw10 Just did some package capture. On the ADC on the other tunnel side:
On the one where it's working:
I am wondering why the length seems to be capped at 190 bytes for the one going through the tunnel...?
-
190B may just be the size of that request.
Where, specifically did you capture there?
I would check on the OpenVPN and internal interfaces at both ends if the tunnel. The traffic should appear in all 4 places but since something is failing it may not. You need to determine where it's failing.
Steve
-
@stephenw10 thanks for your help! :)
So I did capture traffic. Seems there is just no reply from the RADIUS server. Traffic gets to the server, but there is never any packet being sent back.
So it seems like debugging this windows NAPS is due here!EDIT: Seems it must be some issue on Windows firewall? The NPS server logs nothing at all. If running locally NTradping tool it shows at least some log entries. But other then opening port 1812 UDP on the firewall...what else could I do here?
-
Does it log something if there is a bad request? Incorrect shared secret for example.
You might be able to see some difference in the radius requests that fail wireshark. They are smaller packets as you noted.
I don't think that's a problem in the pfSense config though if traffic arrives at the server and looks the same as when it arrives in the remote firewall.
Steve
-
@stephenw10 Hi there!
I just checked again the radius config for the auth servers in the pfSense. Actually I reconfigured it. Now the packet sizes are identical.
I get the bad UDP checksum also for the radius on the ADC without VPN where it's working.
So my current thought is that there might be an issue with the NPS itself. I'll try to uninstall/reinstall the role there. Who knows... -
@ogghi I think I'll try and debug on the windows server/NPS side. The packets arrive at the windows server as seen on Wireshark. But nothing is ever logged on NPS. So it might be some really stupid bug here..
