| 1 |
On 01/02/13 08:38, Tanstaafl wrote: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> This has been bugging me for a while... |
| 5 |
> |
| 6 |
> I've googled, and can't seem to find a definitive answer to this |
| 7 |
> question... |
| 8 |
> |
| 9 |
> Lots of references to the Mangle table, but nothing that really explains |
| 10 |
> what this table is or does, and when or why I would want/need it. |
| 11 |
> |
| 12 |
|
| 13 |
It allows you to mangle the low level bits of a packet. You only need it |
| 14 |
for routing gymnastics. |
| 15 |
|
| 16 |
|
| 17 |
> Currently, I have this in my rules (since forever, honestly don't even |
| 18 |
> remember where it came from): |
| 19 |
> |
| 20 |
> *mangle |
| 21 |
> :PREROUTING ACCEPT [1378800222:449528056411] |
| 22 |
> :INPUT ACCEPT [1363738727:447358082301] |
| 23 |
> :FORWARD ACCEPT [0:0] |
| 24 |
> :OUTPUT ACCEPT [1221121261:1103241097263] |
| 25 |
> :POSTROUTING ACCEPT [1221116979:1103240864155] |
| 26 |
> -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG |
| 27 |
> FIN,PSH,URG -j DROP |
| 28 |
> -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j |
| 29 |
> DROP |
| 30 |
> -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP |
| 31 |
> -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP |
| 32 |
> COMMIT |
| 33 |
> # Completed on Sun Dec 11 14:11:01 2011 |
| 34 |
> |
| 35 |
|
| 36 |
The PREROUTING table happens before the routing decision is made. So |
| 37 |
those rules happen before the network stack decides what to do with a |
| 38 |
packet. |
| 39 |
|
| 40 |
Suppose, for example, that you forward all packets from your LAN to |
| 41 |
wherever they're supposed to go. You might want to alter the source IP |
| 42 |
of VPN traffic (which a priori is not from the LAN interface) so that it |
| 43 |
appears to come from the LAN before you decide whether or not to forward it. |
| 44 |
|
| 45 |
The POSTROUTING table is similar, only it happens after the packet's |
| 46 |
destination is set in stone. So you can, say, change the source IP |
| 47 |
address in the packet and still have it routed wherever it was going to |
| 48 |
go originally. |
| 49 |
|
| 50 |
|
| 51 |
> This is on a mail/web server with a static IP, it does not do any NAT |
| 52 |
> and does not act as a perimeter firewall, it only protects itself... |
| 53 |
> |
| 54 |
> Thanks for any pointers to tfm that explains this if there is one, or |
| 55 |
> just for a simple explanation if not... |
| 56 |
> |
| 57 |
|
| 58 |
I don't know what you were trying to do there, but it doesn't sound like |
| 59 |
you need it. You might have been trying to block packets in an invalid |
| 60 |
state. If so, consider using conntrack's --ctstate INVALID to drop them |
| 61 |
instead. |
Archives