Log Dejargonizer

Cisco ASA / Firepower Threat Defense · Event 113005

Cisco ASA 113005: VPN authentication was rejected

Someone tried to authenticate to the firewall, usually for VPN access, and the authentication server refused. On any internet-facing VPN these arrive constantly — and the ones that matter are the ones followed by a success.

Also written as %ASA-6-113005ASA 113005AAA user authentication Rejectedasa vpn authentication failed

What it means for you

On a personal computer

Enterprise VPN logging. You will not see this on a home router.

For an analyst

This is the outer edge of your network and it is scanned continuously. The reason field distinguishes a wrong password from an unknown account, which is the same distinction the Windows sub-status codes make. Correlate against 113004 and 113008 for successful authentication — a success from an address that produced a run of rejections is the sequence worth alerting on, particularly where multi-factor is not enforced.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 2026 09:47:31 fw-edge-01 : %ASA-6-113005: AAA user authentication Rejected : reason = AAA failure : server = 192.0.2.20 : user = jbrooks : user IP = 198.51.100.77

The fields that decide it

Everything else in the log line is context.

reason
Why authentication failed.
  • AAA failureGeneric rejection, most often a wrong password.
  • Invalid passwordCorrect account, wrong password.
  • User was not foundThe account does not exist. A run of these is username enumeration.
  • Unable to contact serverThe authentication server is unreachable. An availability problem, not a security one.
server
Which authentication server refused it — RADIUS, LDAP, or the local database.
user
The account that was tried. Generic names mean untargeted scanning; real employee names do not.
Source address
Usually on an accompanying line rather than this one. Correlate by session or timestamp.

Ordinary reasons this happens

Most of the time it is one of these.

  • A user mistyping their password.
  • An expired password not yet changed.
  • A saved VPN profile still holding an old credential.
  • The authentication server briefly unreachable, which rejects everyone at once.
  • A user connecting with the wrong profile or group.
  • Internet background scanning against a published VPN endpoint.

When it is not ordinary

Password spraying against the VPN.

What gives it awayMany distinct usernames rejected from one source over hours, kept slow to avoid lockout.

ATT&CK T1110.003

Credential stuffing with breached passwords.

What gives it awayRejections across many real usernames, then a success — the shape that matters most.

ATT&CK T1110.004

Username enumeration.

What gives it awayA run of 'User was not found' rejections, distinguishing real accounts from invented ones.

ATT&CK T1589.002

Targeted access with a stolen credential.

What gives it awayA small number of rejections followed by a success from an unusual location for that user.

ATT&CK T1078

What to do next

  1. Read the reason. A wrong password and an unknown account mean different things about what the other side already knows.
  2. Count distinct usernames per source over a day. Breadth is the spraying signal.
  3. Look for a successful authentication from the same source afterwards. That is the question that matters.
  4. Check whether multi-factor is enforced on this connection profile. If not, that is the finding regardless of the log.
  5. For 'Unable to contact server', treat it as an availability problem and check the authentication server.
  6. Compare the usernames being tried against your real account names — generic ones mean scanning, real ones mean reconnaissance.

Queries to run

splunk Spraying, as distinct usernames per source. 
index=firewall "113005" | rex "user = (?<user>\S+)" | rex "reason = (?<reason>[^:]+)" | stats count dc(user) as users by src_ip reason | where users > 5 | sort -users
splunk A success following repeated failures from the same source — the sequence worth alerting on. 
index=firewall ("113005" OR "113004") | rex "user = (?<user>\S+)" | stats count(eval(searchmatch("113005"))) as fails count(eval(searchmatch("113004"))) as ok by user src_ip | where fails > 5 AND ok > 0
grep Which accounts are being tried, straight off a raw log file. 
grep '113005' asa.log | grep -oP 'user = \K\S+' | sort | uniq -c | sort -rn | head -20

Common questions

Should I worry about lots of ASA 113005 messages?

Not by themselves. Any VPN endpoint reachable from the internet is scanned continuously and rejections are the expected result. What matters is a success from an address that produced a run of rejections, many distinct usernames from one source, or usernames that match your real employees rather than generic wordlist entries.

What does 'reason = AAA failure' mean?

A generic rejection from the authentication server, most often a wrong password. It is deliberately vague — the ASA does not always get a more specific reason back from RADIUS or LDAP. Check the authentication server's own logs when you need the precise cause.

How do I stop VPN password spraying?

Enforce multi-factor authentication on the connection profile — that makes a guessed password insufficient on its own, which is the only fix that holds. Beyond that, lockout policies, rate limiting at the edge, and restricting the VPN to expected geographies all reduce the volume, but none of them substitute for the second factor.

Read next

Vendor documentation

Last reviewed 28 August 2026