Mobile VPN - some users work, some doesn't


When creating new users in our M470 they are able to connect to the VPN, but they are not "authenticated", rather they get blocked by the firewall (Unhandled External Packet).

When checking the documentation online this scenario is described and referred to as issues with users not being members in the SSLVPN group or this group/policy for the group not being correctly configured.

  • The group SSLVPN-Users is created
  • An old user (say henrik) is member of this group
  • A new user is created, testaccount, also member of the group
  • Both henriks and testaccounts credentials can be used to connect to the VPN, and both are accepted and receives an internal IP
  • Only henriks connection shows up under "authentication list" (WebUI -> System Status -> Authentication List)
  • All traffic from testaccount is blocked by the "Unhandled External Packet" policy
  • The henrik session works fine

If I allow the specific IP that testaccount is connected via (say in the firewall policy Allow SSLVPN-Users the session works as expected.

Anybody got some ideas on what to do to get further with this?



  • Options

    You can turn on diagnostic logging for authentication which may show something to help:
    . Policy Manager: Setup -> Logging -> Diagnostic Log Level -> Authentication
    . Web UI: System -> Diagnostic Log
    Set the slider to Information or higher

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    You can also use the tool in the WebUI under System Status -> Server Connection. Logging in the dialogue box here will attempt to bind to your authentication server (like when you log in) and display back the groups that are returned by your auth server. Make sure that the SSLVPN-Users group shows up for the new user.

    If you're using user name for authentication access instead of group, Username is different than USERNAME is different than username (they're case sensitive.) Make sure the username is entered how your user is going to type it.

    -James Carson
    WatchGuard Customer Support

  • Options
    edited February 2021

    @Bruce_Briggs - At the moment we do not have any log server set up, can I retrieve the logs from the unit itself? There is a to-do for setting up a log-server... :)

    @James_Carson - We are using the Firebox-DB for authenticating, so I can't use the System Status -> Server Connection functionality as we're not using any LDAP/AD.
    We are using case sensitive usernames (and the are entered correct).

    When authenticating via the VPN the Event-logs in the traffic monitor are a bit confusing. For some reason the authentication of one of my new colleagues is performed twice:

    2021-02-09 10:14:42 admd Authentication of Firewall user [new_colleague@Firebox-DB] from EXTERNAL_IP_1 was accepted id="1100-0004"
    2021-02-09 10:14:42 admd Authentication of Firewall user [new_colleague@Firebox-DB] from EXTERNAL_IP_1 was accepted id="1100-0004"
    2021-02-09 10:14:42 sessiond SSL VPN user new_colleague@Firebox-DB from EXTERNAL_IP_1 logged in assigned virtual IP is INTERNAL_IP_1 id="3E00-0002"

    2021-02-09 10:16:08 admd Authentication of Firewall user [henrik@Firebox-DB] from EXTERNAL_IP_2 was accepted id="1100-0004"
    2021-02-09 10:16:08 sessiond SSL VPN user henrik@Firebox-DB from EXTERNAL_IP_2 logged in assigned virtual IP is INTERNAL_IP_2 id="3E00-0002"

    After the authentication is performed I show up in the System Status -> Authentication List but my colleague doesn't.

    When confirming user/group-membership under Authentication -> Servers -> Firebox-DB we are both members of the group SSLVPN-Users. This is the only group that exists. No limits are set on "concurrent connections" or such.

    I have worked around our issues for the moment by adding the subnet our VPN users are assigned within to the automatic Firewall policy "SSLVPN-Users".

  • Options

    The firewall keeps a limited amount of log records internally.
    I use WSM Firebox System Manager -> Traffic Monitor. One can set it up to show up to 25,000 log records (right click -> Settings).
    FSM needs to be running to get the log records from the firewall.
    I keep mine open for much of the day, so I can easily see many hours worth of logs without using a log server.

  • Options

    @Bruce_Briggs Alright, so do I understand you correctly if I say that when I enable the "debug/information" level of logging for "Authentication" (as described earlier), this will also show up in the "Traffic Monitor" (either in the WebGUI or via the Firebox System Manager)?

    Thanks a lot for your tips, I'm going to check this tomorrow.

  • Options

    Yes, the debug level logs will show up in Traffic Monitor.

  • Options

    Alright, I ran some tests with higher log-levels.

    When I connect with the user "henrik" I can see this pattern (I think :) )
    1. Session connects - there is no authenticated session
    2. Some type of authentication takes place
    3. The session re-checks the authentication, which is successful and user is authenticated

    When I connect with the user "testaccount" I see a similar pattern, but step 2, the authentication, fails.

    The only difference I can find (before the "logic" diverges) is that the "testaccount" users' "authentication-flow" has the second-last row
    RqstId=0x12925 state=2 user=testaccount@Firebox-DB rslt=1, which isn't there for "henrik".

    Log from working user
    Log from non-working user

    @Bruce_Briggs - Do you have the possibility to scroll through these and see if you have any suggestsions?
    From all I understand in these logs it looks like both users should be authenticated properly.

  • Options

    Time for a support incident.
    If you have not rebooted your firewall recently, consider trying that.

    For unknown reason, it looks like userId=testaccount session gets deleted.

    Line 101: 2021-02-10 10:54:21 m470-fw2 sessiond OK! del sess succeed, sessId=19665

  • Options

    Thanks for your thoughts @Bruce_Briggs ! I'll look deeper into both contacting WG for support and rebooting the FW.

Sign In to comment.