Re: Firewall-1 Logging *Issue*

[BlueBoar () THIEVCO COM (Blue Boar)]

Mike Frantzen wrote:
> While dinking with an eval version of Firewall-1 4.0 last summer,
> I ran across an 'oddity' in the logging.
<snip>
> Now while watching the logs grow (really really fast), I saw that the
> source IP was being diddled on.  For a few seconds of traffic, the source
> IP was losing the high bit.  Ie, a 132.3.2.1 would become a 4.3.2.1.
> The next few thousand packets would also have the wrong source IP.  After
> a few seconds and a few thousand packets, the source IP would be reported
> correctly in the log viewer.  Waiting awhile longer and it would drop the
> MSB again.   Rinse, lather, and repeat.

I had something really similar happen on a production FW-1 4.0 SP4 running
on a Nokia 650.  I was getting packets with a source of 223.255.255.223,
destination of 222.255.255.222 (or vice-versa, can't recall.) They were
just shy of the IP multicast range (class D.)

These were UDP packets, source and destination ports of 135.  Obviously,
these were screwed-up NetBIOS broadcast packets that found their way
to my firewall because of the apparent destination address.  In my case,
I don't think it was a logging problem, at least not entirely. (Spotted
them in the log originally.)

I could see them coming in fairly regularly via tcpdump, which
negates somewhat the screwed logging theory in my case.  I also
caught a few via debug ip packet on the inside Cisco router,
but much fewer than I should have (compared to the number that
hit tcpdump.)

Had they gotten their bits twiddled on the wire somewhere, the
checksum should have killed them at any router.  So, I assumed
they got mangled in memory on the original sending host, and
got a proper checksum for the mangling.

So, one question I'd have for your case is: Are you sure they got onto
the wire intact?  Did you have another mechanism to compare them
on the wire vs. in the log?

                                        BB