Cisco FTD (FMC) — Syslog Configuration Guide (2/2): logging & deploy
Journey Step 3 Visual Guide — Cisco FTD (FMC) Syslog Configuration (2/2)
This is the second half of the guide. Part 1 covered the Platform Settings policy and the syslog destination.
Part 3 — Set the policy-wide syslog default
Do not skip this. Access control rules that send to syslog do so through the policy's default syslog configuration.
Until that default exists, the rules point at nothing and deployment fails validation.
3.1 Open the access control policy
Go to Policies → Access Control and open the policy assigned to your device.
Access Control policy list
Access control rules
3.2 Open the policy's Logging page
Click More → Logging in the policy's breadcrumb bar.
The More menu with Logging marked
By default nothing is selected here, and an orange banner warns that at least one option is required.
Default Syslog Settings before configuration
3.3 Point it at the Platform Settings server
Tick Use the syslog settings configured in the FTD Platform Settings policy deployed on the device, then set Syslog
Severity to INFO.
While you are here, tick Send Syslog messages for IPS events and Send Syslog messages for File and Malware events.
Without these, intrusion and file/malware events stay in the Management Center and never reach your collector.
Default Syslog Settings configured
Leave "Send using specific syslog alert" unticked. It is the alternative to what you just selected: it points at a
Syslog Alert object defined in the FMC with its own address and port. Since the destination already lives in Platform
Settings, ticking both would define two competing destinations. Unticked here is deliberate, not an oversight.
Click Save.
Access control policy logging saved
Part 4 — Enable syslog on the rules
Part 3 defined the destination. This part decides what actually gets sent.
4.1 Edit each rule
Click a rule name to open it, then click Logging in the rule header.
Rule editor
Under Send Connection Events to:, Syslog server is unticked by default — even on rules that already show Logging ON,
because those are logging to the Management Center only.
Rule logging settings with Syslog server unticked
Tick Syslog server, then click Confirm and Apply.
Syslog server ticked
Also confirm at least one of Log at beginning of connection or Log at end of connection is ticked. If neither is, the
rule produces no connection events at all.
Repeat for every rule whose traffic you want to see.
Second rule's logging settings — shown BEFORE ticking Syslog Server; tick it just as you did on the first rule
You may see a warning that a rule could shadow rules below it, or that it has no source or destination network objects.
That describes the rule's existing scope, not anything this procedure changed.
4.2 Do not forget the default action
This is the most commonly missed setting in the whole procedure. The default action at the bottom of the policy handles
every packet that matches no rule — usually blocking it — and by default it logs nothing at all, not even to the
Management Center. Denied traffic is exactly what a SOC most wants to see.
Click the gear icon beside Default Action.
Default action logging, nothing enabled
Tick Log at beginning of connection and Syslog server, then Apply. (Block actions cannot log at end of connection, so
that option stays greyed out.)
Default action logging configured
Click Save.
Access control policy saved
4.3 Security Intelligence (only if you use it)
Security Intelligence blocklists have their own logging toggles — the small icons beside Networks and URLs in the Block
List column.
Security Intelligence block lists
Hover each icon to see how many objects the list contains. If your block lists are empty, there is nothing to log and
you can skip this. Enable it if you later populate those lists.
Part 5 — Deploy
Nothing configured above reaches the firewall until it is deployed.
Click Deploy in the top navigation, select your device, and click Deploy All.
Deploy panel with the device ready
Plan this step. Deployment pushes configuration to a live firewall and can briefly interrupt traffic. Run it in a
maintenance window.
If you see a validation warning
Skipping Part 3 produces exactly this:
Validation warning about invalid Access Control Policy Logging
"Access Control Policy Logging configuration is invalid. Access Control rules have syslog configured to use Access
Control policy's logging configuration. Configure a valid syslog destination to avoid syslogs not being sent."
Do not tick Ignore warnings. Go back and complete Part 3 — deploying past this warning produces a firewall that looks
configured and sends nothing.
Watch it through
Deployment takes several minutes and reports its stage as it goes.
Deployment in progress
Wait for Completed / 1 succeeded.
Deployment completed
Important — the collector is not listening yet
FMC deployment finishes the firewall's half of the job, but that alone does not make the collector reachable. The
collector's syslog listener on port 9002 does not open when your machine enrolls in Step 2 — it opens when Step 4 (the
intake form) is submitted and JawaSec's activation completes. Enrollment only registers the machine with our Fleet
management; the syslog input itself is a separate configuration that is attached to your machine automatically once both
your enrollment and your Step-4 submission are in.
Practically: if you test connectivity from the firewall to the collector's port before you finish Step 4, the connection
will fail — by design, not because something is wrong on your side. Complete Steps 1-4 in order, including saving the
intake form, before drawing any conclusion from a failed connectivity test.
You also never need to re-run the Step-2 install command after this guide. The syslog listener is delivered to your
already-enrolled machine as a policy update pushed by Fleet — the same mechanism Step 2's agent already checks in
through — not by reinstalling anything.
Verification
On the collector machine, confirm the firewall is connecting (only meaningful after Step 4 has completed and activation
has run — see the box above):
sudo ss -tnp | grep :9002
You should see an established connection whose peer is the firewall's interface address.
If you want to prove the firewall is trying even before the collector is ready, watch the packets directly:
sudo tcpdump -nn -i any 'tcp port 9002' -c 20
A firewall that is correctly configured but talking to a collector whose listener has not opened yet (i.e., you have not
finished Step 4) looks like this — repeated [S] from the firewall, [R.] back:
10.20.0.11.14222 > 10.20.0.20.9002: Flags [S], ...
10.20.0.20.9002 > 10.20.0.11.14222: Flags [R.], ...
That output means the firewall side is finished and the only thing missing is finishing Step 4 in the portal.
In the JawaSec portal, the Step-3 card flips to done once you tick the confirmation checkbox and the Step-4 intake form
is submitted; the source itself goes Active once JawaSec's automatic activation detects the first real events arriving
from your collector — this does not happen instantly at Save.
If nothing arrives after Step 4
Each of these produces the same symptom — no data — so check them all before concluding the firewall is at fault.
| Check | How | |---|---| | Step 4 not actually submitted | Go back to /client/settings/data-sources and confirm the
card shows the intake step as done | | Something else holds the port on the collector | sudo ss -lntp \| grep :9002 —
anything other than the collector process is a conflict | | Network path blocked | Confirm the port is reachable from
the firewall's network; check security groups, cloud firewalls and host firewalls | | Wrong "Reachable By" | Section 2.4
— management interface versus data interface | | No logging filter | Section 2.5 — a syslog server with no logging
destination sends nothing | | Severity too strict | Sections 2.5 and 3.3 — anything stricter than informational drops
connection events | | No policy-wide syslog default | Part 3 — rules pointing at a default that does not exist | | Rules
not sending to syslog | Section 4.1 — Logging ON alone is not enough | | Denied traffic missing | Section 4.2 — the
default action logs nothing until you enable it | | Configuration never deployed | Part 5 — saved is not the same as
deployed |
Notes
- The IP Address field in the Add Syslog Server dialog accepts only a selection from its dropdown. Typing a name that
matches an existing object is not enough; the field stays flagged invalid until an entry is chosen from the list.
- A network object created through the + button inside that dialog does not appear in the dropdown until the dialog is
closed and reopened, which reloads the object list.
- Multiple syslog servers are supported. To keep a raw local copy of the logs alongside the collector, add a second
syslog server entry on a different port of the same host and have a local syslog daemon write that port to a file.
- Changing rule logging requires a deployment; so does the default action. Batch your changes and deploy once rather
than deploying after each edit.
- One collector machine can receive both a Palo Alto and a Cisco FTD integration at once, one per port (9001 Palo
Alto, 9002 Cisco by convention) — each keeps its own state in the portal.
Questions
Direct any questions about this guide or the firewall change to your JawaSec onboarding contact.