|
||||||||
Did you already try allowing fragmented packets in your LAN Rules? Holger > -----Ursprüngliche Nachricht----- > Von: Jeroen Visser [mailto:monowall at forty dash two dot nl] > Gesendet: Montag, 23. Januar 2006 17:20 > An: Tim Vaughan; m0n0wall at lists dot m0n0 dot ch > Betreff: Re: [m0n0wall] Re: Firewall weirdness (was: Feature > suggestion: > show related rule in firewall logs) > > > Tim, > > This could be your "problem" with the blocked traffic. > However, this leaves you > without a fix for your current problem. > > I myself had a hard time believing that these dropped packets > would not influence > the connections, but it turns out is really was correct after all. > > http://doc.m0n0.ch/handbook/faq-legit-traffic-dropped.html > > -- > Jeroen Visser. > > > > > On Mon, 23 Jan 2006 15:47:48 +0000, Tim Vaughan wrote > > Even with a rule explicitly allowing these packets through the LAN > > interface, I still get these entries: > > > > 15:39:57.850818 sis0 @0:13 b 192.168.0.14,80 -> > 192.168.1.35,34788 PR > > tcp len 20 60 -AS IN > > > > Could this be a hardware issue? I don't understand what could be > > doing the blocking. ICMP, smb, http etc. all work with 192.168.0.14 > > from a machine on that subnet. They don't work to the work > > 192.168.1.1/24 subnet though. > > I am using non-standard firmware for this machine (Linksys > NSLU2) - no > > idea why that would be a problem though. > > > > Tim > > > > On 1/22/06, Tim Vaughan <talltim at gmail dot com> wrote: > > > > Hi Tim... The feature you are requesting is already > available in m0n0wall. > > > > > > > > > > > > Diagnostics -> Logs -> Settings - Check "Show raw > filter logs" and save > > > > > > > > While you are there you should also check "Log packets > blocked by the > > > > default rule" at least for testing purposes. > > > > > > > > Then view the "Firewall logs" page again... > > > > > > > > Note that now, your firewall logs will contain a p > (pass), b (block) or > > > > r (reject) as well as the number of the rule that > matched the packet. > > > > > > > > Now, go to: http://your.m0n0.wall/exec.php > > > > > > > > enter: ipfstat -ion > > > > > > > > to locate the rule that matches your log entry. > > > > > > > > > Ok, thanks for that, it's really useful. This is the > offending entry: > > > > > > 23:05:41.532041 sis0 @0:13 b 192.168.0.14,80 -> > 192.168.1.44,54131 PR > > > tcp len 20 60 -AS IN > > > > > > With the corresponding rule: > > > > > > @13 block in log quick proto tcp from any to any > > > > > > which I'm guessing is the default rule that blocks > anything that isn't > > > explicity passed. The problem is that I have other Linux > servers on > > > that network which I can access perfectly well over the > VPN and the > > > LAN interface has the standard pass from any to any rule. > > > > > > Additionally, I get the following on my work m0n0wall: > > > > > > 21:50:39.187349 sis0 @0:16 b 192.168.1.44,53214 -> > 72.3.219.62,80 PR > > > tcp len 20 52 -AF IN > > > and > > > 22:12:05.772677 sis0 @0:16 b 192.168.1.44,53330 -> > 65.214.39.12,80 PR > > > tcp len 20 40 -AR IN > > > > > > With: > > > > > > @16 block in log quick proto tcp from any to any > > > > > > Which I guess is the default rule again. I don't have > block rules on > > > the LAN interface, so why are these packets logged as > being blocked? > > > > > > Tim > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch > > ____________ Virus checked by G DATA AntiVirusKit |