Making Sense of Syslog data
-
I can pretty much work out what is going on but I can't debug or explain it …
For instance - I have been forced to completely reload pFSense because a rule - that I cannot see started blocking a valid connection. i.e.
rule match 73/0 block on lo0:
I do not have ANY interface with such a name as lo0 - all are re*, the target IP that was being blocked has a rule in NAT, has an alias and up until I decided to re-install snort was working fine. I could do nothing to fix this and reloaded ... ,my config is now identical to previous (except snort) but the system works correctly.
I guess what I am asking is if some kind person can tell me how to view these hidden 'default' rules so that I can make more sense of the syslog messages ..
-
Hard to say what's going on without more info.
You can check the output of:
pfctl -vvsrFrom Diagnostics > Command or from a shell
The contents of /tmp/rules.debug may also be helpful.
Also, those firewall log entries should be visible from the WebGUI: Status > System Logs, Firewall tab. If you click the 'x' by the rule it will report back which rule did the block.
-
How much of this info is safe to put here and how much is of use to potential hackers .. ??
There is no 'X' by the notifications …
using pfctl I have identified that rule 73 reports this
@73 pass out quick on re2 all flags S/SA keep state label "let out anything from firewall host itself"
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 58951 ]pass out ?? - re2: ?? so where is block on lo0 (that I now know to be loopback) related to this ???????
The interface identified in the rule 're2' currently has NOTHING connected or defined, plus the rule says pass - not block. Since lo0 is loopback the only machine that can be looping back is pfSense itself (127.0.0.1 is assume) and yet the IP address in the block is one on the local LAN.
loopback = "{ lo0 }"
lan = "{ re1 }"
ng0 = "{ re0 ng0 }"
wan = "{ re0 ng0 }"
enc0 = "{ enc0 }"
OPT1 = "{ re2 }"
OPT2 = "{ em0 }"User Aliases
I appreciate the pointers though because I identified one other issue too in that the system has decided (and don't ask me how) that one of my internal subnet IP's is on the WAN so it is refusing any packet from it even on the local LAN nic re1:, when I try to resolve the affected machines name the pfSense fails, ping fails because pfSense blocks itself (bit stupid). I found out why though - it is the manner in which pFSense is resolving names. pfSense seems unable to resolve using the private DNS server that I run, ther eis no way to tell pfSense that it should use LAN for DNS resolution.
If I put my DNS server IP address in the system > general setup > dns servers box the internet access is broken, pFSense tries to use it to resolve only on the WAN re0:, if I leave the DNS boxes empty my internet connection is broken even with DNS forwarder disabled.
My private dns server has root hints for openDNS but I don't WANT or need the pfSense to get involved with ANY kind of DNS resolution but the only way I can get internet working though is to put the public (openDNS addresses) in the boxes in pFSense.
My private DNS is configured OK because if I turn off packet filtering (turn pFSense into a bridge) I can resolve anything perfectly fine so why can't I force pFSense stay out of DNS resolutions and keep my internet working.
