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.
Regards,
Rainer
Rainer,
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.
Eric
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.
–
Rainer
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:
15:09:48 OUTGOINGFW UDP 172.22.1.13 172.22.10.179 514(SYSLOG) 514(SYSLOG)
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.
–
Rainer
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 172.16.1.0/24 is my virtual Internet.
The virtual IPFire has 172.16.1.4 on RED and 192.168.4.0/24 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 172.16.1.201 ON RED and 192.168.4.201 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
TCP RED 192.168.4.201:22 ALLOW SSH
Protocol Source Destination Comment
TCP RED 192.168.4.201 DROP ANY TCP
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 
root@u2004s:~# nmap 172.16.1.201 -sT -p 22,514
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-09 10:53 UTC
Nmap scan report for 172.16.1.201
Host is up (0.00065s latency).
PORT STATE SERVICE
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 
I do an nmap from within the IPFire:
[root@vipfire ~]# nmap 192.168.4.201 -sT -p 22,514
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-09 13:00 CEST
Nmap scan report for 192.168.4.201
Host is up (0.00034s latency).
PORT STATE SERVICE
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
–
Rainer
