OPNsense Forum
Archive => 18.7 Legacy Series => Topic started by: chemlud on December 22, 2018, 03:10:37 pm
-
Hi everybody!
Have here an up-to-date amd64 install I configured these days. This morning I had a look at the live view of the FW log and found that for some (not all) entries the WRONG FW rule was indicated that resulted in blocking this traffic.
I had to add a rule (Floating this time) and afterwards I had a look into live view of FW logs again. This time even more entries had the wrong FW rule listed.
Here is an example:
lan Dec 22 07:20:27 10.0.0.33:60061 153.122.0.27:80 tcp USER_RULE: Block SILENT HTTPS any NOT LAN or VPNs
lan Dec 22 07:20:19 10.0.0.33:60061 153.122.0.27:80 tcp USER_RULE: Block SILENT HTTPS any NOT LAN or VPNs
lan Dec 22 07:20:15 10.0.0.33:60061 153.122.0.27:80 tcp USER_RULE: Block SILENT HTTPS any NOT LAN or VPNs
lan Dec 22 07:20:13 10.0.0.33:60061 153.122.0.27:80 tcp USER_RULE: Block SILENT HTTPS any NOT LAN or VPNs
lan Dec 22 07:20:12 10.0.0.33:60061 153.122.0.27:80 tcp USER_RULE: Block SILENT HTTPS any NOT LAN or VPNs
As can been seen, the port does not match to the description of the FW rule which caused the block. And I have more of this in my list. Is there any known bug in parsing the "decription" of the FW rules to the live view?
-
Hi,
I have just realized, that I have the same issue. It might catch the interest of someone more knowledgeable.
I´m running the latest production release: OPNsense 18.7.9-amd64 FreeBSD 11.1-RELEASE-p17 OpenSSL 1.0.2q 20 Nov 2018
The wrong labels are sometimes predefined ones, sometimes they are from the user defined ruleset.
I was trying to reboot, checked the logs, looked at pfctl -f /tmp/rules.debug, but have seen nothing suspicious.
The filtering works well. Seems like a reporting problem only (which is still annoying ;)) .
Here an example of a wrong entry:
It's a block of somebody trying to enter my network, but the label is completely wrong "pass loopback":
__timestamp__ Jan 3 22:50:49
ack 331199351
action [block]
anchorname
datalen 63
dir [in]
dst 89.132.120.129
dstport 36686
ecn
id 47036
interface igb1
ipflags none
label pass loopback
length 115
offset 0
proto 6
protoname tcp
reason match
ridentifier 0
rulenr 104
seq 1919712663:1919712726
src 172.217.18.78
srcport 443
subrulenr
tcpflags FPA
tcpopts
tos 0x0
ttl 122
urp 435
version 4
The same entry from the raw logs:
Jan 3 22:50:49 filterlog: 104,,,0,igb1,match,block,in,4,0x0,,122,47036,0,none,6,tcp,115,172.217.18.78,89.132.120.129,443,36686,63,FPA,1919712663:1919712726,331199351,435,,nop;nop;TS
Here a few more wrong entries:
WAN Jan 3 23:25:57 89.132.120.129:1222 1.1.1.1:53 udp Block bogon IPv4 networks from WAN
WLAN Jan 3 23:25:57 10.1.3.104:53513 10.1.3.1:53 udp USER_RULE: lan:2internetTcp
LANT Jan 3 23:25:53 10.1.1.50:50386 10.1.1.1:443 tcp USER_RULE: guestif:Allow UDP to Inet
LANT Jan 3 23:25:53 10.1.1.50:50384 10.1.1.1:443 tcp USER_RULE: guestif:Allow UDP to Inet
LANT Jan 3 23:25:53 10.1.1.50:50382 10.1.1.1:443 tcp USER_RULE: guestif:Allow UDP to Inet
LANT Jan 3 23:25:53 10.1.1.50:50380 10.1.1.1:443 tcp USER_RULE: guestif:Allow UDP to Inet
lo0 Jan 3 23:25:52 127.0.0.1:59071 127.0.0.1:2055 udp webConfiguratorlockout
lo0 Jan 3 23:25:52 127.0.0.1:59071 127.0.0.1:2055 udp virusprot overload table
Regards
Petrus
-
I am also experiencing this issue and can provide some examples if needed.
OPNsense 18.7.9-amd64
FreeBSD 11.1-RELEASE-p17
LibreSSL 2.7.4
-
This can happen after a reload of the firewall, since the log output only has a line number in it of the raw ruleset in /tmp/rules.debug (which might have changed in the meantime)
The log rule has a field "rulenr", which represents the line in
pfctl -vvPnf /tmp/rules.debug
There's not much we can do about that at the moment unfortunately.
-
Many thanks for the reply! Anything to "refresh" or restart to give the LiveView a new chance? Or only reboot will help?
-
Usually the entries will recover automatically, since the contents of /tmp/rules.debug are in sync.
Just to be sure, there aren't any notices about reload issues?
If you would like to validate manually, you can reload the ruleset using:
pfctl -f /tmp/rules.debug
new entries should have the right content, which still might be another rule preceding the one you think it should be.
-
Search term "reload":
File /var/log/system.log yielded no results.
OT:
...but I see a lot of (every 8h or so):
Jan 5 14:36:56 flowd_aggregate.py: vacuum done
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/interface_086400.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/interface_003600.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/interface_000300.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/interface_000030.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/dst_port_086400.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/dst_port_003600.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/dst_port_000300.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/src_addr_086400.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/src_addr_003600.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/src_addr_000300.sqlite
Jan 5 14:36:56 flowd_aggregate.py: vacuum /var/netflow/src_addr_details_086400.sqlite
...although netflow should not listen on any interface, according to GUI...
-
not related, but netflow is enabled in that case (
You could try to see if the gui presentation matches reality by searching for the rule number manually (using the command in my first response). Maybe you have an overlapping rule matching your traffic. I haven't seen issues myself on an active and unchanged ruleset (on new records)
-
Hi,
Thanks for all of your replies!
As I understand AdSchellevis argumentation, a reboot would certainly help, since only a modification in the ruleset can trigger this behavior.
Unfortunately, this is not the case on my box.
If I do a complete reboot, the wrong rules are still displayed.
BR Petrus
This can happen after a reload of the firewall, since the log output only has a line number in it of the raw ruleset in /tmp/rules.debug (which might have changed in the meantime)
The log rule has a field "rulenr", which represents the line in
pfctl -vvPnf /tmp/rules.debug
There's not much we can do about that at the moment unfortunately.