In article <[EMAIL PROTECTED]>,
Derrik Pates <[EMAIL PROTECTED]> wrote:
>It would appear the mangle5hooks patch has been applied to the mainline
>kernel as part of that update. Now mangle targets can be used on all 5
>hooks (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING).
Any chance that we could get 'filter' targets in all five places as well?
Suppose I want to migrate rules directly from ipchains to iptables,
because I don't want to have to rewrite ~235 tested and verified ipchains
firewall rules from scratch just to use one new iptables feature.
I might use the following mappings:
ipchains input rule -> iptables -t mangle PREROUTING rule
(except REDIRECT, which is -t nat)
ipchains forward rule -> iptables -t filter FORWARD rule
ipchains output rule -> iptables -t mangle POSTROUTING rule
(unless you are using SNAT or MASQUERADE)
mangle-PREROUTING is called first when all incoming packets are received
for every packet, so it works reasonably well as a replacement for
ipchains-compatible input filtering (assuming your actual INPUT chain
in the forward table has policy ACCEPT). filter-FORWARD is close enough
to ipchains forward for my purposes (I usually only have one forward
rule, and never more than four, out of rule sets ranging in size from
188 to 312 rules).
For ipchains output rules I seem to be stuck. There is
mangle-POSTROUTING, which is the closest thing to the ipchains output
chain, but nat-POSTROUTING is called after it, which means that any
changes to the packet done by outgoing NAT (especially MASQ) can't be
filtered at all. Logically, there should be a POSTROUTING chain in the
filter table which deals with this.
The first thing in my ipchains output chain is usually a sanity check to
make sure that I'm not sending packets with an inappropriate source
address. I seem to have nowhere to put this check in iptables.
Historically this check has been necessary as Linux networking never seems
to get it right in non-trivial cases--I have dropped many thousands of
outgoing packets over the years in places where they just should not be.
Especially bad problems occur when MASQ is combined with dynamic changes
to the routing table or policy routing, and there was a really mysterious
bug in the NFS kernel server code that would cause it to start sending
replies via random interfaces despite the fact that such routing disagrees
with the interface address, the routing table, the origin of the request
packet, and all common sense. ipchains could catch all of these bugs
easily, but I can't have the same confidence in iptables because it lacks
filter-POSTROUTING.
I and some of my clients have to deal with some ISP's with fairly
draconian policies about incorrect source addresses on packets.
That policy is: disconnect subscriber, wait about six hours, leave
rude voicemail, close ISP office, wait for someone to call back and ask
for reconnection during business hours. If Linux starts spewing wrong
packets on a Friday, I could be offline for an entire weekend.
--
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
