Ray => Thank you, again . . .
Ray Olszewski wrote: > > Thanks for the additional information. I see you have the rules you were > describing at the top of the input chain and before the only ACCEPT rule in > the output chains, so you should not be having order problems with them. > And all the interface specifications appear to be correct. > > The "problem" connections you show below are all from one IP address, > namely 192.168.13.103 . This causes me to wonder about one (admittedly > remote) possibility ... do you KNOW that the connections are actually > active with this ruleset in place? That is, might they be old connections > that were made before you added the blocking rules and restarted the > firewall, and are just sitting there idle because they haven't hit the MASQ > timeout yet? Yes, after I read your response, I checked and there are now *NO* tcp/udp 1214 connections to be found! Any idea what this timeout value is? I have been working on this, off and on, since 2200 last night. For those who are interested, this customer has a T-1 to the internet, and T-1's between multiple offices and -- omigosh! -- and the two owners' homes. tcp/udp 1214 is the dreaded Kazaa and we have no interest in managing security for this business with kids at home poking holes all over the place ;< > This feels to me like grasping at straws, but everything you've posted > (including the content at the URL you provided) looks right, so I'm reduced > to long shots. And I do know that restarting a firewall doesn't break > established MASQ'd connections. [ snip ] Yes, now, apparently, it works -- the brute force approach. It's that darn masquerading that confused me. Shouldn't we be able to block this inside the masquerading process? To complete this exercise, I want to back out the un-necessary chains. I should be able to block this at eth0, shouldn't I? Are the wan1 chains un-necessary? Also, I should be able to block this on one of many subnets, all channelled through eth0, right? Yes, I can just try this; but, since I am not in control of the tcp/udp 1214 connections, after every change I make, I need to wait and see . . . Further response? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
