Michael -- 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? 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. At 12:29 PM 6/15/02 -0500, Michael D. Schleif wrote: >Ray => > >Thank you, for your participation. > >Ray Olszewski wrote: > > > > Your report is a bit fragmentary, but even so, the input- and output-chain > > rules you propose look like they should work. (I'm not sure about the > > forward-chain rules because I'm a bit fuzzy on whether and when NAT changes > > the apparent source address). > >That is why I did not go into more detail first. I am thinking that I >am missing something very simple, very profound ;> > > > But as you know, evaluating rules on a standalone basis doesn't work; > > packets traverse each chain and get handled by the FIRST matching rule, not > > the most specific one. And although you are inserting these rules, you > > don't specify a place in the chain, so they go at the end. My first > > thought, then, is that the offending packets never reach these rules, > > instead being passed by some eariler rule in each chain. The simplest test > > for this hypothesis would be to change the "-I" parts to "-I 1", so each > > candidate rule is the first rule in its chain, not its last. > >OK, look here: > > <http://www.helices.org/tmP/mcaI/1214.txt> > >Since there are several rules involved, I have not tried the '-I 1' yet; >but, looking at these chains, I do not see the necessity. > > > Based on the goals you list, I'd try using the input chain to block the > > outgoing 1214 connection and the output chain to block the incoming ones > > (though I'm not exactly clear on how any incoming ones might get in, given > > that the LAN is NAT'd -- you'd need to port forward incoming connections to > > port 1214, no? -- and your "evidence of the failure" only lists outgoing > > connections). > >Yes, there is partial success. Clearly, I have successfully blocked >both incoming tcp 1214 and udp 1214 at wan1 -- however, once I find the >all-or-nothing solution, then I want to back off of wan1 and block these >only at eth0 and only for specific subnets attached thereto. > >The above link demonstrates my usage of forward, input and output chains >-- yet, internal systems continue to connect to remote tcp 1214 !?!? > >What do you think? > > > > At 10:30 AM 6/15/02 -0500, Michael D. Schleif wrote: > > > > >"Michael D. Schleif" wrote: > > > > > > > > how do we stop masqueraded connections to a given remote port? > > > > > > > > this does not work in /etc/ipchains.forward: > > > > > > > > $IPCH -I forward -j DENY -p udp -s 192.168.0.0/16 -d 0.0.0.0 1214 > > > > $IPCH -I forward -j DENY -p tcp -s 192.168.0.0/16 -d 0.0.0.0 1214 > > > > > > > > what do you think? > > > > > >I have also tried these _without_ success: > > > > > >$IPCH -I input -j DENY -p udp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i eth0 > > >$IPCH -I input -j DENY -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i eth0 > > >$IPCH -I input -j DENY -p udp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i wan1 > > >$IPCH -I input -j DENY -p tcp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i wan1 > > >$IPCH -A output -j DENY -p udp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i eth0 > > >$IPCH -A output -j DENY -p tcp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i eth0 > > >$IPCH -A output -j DENY -p udp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i wan1 > > >$IPCH -A output -j DENY -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i wan1 > > > > > > > > >This is evidence of the failure: > > > > > ># netstat -Mn | grep 1214 > > >tcp 137:51.51 192.168.13.103 213.166.63.97 4680 -> 1214 > > >(64280) > > >tcp 96:29.21 192.168.13.103 213.166.61.21 4431 -> 1214 > > >(63842) > > >tcp 175:44.59 192.168.13.103 64.157.147.70 4732 -> 1214 > > >(64369) > > >tcp 195:15.28 192.168.13.103 24.222.82.41 4845 -> 1214 > > >(64544) > > >tcp 14:45.23 192.168.13.103 200.243.17.204 4349 -> 1214 > > >(63696) > > >tcp 75:17.67 192.168.13.103 67.233.168.173 4565 -> 1214 > > >(64089) > > >tcp 92:51.49 192.168.13.103 217.224.26.124 4603 -> 1214 > > >(64165) > > >tcp 124:53.85 192.168.13.103 213.166.62.57 4648 -> 1214 > > >(64231) > > >tcp 53:51.02 192.168.13.103 80.14.23.48 4504 -> 1214 > > >(63975) > > >tcp 40:34.36 192.168.13.103 12.87.135.40 4314 -> 1214 > > >(63624) > > >tcp 180:46.91 192.168.13.103 213.166.56.209 4714 -> 1214 > > >(64343) > > > > > > > > >This is what I want to accomplish: > > > > > >[1] I do *not* want to block tcp 1214 nor udp 1214 at the external > > >interface (wan1) > > > > > >[2] I want to deny both tcp 1214 and udp 1214 connections _from_ the > > >internal interface (eth0) > > > > > >[3] I want to deny both tcp 1214 and udp 1214 connections _to_ the > > >internal interface (eth0) > > > > > >Any ideas? > -- -----------------------------------------------"Never tell me the odds!"-------------- Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] ------------------------------------------------------------------------------------------- _______________________________________________________________ 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
