Skip to main content

SonicWall | Unauthorized Error

SonicWall, 401, 403, Unauthorized, Request failed with status code 401, Request failed with status code 403

Updated over a week ago

Overview πŸ’₯

If your SonicWall inspector is failing with an β€œUnauthorized” error, the Liongard Inspector cannot authenticate to the device’s REST API. This typically means the API credentials, API access settings, or the SonicOS configuration are incorrect or incompatible with the Inspector.

This article explains common root causes, step-by-step remediation, debugging commands, best practices, and what to collect for support escalation.

Typical error shown by the Inspector / logs:

HTTP 401 / 403 Unauthorized (OR)
Authentication failed for API user


Why This Happens? πŸ€”

Common Root Causes :

Category

Problem

Effect

Credentials

Wrong username/password, expired password, account locked

Immediate authentication failure β†’ Unauthorized

Password policy

Password does not meet SonicWall complexity rules

Login rejected; may cause lockout after retries

Account lockout

Too many failed logons

Account locked; API calls fail

API role/permissions

API user not assigned required role

Insufficient privileges β†’ 401/403

API access disabled or wrong interface

API access not enabled or allowed only on LAN/WAN

Inspector cannot reach API endpoint

Firmware / endpoint mismatch

SonicOS changes REST endpoints between versions (V6 vs V7)

Using wrong API path/port fails auth

MFA/2FA

API user has MFA/2FA applied

API auth invalid (interactive flows blocked)

Certificate / TLS issues

TLS handshake fails (mutual TLS, invalid certs, unsupported ciphers)

Connection fails before auth

Network / NAT / Reverse proxy

Intermediate devices alter headers or block auth

Requests rejected or malformed

Rate limiting / blocked IP

Device blocks or rate-limits API calls

Intermittent 403s or account lockouts


Quick Checklist πŸ“

  1. Confirm username and password are correct.

  2. Confirm the password meets SonicWall requirements (min length, complexity).

  3. Check the SonicWall account is not locked.

  4. Confirm API access is enabled and permitted on the management interface you target.

  5. Validate SonicOS version and use the correct REST endpoint/port.

  6. Ensure the API user does not have MFA/2FA enabled.

  7. Confirm the agent can reach the API from its network (no firewall/NAT issues).


Step-by-Step Resolution πŸ‘¨β€πŸ’»

Follow these steps in order. After each change, re-run the inspector in Clear Cache + Debug Mode to check progress.

1️⃣ β€” Verify Inspector Configuration in Liongard

  • Open Liongard β†’ Admin β†’ Inspectors β†’ SonicWall.

  • Ensure hostname/FQDN, port, and credentials match the device.

  • Confirm you are pointing to the correct interface (LAN vs WAN) and port (default TLS/HTTPS)..

2️⃣ Step 2 β€” Validate Credentials & Account Status on the SonicWall

  1. Log in to the SonicWall management UI with the API user credentials.

    • If you cannot log in, reset the password to comply with SonicWall complexity rules:

      • Example policy: Minimum 8 characters, 1 uppercase, 1 lowercase, 1 number, 1 special.

  2. If the account is locked, unlock it in Users > Local Users & Groups (or corresponding area).

  3. If password changes are made, update the Inspector credentials in Liongard and re-run in Clear Cache + Debug Mode.

3️⃣ β€” Confirm API Role & Permissions

  • Ensure the API user is assigned the role required by Liongard. For more information, please consult our documentation.

  • Recommended: create a dedicated API user (not reused for interactive logins).

  • If your environment has role granularity, ensure the role includes permission for the endpoints required by the Inspector (monitoring, configuration read).

4️⃣ β€” Check API Access Settings & Interface Binding

  • In SonicWall: verify API access is enabled and allowed from the management interface (LAN or WAN IP) that the Liongard agent uses.

  • If the SonicWall restricts API access to certain IP ranges, ensure the Liongard agent IP (or agent network) is allowlisted.

5️⃣ β€” Verify SonicOS Version & Correct API Endpoint

  • Confirm the device is running a SonicOS version supported by the Inspector.

  • SonicOS v7 introduced REST endpoint differences vs v6 β€” confirm host:port & path. Default external management port is typically 443 (HTTPS).

  • If the device uses a non-standard port for REST, include it in the Inspector configurations :

6️⃣ β€” Check for MFA/2FA & Interactive Restrictions

  • API user accounts should not have MFA/2FA enabled. API access requires non-interactive authentication. If MFA is enabled, create a separate API user without MFA.

7️⃣ β€” TLS / Certificate Troubleshooting

  • If SonicWall uses a self-signed certificate, ensure the Liongard Agent can validate the certificate or import the CA into the agent host trust store.

  • Validate TLS handshake using the agent host:

    curl -v -k https://<sonicwall-host>:<port>/api/...
    • -k bypasses cert verification β€” use only for testing.

