Site VPN Works but ASA Logs Don't: Check the Source Address

Inside hosts reach the remote collector and their syslog lines show up. The ASA's own messages about those same sessions never arrive. Nothing is wrong with the collector or with the tunnel, and that is the confusing part. The firewall is sending its logs from a source the tunnel was never built to protect.

What arrives and what does not

Start by separating two flows that look identical on a dashboard. Forwarded traffic passes through the ASA: a LAN host sends to the collector, the ASA matches it against the tunnel policy, encrypts it, and the collector sees the host's address. Generated traffic starts on the ASA itself: the box builds a syslog packet, chooses an egress interface and source, and only then asks whether any tunnel policy matches. The first flow proves the tunnel works, and it says nothing about the second.

A buffered event on the device is not evidence of remote delivery either, since the log may exist locally and never have been transmitted. Check the collector's receive counters before blaming the tunnel, because an empty counter is a different finding from one that grows.

A generated message is not forwarded traffic

When the ASA originates a packet, it is not proxying a LAN host. The source comes from the egress interface or from an explicit source setting, and the packet enters the same route lookup and policy checks as anything else the box sends. That means the VPN selector has to include the address the ASA actually uses, which is frequently its outside interface rather than an inside subnet.

If the policy protects 10.20.0.0/24 and the ASA sources from its outside address, the log packet either leaves in clear text toward a collector it cannot reach or gets dropped. Both outcomes look identical from the collector's side. The same reasoning applies to management traffic, which is why management-access is a separate design decision.

Which source the ASA puts on the wire

Find the source empirically rather than by assumption. A capture on the egress interface during a test message shows the actual source and destination, and it costs less time than reading three configuration sections. Compare that address against the tunnel's local selector.

Some releases let you pin the logging source to an interface, and the command reference for your version is the authority on whether that option exists and what it changes. A source-interface command from a different Cisco platform is not automatically valid on an ASA.

If you do change the source, change it deliberately and note it, because collector ACLs and any correlation built on syslog depend on it.

Match the selector to the log flow

Once the source is known, check three things in order: the crypto ACL or policy-based selector that decides which traffic is interesting, the route that decides where the packet goes, and any NAT rule that might rewrite the source before encryption. A packet that matches the route but not the selector is not tunneled, and a packet rewritten by NAT may match neither.

The collector side has requirements of its own: an ACL permitting the ASA's source, a return route, and a listening service on the port you configured. Transport matters here too, because TCP and TLS logging behave differently from UDP on a partially blocked path. Change one element at a time, or the next capture will not tell you which change mattered.

Verify at the collector, then record the source

Confirm the message arrives, then write down the source address the ASA used, the selector that carried it and the severity you tested with.

That record turns the next collector ACL change or selector edit into a two-minute check instead of a rediscovery. It also documents which of the two flows was ever validated, which is the part most runbooks omit. If the message still does not arrive, lower the severity threshold temporarily and test against a single destination.

Cisco's ASA logging FAQ documents an outside-sourced case that needs the corresponding protected traffic definition, and its inside-sourced example includes both a logging host on the inside and management-access on the inside. Treat the documented combination and the software context together rather than assuming one copied line fits every configuration.

A tunnel that carries LAN traffic is not a tunnel that carries the firewall's own voice.