On 01/02/13 08:38, Tanstaafl wrote: > Hi all, > > This has been bugging me for a while... > > I've googled, and can't seem to find a definitive answer to this > question... > > Lots of references to the Mangle table, but nothing that really explains > what this table is or does, and when or why I would want/need it. >
It allows you to mangle the low level bits of a packet. You only need it for routing gymnastics. > Currently, I have this in my rules (since forever, honestly don't even > remember where it came from): > > *mangle > :PREROUTING ACCEPT [1378800222:449528056411] > :INPUT ACCEPT [1363738727:447358082301] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [1221121261:1103241097263] > :POSTROUTING ACCEPT [1221116979:1103240864155] > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG > FIN,PSH,URG -j DROP > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j > DROP > -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP > COMMIT > # Completed on Sun Dec 11 14:11:01 2011 > The PREROUTING table happens before the routing decision is made. So those rules happen before the network stack decides what to do with a packet. Suppose, for example, that you forward all packets from your LAN to wherever they're supposed to go. You might want to alter the source IP of VPN traffic (which a priori is not from the LAN interface) so that it appears to come from the LAN before you decide whether or not to forward it. The POSTROUTING table is similar, only it happens after the packet's destination is set in stone. So you can, say, change the source IP address in the packet and still have it routed wherever it was going to go originally. > This is on a mail/web server with a static IP, it does not do any NAT > and does not act as a perimeter firewall, it only protects itself... > > Thanks for any pointers to tfm that explains this if there is one, or > just for a simple explanation if not... > I don't know what you were trying to do there, but it doesn't sound like you need it. You might have been trying to block packets in an invalid state. If so, consider using conntrack's --ctstate INVALID to drop them instead.
