VPN group/user list

Good afternoon,

Trying to setup the AuthPoint radius on 12.7.1. I can get the client to receive the push notifications and it appears like they connect for a second and then the traffic monitor records "Jim@AuthPoint isn't in the authorized vpn group/user list". However if I use the old radius method the user is in the right group to allow access.

What have I messed up?

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative
    edited September 2022

    @HeroldEng
    The firebox is looking for the group that the user is a part of to be in the RADIUS server's Access-accept message as attribute 11 (also known as FilterID.)

    AuthPoint will output the group the user is in -- just make sure that the same group is present in your SSLVPN configuration

    See the post below.
    The group that's in your AuthPoint config needs to be listed here so the firebox knows to look for that instead of "SSLVPN-Users"

    -James Carson
    WatchGuard Customer Support

  • james.carsonjames.carson Moderator, WatchGuard Representative

    -James Carson
    WatchGuard Customer Support

  • @james.carson
    Thank you for the response. I had previously added my MFA_Users group to the users and groups list under as Any Authentication server, but added it specifically to the AuthPoint server with the same results. I've also updated the firebox OS in case there was an issue there, now running 12.8.2

    Does it matter if I'm using IKEv2 instead of SSL?


  • james.carsonjames.carson Moderator, WatchGuard Representative

    If you're using AD via authpoint you'll need to be using NPS -- Is NPS set up to pass that group?

    -James Carson
    WatchGuard Customer Support

  • Yes sir, as mentioned using the old radius method with a GW works as expected using the same MFA_Users group name.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @HeroldEng
    You can use the TCPDUMP tool inside firebox system manager to see what's coming across.

    -In FSM, go to Tools -> Diagnostic Tasks.
    -In the network tab, choose TCP Dump from the drop down menu.
    -Check the advanced options box.
    -In the arguments box, type in "-i eth1 port 1812" without the quotes. Replace eth1 with the interface that your RADIUS server is residing on. If you're using a different port than 1812, replace that as well.

    -Click to stream the data to a file.
    -Click Start task.
    -Attempt to authenticate via the VPN and verify you get the wrong group error.
    -Click Stop task.

    -Using a tool like wireshark, open the file you created by streaming the data to it.
    -Look for a RADIUS Access-Accept message.
    If you drill down into the RADIUS attributes, you should see the group listed under attribute 11 (it'll show as AVP=11 in wireshark.)

    If you need assistance checking that, I'd suggest opening a support case and one of our support reps can help. My guess is that the group is being passed differently (it's case sensitive) or isn't being passed at all.

    -James Carson
    WatchGuard Customer Support

  • It appears that the FilterID is being passed correctly.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @HeroldEng I'm not sure why the RADIUS server is responding with 3 different attribute 11s -- it'll generally reply with one, and separate the groups with a comma or similar. The firewall will generally take whatever one it sees first.

    Does it work if you add "IKEv2-Users" and "MFA_Admin" to the list of allowed groups? (This just covers them all, if it does you can try removing them one at a time till you determine what one is being parsed.)

    -James Carson
    WatchGuard Customer Support

  • The RADIUS is responding with three likely because I have one policy on RADIUS with one windows group, and then the three filter-ids listed.

    So now for testing I have:

    • disabled all existing the VPN policies on the RADIUS server
    • created a new policy with filter-id MFA_Users
    • disabled all the authentication servers other than Authpoint
    • added IKEv2-Users, MFA_Users and MFA_Admins all to Any authentication server on the allowed group list
    • verified that attribute 11 on the TCP dump is only sending "MFA_Users"

    Still no go.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    I'd suggest creating a support case so that one of our support team can assist.

    -James Carson
    WatchGuard Customer Support

  • @HeroldEng said:
    The RADIUS is responding with three likely because I have one policy on RADIUS with one windows group, and then the three filter-ids listed.

    So now for testing I have:

    • disabled all existing the VPN policies on the RADIUS server
    • created a new policy with filter-id MFA_Users
    • disabled all the authentication servers other than Authpoint
    • added IKEv2-Users, MFA_Users and MFA_Admins all to Any authentication server on the allowed group list
    • verified that attribute 11 on the TCP dump is only sending "MFA_Users"

    Still no go.

    You have to use 1 NPS policy per AD group, then only 1 group will be returned with filter id 11.

  • Yeah WG’s documentation is missing the Filter ID step if you do the direct AuthPoint integration with IKEv2.

    I put in a support request to add this missing step as it’s caused confusion on several deployments from my teammates.
  • edited September 2022
    If you go to this document and go to 12.6 or lower for the windows sever directions it is identical to what the steps should be if you do the new AuthPoint integration. The steps you are looking for are 23-27:

    https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/AuthPoint/firebox-ikev2-vpn-radius_authpoint.html

    For some reason they are missing steps 23-27 in the “Firmware 12.7.2 or higher” part of the document which are critical to getting this working with either setup.

    (I put in a request for their team to fix this almost a month ago and even gave them screenshots to do this… I’m surprised such simple but important change to the document hasn’t been done yet as it would prevent a lot of issues)
  • > @james.carson said:
    > I'd suggest creating a support case so that one of our support team can assist.

    I put in a request for them to fix documentation on filter ID (see above comments)

    I did this a while back and it seems the documentation is still not updated... considering how the steps are very similar I am surprised it's taking so long to add a couple lines of documentation...
Sign In to comment.