Remote syslog stopped working

Hi there,

I have configured my remote syslog from the beginning. After some weeks I checked my syslog server logfiles today. No IPFire log records anymore.

I assume it stopped working after one of the most recent updates. Currently I run Update 146.

Can anybody confirm that UDP logging to a remote syslog server still works, or even not. My other sources are still logged by my syslog server.



I don’t yet have syslog running, although its seriously on my to do list.

Do this tho, if you want to confim syslog is actually leaving your ipfire.

Drop to SSH on Ipfire BASH… run:

#tcpdump -XXnn port 514

Press Enter… and wait for results.

You should see packets trying to leave your IPFire destined for the IP address of your syslog server, unless something broke in Core 146. See if that gives you a clue as to whether it is sending. The packets in BASH should also clue you in, as to the Protocol its sending on, so you can confirm.

If you are, in fact seeing packets leave IPFire, is there a firewall between IPFire and Syslog server? if there is, do the same thing there, on the receiving interface to see if you see port 514 UDP traffic sourced from IPFires interface.


Hello Eric,

to make sure remote syslog is really on, I unchecked remote syslog, clicked the save button in the web interface. I activated remote syslog again, clicked the save button.

After then I just tried tcpdump for an hour:

tcpdump -XXnn port 514 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on green0, link-type EN10MB (Ethernet), capture size 262144 bytes

It does not show any port 514 traffic.

On the other hand the firewall log in the web interface shows me entries during these hour.

To make sure the the tcpdump is working, I tried an nmap ipfire -sU -p 514 from my syslog server. It produced tcpdump output.

So, I can confirm there are no packets leaving my IPFire towards UDP port 514.


Is your syslog server on green0?
Ipfire chooses the interface based on the server address.

I just checked the function on my system. tcpdump lists the packets, the server receives the packets.

I have solved the remote syslog problem!

But now I’m confused about firewall rules.

The syslog packets have been blocked by an IPFire-Firewall rule.

Since the syslog server is connected to the internet I have a rule to DROP ALL UDP from RED to my server on GREEN. That rule kills my syslog traffic. Enabling logging for that rule gives me in the web interface:


with .1.13 IPfire and .10.179 Server.

I declare the syslog issue to be closed.

Well, I have to think about my firewall rules again.


I’m back again. I thought about my firewall rules which caused my remote syslog problem. And now I consider it being a firewall problem. For testing I setup virtual machines sinnce I didn’t want to do testing on my production IPFire.

My test bed is the LAN-side of a ZyXEL USG 60. Its LAN is my virtual Internet.

The virtual IPFire has on RED and on GREEN.

The rsyslog (also a MTA) has its own global address. I configured an ALIAS in IPFire and setup SNAT and DNAT rules. So, the rsyslog server has ON RED and on GREEN. For easier testing with nmap I enabled TCP port 514 for rsyslog.

From the internet only the SSH port of the rsyslog should be reachable and not port 514 for rsyslog!

Firewall rules

Protocol  Source  Destination       Comment
Protocol  Source  Destination       Comment

Well, my DROP ANY TCP rule is meant to prevent TCP access from the Internet (RED) to my server (GREEN). I do an nmap form the internet side (RED) to my server (ALIAS). As expected, 22 is open and 514 is closed :grinning:

root@u2004s:~# nmap -sT -p 22,514
Starting Nmap 7.80 ( ) at 2020-07-09 10:53 UTC
Nmap scan report for
Host is up (0.00065s latency).

22/tcp  open     ssh
514/tcp filtered shell
MAC Address: 08:00:27:F5:1D:C1 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 1.34 seconds

And that is the moment where IPFire no longer feeds the rsyslog daemon :thinking:

I do an nmap from within the IPFire:

[root@vipfire ~]# nmap -sT -p 22,514
Starting Nmap 7.80 ( ) at 2020-07-09 13:00 CEST
Nmap scan report for
Host is up (0.00034s latency).

22/tcp  filtered ssh
514/tcp filtered shell
MAC Address: 08:00:27:3F:24:72 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 1.31 seconds

Port 514 is filtered, hence the rsyslog is no longer feeded by IPFire!

The solution: I configured “Outgoing Firewall Access”:

Protocol Source          Destination    Comment
TCP      Interface All   Any            ALLOW ANY TCP

Okay so far. The strange thing is, the “Default firewall behaviour” is “Allowd”. Which means, I configued an ALLOW RULE on the top of the default ALLOW :thinking: