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.
3.2 Open the policy's Logging page
Click More → Logging in the policy's breadcrumb bar.
By default nothing is selected here, and an orange banner warns that at least one option is required.
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.
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.
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.
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.
Tick Syslog server, then click Confirm and Apply.
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.
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.
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.)
Click Save.
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.
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.
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:
"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.
Wait for Completed / 1 succeeded.
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 (
9001Palo Alto,9002Cisco 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.