> -----Original Message----- > From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter- > owner@xxxxxxxxxxxxxxx] On Behalf Of Gáspár Lajos > Sent: Friday, August 26, 2011 2:13 AM > To: Jan Engelhardt > Cc: netfilter list > Subject: Re: Theoretical question: need for filter table in the > POSTROUTING chain > > Hi, > > 2011-08-26 09:56 keltezéssel, Jan Engelhardt írta: > >> > >>> How about putting a reject route in the kernel routing table? > >> Yeah.. that is an alternative... > >> But: > >> - I want to REJECT any tcp sessions with tcp-reset, > >> - and any other protocoll with icmp-admin-prohibited. > >> - I would like to do it in iptables/netfilter. > >> > >> The main question is: Why do not we have such a table in the > POSTROUTING chain? > > If they did not go through nat, the packet's computed state was most > > likely INVALID or UNTRACKED to begin with. And that you can already > > filter for in FORWARD. > I do not get it... > If a packet comes from the network then it is either goes to FORWARD or > to INPUT... (You can forget INPUT for now.) And there we have nat... > If a packet comes from the local computer then it leaves out on the > OUTPUT chain... And there we have nat again... > So every packet should be tracked at the POSTROUTING chain... > > Yes, I can filter at the FORWARD and the OUTPUT chain... But why can't > I > at the POSTROUTING??? By adding filtering support to the POSTROUTING hook you only get one benefit: Rules that apply to both locally generated traffic (OUTPUT) and forwarded traffic (FORWARD) do not need to be duplicated. Right? You do not get any other benefit. In some cases this may help to simplify the configuration, I agree. However, _usually_, you have distinct sets of rules for locally generated traffic and forwarded traffic, the overlapping is not that much. On top of that: - By adding one extra check (ie filter table) where you do not need it (POSTROUTING) - because you can achieve the same result by using another hook - you would waste CPU cycles. - Since we are talking about filtering (not NAT), if you apply filtering earlier in the data path (ie OUTPUT/FORWARD instead of POSTROUTING) you save again some CPU cycles. Anyway, adding such support is simple (if patching iptables and the kernel is an option you can consider). It is just matter of telling netfilter (and iptables) to use the filter table _also_ for the POSTROUTING hook (recompile, etc). /Chris > I do not seek alternatives... (I found them... :D) I want to know why > it is not "enabled" ??? > Thanx > > Swifty > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
