NetExtender Logs In But No Access: SonicWall Local + LDAP

Login succeeds, the tunnel comes up, and nothing behind the firewall answers. That pattern on a SonicWall SSL VPN usually means the account passed authentication and stopped at one of two later grants: admission to the SSL VPN service, or permission to reach a resource. Mixed local and LDAP accounts make it worse, because the two stores reach those grants by different paths. The symptom is identical from the client, which is why the layers have to be separated deliberately.

The symptom, and the three grants behind it

Three independent decisions stand between a username and a reachable server. The authentication method decides whether the credential is accepted and by which store. The SSL VPN service membership decides whether that identity may use the SSL VPN at all. The VPN Access list decides which private destinations the session may reach. Passing one says nothing about the next two.

A user who authenticates but is not in the SSL VPN service group sees a connection that establishes and then carries nothing, and the firewall log shows an accepted login rather than a failure. That is the case worth recognising quickly, because the fix is a group membership rather than a password reset.

A user who is admitted but has no resources sees a session that connects and routes nowhere useful. Both look like a broken tunnel from the help desk, and both are configuration rather than connectivity.

The domain box is not the directory

NetExtender asks for a domain, and that field is not a search base for Active Directory. In the default arrangement the field has to equal whatever SSL VPN user domain the firewall has configured, and the documented default for that value is LocalDomain. The comparison is case-sensitive, so a value typed with different capitalisation fails even when the account is correct.

With authentication partitioning configured, the partition names select the external authentication context instead, and the configured default keeps its own role. In either arrangement the client-side domain label is not forwarded to LDAP or RADIUS as part of the username, so it cannot be used to steer a directory search.

Keep the three strings apart in your notes: the company DNS suffix, the LDAP search base and the NetExtender domain label. They look alike and none of them substitutes for another. Copy the operator's value for this installation rather than a value from a forum post about a different firmware release.

Admission and resource access are separate grants

Local accounts need membership in the SSL VPN service group before the service will accept them. Directory accounts reach the same group through the supported group-mapping workflow, which means the LDAP group relationship has to be configured and then verified as an effective membership rather than assumed from the directory side.

Resource access comes next, under VPN Access on the user or the group. Grant the specific subnets and services the role needs, and resist the shortcut of granting the whole LAN because one application is required. The session's routes, the access rules and the destination service permissions all have to agree with that scope.

A route on the client makes a destination selectable and does not authorise it. Membership in the SSL VPN group does not make the account a firewall administrator either, and it should not be treated as a general privilege grant.

Two identities, four checks each

Test with one local account and one directory account, both narrowly authorised and both documented as test accounts. For each, record the authentication source that accepted the login, the effective groups, the assigned resource access and one permitted application operation. Four checks, two stores, and a written result for each combination.

Then test the negative cases: a resource the account should not reach, and an account that should be rejected outright. A design that only proves the positive path tends to leave a second entrance open, particularly when the same short username exists in both stores. Disable the directory account and confirm the local one does not quietly keep working.

Review duplicate names as part of the rollout rather than after an incident. The same person in two stores is a support convenience and an audit problem at the same time, and the firewall will happily authenticate whichever one you configured.

Keep the recovery path narrow

Preserve the MFA policy for each account class instead of exempting local accounts from it. If local accounts provide an approved recovery path for a directory outage, restrict that path to named administrators and operate it deliberately, because a local emergency account for every employee is a second authentication system with weaker oversight.

Write the client domain, the authentication source and the effective access into the same record. The next administrator can then reproduce a working mixed-account design instead of cycling through domain strings until a login succeeds.