8️⃣ β€” Test Authentication Manually (curl / Postman)

From the agent host (or a host in the same network), attempt a simple API call to confirm credentials and endpoint:

Example (curl):

curl -v -u 'apiuser:password' \
https://<sonicwall-host>:<port>/rest/sonicos/api/1.0/diagnostics
  • Inspect headers and HTTP status:

    • 200 β†’ success

    • 401 / 403 β†’ authentication/authorization problem

    • TLS errors β†’ certificate / handshake issue

Example (Postman):

  • Import a small request to POST https://<host>/rest/… or GET a diagnostics endpoint.

  • Disable certificate verification only for troubleshooting; do not leave disabled in production.

9️⃣ β€” Review SonicWall Logs

  • Check System Logs and Security Events on the SonicWall for:

    • Failed login attempts (user locked out).

    • API-specific denial messages.

    • Source IP blocked or rate-limited.

  • If log entries show failed auth attempts from the Liongard agent IP, confirm password, unlock account, and re-test.

1️⃣0️⃣ β€” Network / Proxy / NAT Checks

  • Verify there is no proxy/NAT altering headers or requests (reverse proxy stripping auth).

  • If using reverse proxy or load balancer, ensure it forwards authentication headers correctly and supports HTTPS pass-through for REST API.

  • Refer SonicWall Documentation for more details : SonicWall Technical Documentation.


Common Error Scenarios & Resolutions 🀩

Symptom

Root Cause

Fix

401 Unauthorized from curl/Postman

Wrong credentials/password expired

Reset password, ensure complexity; update inspector

403 Forbidden when parent inspector calls child (API permitted but role lacking)

Insufficient API role

Assign correct admin/API role

Logs show account locked

Too many failed logins

Unlock account, confirm correct creds, reduce retries

TLS handshake errors

Invalid cert / unsupported ciphers

Import cert to agent, update TLS settings

Works from browser but not from agent

Agent host TLS/cert trust or network block

Check agent host trust store and network path


Best Practices (do these proactively) πŸš€

  • Use a dedicated API user per SonicWall for Liongard.

  • Document API user name, role, and the date when credentials were changed.

  • Use strong, randomized passwords that meet SonicWall complexity rules.

  • Avoid enabling MFA on API users.

  • Keep SonicOS patched and follow SonicWall release notes for API changes.

  • When upgrading SonicOS, re-verify REST endpoints and API settings.

  • Test the API from an agent host after any firewall or NAT change.

  • Keep a copy of recent SonicWall logs for troubleshooting.


When to Contact Support 🦁

Open a Liongard Support ticket if:

  • You completed the steps above and curl from the agent host still returns 401/403/Unauthorized Error.

  • The SonicWall logs show allowed requests yet Liongard still reports unauthorized.

  • You need the Liongard team to review Inspector logs or correlate timestamps.

  • You suspect a bug or recent build change might be affecting authentication.

What to collect before contacting Liongard Support

Gathering these items up front speeds resolution:

  1. Inspector logs (export from Liongard, show failed authentication attempts)

  2. SonicWall system logs showing failed logins / API denials (timestamped)

  3. SonicOS version and patch level

  4. Screenshots of API user configuration, role assignment, and API access settings

  5. Results of curl/Postman tests from agent host (raw output)

  6. Agent network path info (IP address used by agent, NAT/proxy details)

  7. Exact error messages and timestamps (Liongard & SonicWall timestamps help correlate)


Troubleshooting Flow 🀩

Start
β”œβ”€β–Ί Validate Inspector Config in Liongard
β”œβ”€β–Ί Test manual login to SonicWall UI with API user
β”‚ β”œβ”€ If fails β†’ Reset password / unlock account β†’ Retry
β”œβ”€β–Ί Test API from agent host (curl/Postman)
β”‚ β”œβ”€ If 401/403 β†’ Check role & API permissions
β”‚ β”œβ”€ If TLS error β†’ Check certs/ciphers
β”œβ”€β–Ί Check SonicWall logs for failed auth/rate-limits
β”œβ”€β–Ί If proxy/NAT in path β†’ verify headers & pass-through
β”œβ”€β–Ί Re-run Inspector in Clear Cache + Debug Mode
└─► If still failing β†’ collect artifacts & contact Support
End

References & External Docs

Third-party link disclaimer ‼️

We may reference external third-party resources solely as additional guidance.
​Liongard does not own, control, or guarantee the accuracy, security, or reliability of third-party sites. Please use them at your own discretion and risk.

Did this answer your question?