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