Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Upgrade to 2.4.5 broke 802.1x RADIUS WiFi over VPN

    Scheduled Pinned Locked Moved General pfSense Questions
    39 Posts 6 Posters 5.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      It's probably this you're hitting: https://redmine.pfsense.org/issues/7779

      You could confirm it by checking the packet size and if they are fragmented in a packet capture.

      If you are using RADIUS with UDP this is more likely to be an issue. If it's using TLS, and therefore TCP, I expect it to detect the route MTU and use packets that do not fragment. If it is not doing so you should investigate that.

      Steve

      W 1 Reply Last reply Reply Quote 0
      • W
        wdup @stephenw10
        last edited by

        @stephenw10 Thank you for the reply.

        If I may ask the question differently, is there any harm in assigning ALL OpenVPN interfaces?

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • O
            ogghi
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              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

              O 1 Reply Last reply Reply Quote 1
              • O
                ogghi @stephenw10
                last edited by

                @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...

                stephenw10S 1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator @ogghi
                  last edited by

                  @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

                  O 1 Reply Last reply Reply Quote 0
                  • O
                    ogghi @stephenw10
                    last edited by

                    @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...

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      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

                      O 1 Reply Last reply Reply Quote 1
                      • O
                        ogghi @stephenw10
                        last edited by

                        @stephenw10 Just did some package capture. On the ADC on the other tunnel side:
                        837c7862-db80-4888-bf86-867e549a13f8-image.png

                        On the one where it's working:
                        831b8a45-50a8-44bd-b379-16dfdd7a6edf-image.png

                        I am wondering why the length seems to be capped at 190 bytes for the one going through the tunnel...?

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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

                          O 1 Reply Last reply Reply Quote 1
                          • O
                            ogghi @stephenw10
                            last edited by ogghi

                            @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?

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              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

                              O 1 Reply Last reply Reply Quote 1
                              • O
                                ogghi @stephenw10
                                last edited by

                                @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...

                                O 1 Reply Last reply Reply Quote 0
                                • O
                                  ogghi @ogghi
                                  last edited by

                                  @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..

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.