Does anyone know where I might find information on deciphering messages from the SuSE firewall? I fond the following two lines in my messages file listed a number of times and I am trying to figure out what they are all about. Any ideas?

Aug 28 05:38:15 myserver kernel: SuSE-FW-TRACEROUTE-ATTEMPT IN= OUT=eth0 SRC=192.168.1.1 DST=192.168.1.12 LEN=56 TOS=0x00 PREC=0xC0 TTL=64 ID=29472 PROTO=ICMP TYPE=11 CODE=0 [SRC=192.168.1.12 DST=12.158.33.17 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=2247 DF PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=1024 ]

Aug 28 05:37:12 myserver kernel: SuSE-FW-ILLEGAL-TARGET IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:30:f1:47:be:2d:08:00 SRC=10.44.44.26 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=5311 PROTO=2

Some background on my settings:
My server is myserver and has an ip of 192.168.1.1 on the internal card eth0 and an isp assigned ip of 10.44.44.15 on the external card eth1.
192.168.1.12 is simply a machine on my network
I am running the SuSE firewall2 that came with SuSE 8.1 and it is set in Quick mode which should as far as I understand block everything externally and nothing internally.

TongueTied, your logs are showing messages from iptables/netfilter, as configured by the Suse-firewall.

I hope this link will help you, as it explains better than me...

http://logi.cc/linux/netfilter-log-format.php3

Tried using that link but I still don't understand if it is simply a notice of activity or something I should be concerned about.

myserver kernel: SuSE-FW-TRACEROUTE-ATTEMPT IN= OUT=eth0 SRC=192.168.1.1 DST=192.168.1.12 PROTO=ICMP
Outbound ICMP traffic triggering traceroute rule (from internal "myserver" address to internal "simply a machine on my network" address).


myserver kernel: SuSE-FW-ILLEGAL-TARGET IN=eth1 OUT= DST=224.0.0.1 PROTO=2
Inbound request for IGMP from "myserver" public address to external network multicast address.

Like everything that isn't abused, traceroutes and multicasts are harmless activity unless your network policy dictates otherwise. If unnecessary it's just harmless and annoying. If your policy needs these rules in place you could drop the LOG target rules.