Applies to UniFi consoles running UniFi OS: UDR, UDR7, UDR 5G Max, Express, Express 7, UDM, UCG-Ultra and UXG-Lite.
Enabling Remote Logging in the UniFi Network application is not enough on these consoles.
This page explains why, and what to change so that firewall events actually reach the SIEM.
This procedure must be repeated after every UniFi firmware update.
Both files you are about to edit are regenerated by ubios-udapi-server and carry the header “Generated automatically”.
An update — and sometimes a simple re-provisioning — silently reverts them, and the event flow stops without any error being raised.
See After every UniFi update.
Remote Logging is enabled in the UniFi Network application, the SIEM address and port 514 are correct, the SIEM listener is up and reachable — and no event ever arrives.
On the SIEM, syslog_received_total does not even exist, which in Prometheus means nothing was ever received.
On UniFi OS, firewall events never travel through syslog.
They are captured by ulogd from a netfilter NFLOG group and delivered as JSON over a Unix socket to the controller — that is what feeds the event list in the UniFi interface.
ulogd ships with a second processing stack that renders the same events as classic netfilter text (SRC=… DST=… PROTO=…), which is exactly the format the Artica SIEM parses.
That stack exists, is enabled, and writes into a pipe that syslog-ng already reads.
The problem is a single number:
| ulogd stack | NFLOG group | Output |
|---|---|---|
mcad_fw |
1 | JSON > Unix socket > controller (UniFi interface) |
iptables_nflog > PRINTPKT |
0 | text > /run/ulog/ulogd.pipe → syslog-ng |
Everything needed is already installed.
Only the wiring is missing.
root (enable SSH in UniFi OS settings).Do not copy the value blindly. The group number is a property of your console and its firmware. Read it on your own device before editing anything.
List the groups your firewall rules actually use:
iptables -S | grep -oP "nflog-group \K[0-9]+" | sort | uniq -c
Typical output on a UDR — 188 rules, all on group 1:
188 1
If this command returns nothing, your firewall produces no log at all: enable logging on the relevant firewall rules in the UniFi Network application first, otherwise the rest of this page will change nothing.
Now read which group each ulogd stack listens to:
awk '/^\[/{s=$0} /^group=/{print s" "$0}' /etc/ulogd.conf
[iptables_nflog] group=0 <-- the text stack, listening to nobody[ip_reputation_block] group=3[mcad_fw] group=1 <-- where the rules actually log[mcad_geo] group=2
Back up the file first:
cp -a /etc/ulogd.conf /root/ulogd.conf.bak-siem
Edit /etc/ulogd.conf and change only the group of the [iptables_nflog] section, to the value found in step 1:
[iptables_nflog]group=1
Leave [mcad_fw], [mcad_geo] and [ip_reputation_block] untouched. mcad_fw keeps the same group: both stacks then read it, the controller keeps receiving its events, and the UniFi interface keeps working.
Create a new file /etc/syslog-ng/conf.d/99-siem.conf, replacing 10.1.15.3 with your SIEM address:
# Firewall events forwarding to the Artica SIEM.## NOTE 1: this directory is managed by ubios-udapi-server; this file may be removed# by a firmware update. Re-apply it if the flow stops.# NOTE 2: the anti-loop filter is MANDATORY. See below.filter f_siem_noloop { not (match("DST=10.1.15.3" value("MESSAGE")) and match("DPT=514" value("MESSAGE")));};destination d_siem { network("10.1.15.3" transport("udp") port(514)); };log { source(s_ulogd); filter(f_siem_noloop); destination(d_siem); };
Never omit the anti-loop filter.
Every message sent to the SIEM is itself an outbound packet to<SIEM>:514, which the firewall logs, which is then forwarded, which produces another log entry…
On a quiet home network this loop was measured at 56 % of all events and 145 events/s.
With the filter in place, the same console settled at 12 events/s of genuine traffic.
The s_ulogd source already exists in the stock configuration — do not redefine it.
syslog-ng-ctl reloadkill $(cat /run/ulog/ulogd.pid)
ulogd is supervised and restarts on its own within a few seconds.
Confirm it before going further — a console left without ulogd no longer feeds the UniFi interface either:
ps -eo pid,args | grep "[u]logd"
If it does not come back, start it with the exact same arguments:
/usr/sbin/ulogd --daemon --uid ulog --pidfile /run/ulog/ulogd.pid
Check that the text stack now produces events:
timeout 5 head -c 300 /run/ulog/ulogd.pipe
Aug 17 14:45:32 Dream-Router 684df252…;PREDEFINED_FIREWALL_RULE;ACCEPT IN= OUT=br2 MAC= SRC=10.1.15.1 DST=10.1.15.3 LEN=313 TOS=00 PREC=0x00 TTL=64 ID=13255 DF PROTO=UDP SPT=39840 DPT=514 LEN=293 UID=0 GID=0 MARK=1a0000
Declare the address the console sends from, not its LAN address.
A UniFi console is a router:
10.1.14.1 may well emit from 10.1.15.1. Declaring the wrong address is not a hard failureRead the real source address from the SIEM itself:
tcpdump -ni any port 514 -c 3
Then declare that address in Firewall > Sources of the Artica console, with the device name and tenant of your choice.
Both files are generated by UniFi:
/etc/ulogd.conf — header “Generated automatically by ubios-udapi-server”/etc/syslog-ng/conf.d/ — same generator owns the directoryA firmware update, and sometimes a simple re-provisioning of the console, restores them to their stock state:
group=0comes back and99-siem.confdisappears.
The flow then stops silently — syslog never acknowledges anything, so neither the console nor the SIEM raises an error.
Nothing will tell you; the events simply stop.
Two practical consequences:
accept 10 352, deny 336, but log 12 132 — more than half. log as “undetermined”, never as “not blocked”.cp -a /root/ulogd.conf.bak-siem /etc/ulogd.confrm -f /etc/syslog-ng/conf.d/99-siem.confsyslog-ng-ctl reloadkill $(cat /run/ulog/ulogd.pid)
The console returns to its stock behaviour: firewall events keep feeding the UniFi interface, and nothing is forwarded any more.