Need help (albeit basic) identifying FW log weirdness
Ok so I know this is likely going to have a simple answer and I have pondered it for some time before posting but drawn a blank.
Attached is a small screen grab of my FW log. I'm logging the rule that passes traffic over 80 just for the sake of this post. As you can see traffic from a local machine (192.168.2.2) is being passed quite happily.
What I'm slightly confused about is the outbound traffic from my WAN interface (the IP behind the big read blocks). Now I assume that the traffic is coming from the LAN, heading out to the Internet but what I don't understand is why the WAN interface is being presented in the logs. Surely is should show a LAN address as the source address?
Secondly, when I look at my WAN rules (there aren't any bar the ones that were set out of the box), I don't see a default deny all rule yet I know if is there from watching all the port scans bounce off the WAN interface. Where exactly is it?
Thanks for any pointers.
Looks like a case of this…
Thanks for your reply. During my limited time lurking in the forums, I'm amazed how many times you pop up in replies to help with the simple to the complex issues and not once seem to crack under what must seem (as in this case), very simple questions. More credit to you. Its good to know we (I!) can ask questions without being slammed for asking them!
Anyway, back on topic, I actually read the link you have posted in the pfsense book and thought that this may be the case although my understanding of the way it would work led me to think that the source address in my case should still be a LAN address, not my WAN address. Even if it was say, my browser sending a late FIN packet, the source of that block should be the LAN no?
I get a sneaking suspicion I'm missing something obvious again…. ???
Thanks for your help.
The raw logs might tell you more, but it looks more like your WAN somehow blocked inbound a packet from itself. Normally all the logs are for inbound packets, not outbound, though with out-of-state traffic as the link above goes into it gets muddier.
TCP:RA is a connection reset, meaning the port is not open for making a connection. Though the ordering of the WAN and remote IP are little odd…
Is that a 2.0 snapshot? If so, do you have any floating rules? What shows up if you click the red x next to the rule, "Default Deny" or some other rule?
I am indeed running a snapshot - 2.0-BETA5 (i386) built on Sat Jan 8 14:40:33 EST 2011.
I don't have any floating rules, the only rules that exist are LAN rules to allow browsing, etc out.
I'm now sat here waiting for an entry in the FW logs so I can get you the info on which rule blocked it but sod's law, I'm seeing nothing at the moment. However, I am 99% sure that the block was blocked by the default deny rule on the WAN. As soon as I see the entry again, I will be able to give the raw logs and hopefully you/other helpful forum member can point me in the right direction.
Ok, so I've just got in and checked the logs. Its full of those weird entries that seem to originate from my WAN address to the Internet.
Image attached with my IP blocked out.
A raw log output of some of these entries reads as follows, (again, starred out my IP):
pf: ...114.58775 > 126.96.36.199.5228: Flags [FP.], cksum 0x2550 (correct), seq 0:74, ack 1, win 32044, options [nop,nop,TS val 1648272 ecr 486655357], length 74
pf: ...114.60183 > 188.8.131.52.5223: Flags [FP.], cksum 0xb104 (correct), seq 0:37, ack 1, win 32965, options [nop,nop,TS val 21515052 ecr 1739744880], length 37
On this occasion, these seem to be the main 2 addresses the WAN is trying to connect to. That would be a Google address and an Apple address. The only thing this (Apple) attempt is going to be (at least from the inside of my LAN) is 1 iPhone). That still doesn't explain pfsense showing the WAN interface sending traffic however.
The block rule that fires for these 2 blocks and all others that are attempting to leave via the WAN with the WAN address as the sending address is: @2 block drop out log all label "Default deny rule"
Does this help in any way to narrow down the problem?