|
||||||||
For version 1.2b9, I have noticed in my firewall log that certain packets are blocked that should not be. However, the communication seems to work fine. For instance: filter log entries from status.php: Sep 13 16:28:40 m0n0wall ipmon[87]: 16:28:40.165694 dc0 @0:11 b 63.101.150.33,80 -> 10.0.0.102,3507 PR tcp len 20 40 -A IN That's from a local user (OPT1) to a web site, port 80. Why would that packet be blocked? Port 80 has worked all day, that's HTTP traffic. It seems like only occasional packets are randomly blocked, or at least logged as being blocked. And notice two of these DNS queries pass, and four are blocked, within microseconds of each other (yes I was experimenting with TCP DNS queries per the other thread): Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.066818 dc1 @300:2 p 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 48 -S K-S IN Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.067478 dc1 @300:2 p 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 48 -S K-S IN Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.067503 dc1 @0:11 b 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 42 -AP IN Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.068204 dc1 @0:11 b 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 40 -A IN Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.068428 dc1 @0:11 b 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 40 -A IN Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.068634 dc1 @0:11 b 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 42 -AP IN Sep 13 16:27:00 m0n0wall ipmon[87]: 16:27:00.069054 dc1 @0:11 b 10.0.0.104,3252 -> 10.0.0.3,53 PR tcp len 20 40 -A IN OPT1 is bridged to WAN, and the only firewall rules that are active on WAN or OPT1 are: allow UDP traffic from WAN to m0n0wall, port 53 allow TCP traffic from WAN to m0n0wall, port 53 block traffic from WAN to m0n0wall (10.0.0.3) allow traffic from all to all allow UDP traffic from OPT1 to m0n0wall, port 53 allow TCP traffic from OPT1 to m0n0wall, port 53 block traffic from OPT1 to m0n0wall (10.0.0.3) allow traffic from all to all All of these settings have been applied. ipfstat -nio section from status.php: @1 pass out quick on lo0 from any to any @2 pass out quick on rl0 proto udp from 192.168.1.2/32 port = 67 to any port = 68 @3 pass out quick on dc0 proto udp from any port = 68 to any port = 67 @4 pass out quick on rl0 from any to any keep state @5 pass out quick on dc0 from any to any keep state @6 pass out quick on dc1 from any to any keep state @7 block out log quick from any to any @1 pass in quick on lo0 from any to any @2 block in log quick from any to any with short @3 block in log quick from any to any with ipopt @4 pass in quick on rl0 proto udp from any port = 68 to 255.255.255.255/32 port = 67 @5 pass in quick on rl0 proto udp from any port = 68 to 192.168.1.2/32 port = 67 @6 block in log quick on dc0 from 192.168.1.0/24 to any @7 block in log quick on dc0 proto udp from any port = 67 to 192.168.1.0/24 port = 68 @8 pass in quick on dc0 proto udp from any port = 67 to any port = 68 @9 block in log quick on rl0 from !192.168.1.0/24 to any @10 skip 1 in proto tcp from any to any flags S/FSRA @11 block in log quick proto tcp from any to any @12 block in log quick on rl0 from any to any head 100 @1 pass in quick from 192.168.1.0/24 to 192.168.1.2/32 keep state group 100 @2 pass in quick from 192.168.1.0/24 to any keep state group 100 @13 block in log quick on dc0 from any to any head 200 @1 pass in log first quick proto udp from any port = 53 to 10.0.0.3/32 keep state group 200 @2 pass in log first quick proto tcp from any port = 53 to 10.0.0.3/32 keep state group 200 @3 block in log first quick from any to 10.0.0.3/32 group 200 @4 pass in quick from any to any keep state group 200 @14 block in log quick on dc1 from any to any head 300 @1 pass in log first quick proto udp from any to 10.0.0.3/32 port = 53 keep state group 300 @2 pass in log first quick proto tcp from any to 10.0.0.3/32 port = 53 keep state group 300 @3 block in log first quick from any to 10.0.0.3/32 group 300 @4 pass in quick from any to any keep state group 300 @15 block in log quick from any to any Thanks for any insight, - Steve Yates - ITS, Inc. - Sometimes the act of searching is more important than what you're searching for. ~ Taglines by Taglinator 4 - www.srtware.com ~ |