Since on 2.0, seeing strange pfS Syslog messages from WAN interface

goulou

Not sure what to make of this but since I have temporarily shelved my pfS 1.2.3 box and installed 2.0 Beta2, (now on Fri Jun 4 build), I am seeing some infrequent traffic in my syslog that I can't explain and is also not showing up anywhere I can find in the pfS system and F/W logs.

The Syslog shows my DHCP assigned WAN Interface address going out to Chinese networks as follows:

<134>jun 5 14:47:06 pf: 67.x.x.x.9739 > 118.x.x.x.25511: tcp 28 [bad hdr length 0 - too short, < 20]

In addition I get another one going to to 124.x.x.x … which is another Chinese net IP range

My setup is very straightforward:

LAN-->|pfS|WAN-->(Cable Modem)-->Internet
Rules are default: LAN any/any | WAN Block Bogons and Private ranges and I have no open ports
I have no software that is generating traffic out of my LAN (on its own) and anyway like i said the traffic is indicated as originating from the WAN Interface address.

Q. Can anyone tell me what this might be all about? This is my 3rd 2.0 snapshot (May 25, June 1 and June 4) and have never seen this traffic logged in my syslog on version 1.2.3

Q.From a bug point of view, why am I seeing these pf messages in Syslog and not seeing them in the pfS GUI display logs?

Thank you in advance!

jimp

I've not seen anything like that happen. If you are near the system when these happen, it would be interesting to see the contents of the state table when they pop up.

Are the ports involved always the same?

goulou

@Jimp,

Thanks for your reply - Since Monday, I'm not seeing further entries like these:

<134>jun 6 02:28:36 pf: 67.x.x.x.330 > 118.x.x.x.25511: tcp 28 [bad hdr length 0 - too short, < 20]

I don't quite get how the source address could ever be my WAN interface's route-able address - I guarantee I wasn't sending traffic out and if I had been, wouldn't the source be my LAN (nat) address?

The only other thing worth mentioning is that since upgrading to 2.0, I've noticed my syslog software is not processing events the same way as on 1.2.3. I guess there's some difference in the format of the udp syslog messages in 2.0? It doesn't make much sense because although I didn't check the state table, I do remember checking the GUI log entries in pfS and couldn't find the same entries so about the only guess I have is that the syslog messages are somehow bogus?

I appreciate your suggestion if I see it again.

jimp

Well it's really odd that the log entry doesn't have an interface on it, too.

pf log lines in 2.0 are often split over two lines. I had to practically rewrite the log parser to handle the new lines.

eri--

That seem like assymetric routing.

goulou

@Jimp
@ermal

Interesting thanks, I'll have to read up on asymmetrical routing - apparently it's not unheard of on stateful packet insp. routers with NAT?

So assuming that's it, was it just a fluke and forget it? Just out of curiosity, whatever it is/was… I assume that the appearing to be WAN outbound traffic was actually dropped based on the last part of the syslog entry: [bad hdr length 0 - too short, < 20]

jimp

The bad header length message is from tcpdump (which is used to extract the pf logs) and not from the actual log.

Somehow that log message was not proper. I'd consider it a fluke unless you see more of them.

goulou

@Jimp

Since you mentioned there was info missing I enabled raw logging - here's the latest relevant entry.

note again that 67.x.x.x is my ISP's assigned DHCP WAN IF address I've read up on asymmetrical routing and I follow the basic idea but it looks like it wasn't a fluke…

Jun 9 11:54:49 pf: 67.x.x.x.330 > 122.x.x.x.3016: [|tcp]
Jun 9 11:54:49 pf: (tos 0x0, ttl 117, id 33575, offset 0, flags [DF], proto TCP (6), length 48)
Jun 9 11:54:49 pf: 111.x.x.x > 67.x.x.x: ICMP host 122.x.x.x unreachable, length 36
Jun 9 11:54:49 pf: 00:28:27.377615 rule 2/0(match): block in on bge0: (tos 0x0, ttl 48, id 16200, offset 0, flags [DF], proto ICMP (1), length 56)

Anyone else seeing anything like this on 2.0?

jimp

That still doesn't look quite right.

A single log entry should look like this:

Jun  9 20:09:27 blooper pf: 00:00:00.001246 rule 2/0(match): block in on em0: (tos 0x0, ttl 1, id 46432, offset 0, flags [none], proto UDP (17), length 361)
Jun  9 20:09:27 blooper pf:     192.168.10.3.2314 > 239.255.255.250.1900: UDP, length 333