Michael -- 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).
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. 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). 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
