Not NATed packets

Not NATed packets

[lukas]

Hi there
I have strange problem with NAT.
I have kernel 2.6.14.7-5 and iptables-1.3.3-6@2.6.14.7_5 and I use nat to 
share my home network on one public ip.
NAT configuration is simple but some packets are not NATed - on my public 
interface packets with source address of my internal (NATed) network 
appears and i have no clue what is wrong.

I tryed:
- to use SNAT instead of MASQUERADE
- diferent network cards
- diferent PC
- diferent kernel
- many diferent iptables configuration

Is anyone have a idea what can be wrong ?

tcpdump -i eth0 -n -vvv |grep 10.10.10
16:30:39.015880 IP (tos 0x0, ttl 127, id 28594, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F, cksum 
0x1623 (correct), 3885889894:3885889894(0) ack 3151418643 win 65535
16:32:14.987691 IP (tos 0x0, ttl 127, id 55701, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F, cksum 
0x1623 (correct), 0:0(0) ack 1 win 65535
16:34:14.996658 IP (tos 0x0, ttl 127, id 6582, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F, cksum 
0x1623 (correct), 0:0(0) ack 1 win 65535
16:36:50.209347 IP (tos 0x0, ttl 127, id 29938, offset 0, flags [DF], 
proto: TCP (6), length: 612) 10.10.10.104.3779 > 62.195.80.212.6881: FP 
4211640358:4211640930(572) ack 4076174940 win 65467
16:41:02.531491 IP (tos 0x0, ttl 127, id 12374, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.106.1224 > 217.96.89.139.80: R, cksum 
0x7e36 (correct), 1532046053:1532046053(0) ack 3047309971 win 0
17:03:00.361901 IP (tos 0x0, ttl 127, id 28252, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.106.1044 > 64.152.73.140.80: R, cksum 
0x6dba (correct), 2101015522:2101015522(0) ack 3552965504 win 0
17:08:21.299312 IP (tos 0x0, ttl 127, id 23907, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.4201 > 62.43.9.255.8601: F, cksum 
0x13b8 (correct), 3283228993:3283228993(0) ack 1610246617 win 65535
17:23:05.771272 IP (tos 0x0, ttl 127, id 54404, offset 0, flags [DF], 
proto: TCP (6), length: 612) 10.10.10.104.4388 > 80.224.86.144.11510: FP 
2712689086:2712689658(572) ack 3966653462 win 65467
17:41:30.080404 IP (tos 0x0, ttl 127, id 35623, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.4593 > 83.20.178.58.6881: F, 
cksum 0x8e61 (correct), 545571229:545571229(0) ack 4264072226 win 65467
17:43:30.086802 IP (tos 0x0, ttl 127, id 40899, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.4593 > 83.20.178.58.6881: F, 
cksum 0x8e61 (correct), 0:0(0) ack 1 win 65467
17:57:20.784291 IP (tos 0x0, ttl 127, id 12161, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.4836 > 81.232.66.10.27015: F, 
cksum 0x0f8a (correct), 1396937025:1396937025(0) ack 1135013016 win 65535
18:31:54.537480 IP (tos 0x0, ttl 127, id 39418, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.1324 > 81.232.66.10.27015: F, 
cksum 0xd48a (correct), 1916158042:1916158042(0) ack 1661945819 win 65535
18:51:11.680846 IP (tos 0x0, ttl 127, id 4651, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.112.1035 > 208.174.60.61.80: R, cksum 
0xec56 (correct), 877644103:877644103(0) win 0
18:51:11.680908 IP (tos 0x0, ttl 127, id 4652, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.112.1036 > 208.175.188.61.80: R, 
cksum 0xef09 (correct), 885278103:885278103(0) win 0
18:53:16.394703 IP (tos 0x0, ttl 127, id 33468, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.1566 > 80.224.86.144.11510: F, 
cksum 0x99b3 (correct), 3140707125:3140707125(0) ack 2527136685 win 65467
19:32:18.666316 IP (tos 0x0, ttl 127, id 13515, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.2041 > 84.77.24.199.4663: F, 
cksum 0xf208 (correct), 248022218:248022218(0) ack 2303565438 win 65535
19:33:33.908501 IP (tos 0x0, ttl 127, id 17092, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.104.2041 > 84.77.24.199.4663: F, 
cksum 0xf208 (correct), 0:0(0) ack 1 win 65535
03:54:45.613606 IP (tos 0x0, ttl  63, id 23506, offset 0, flags [DF], 
proto: TCP (6), length: 52) 10.10.10.2.2770 > 217.149.246.5.21: R, cksum 
0xe969 (correct), 3284961714:3284961714(0) ack 4025764409 win 1989 
<nop,nop,timestamp 155860672 485114788>
03:54:45.614335 IP (tos 0x0, ttl  63, id 27118, offset 0, flags [DF], 
proto: TCP (6), length: 52) 10.10.10.2.2208 > 217.153.11.26.2121: R, cksum 
0x1c13 (correct), 2275106033:2275106033(0) ack 1233749439 win 1728 
<nop,nop,timestamp 155860672 1617725243>
10:57:22.429824 IP (tos 0x0, ttl 127, id 2151, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1180 > 212.191.130.194.80: R, 
cksum 0x1aad (correct), 4150758452:4150758452(0) ack 3914748052 win 0
11:08:30.449915 IP (tos 0x0, ttl 127, id 3167, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1223 > 213.251.163.98.80: R, 
cksum 0xf015 (correct), 3114778154:3114778154(0) ack 666642057 win 0
11:08:30.450689 IP (tos 0x0, ttl 127, id 3168, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1257 > 213.251.163.213.80: R, 
cksum 0x2dd7 (correct), 769668751:769668751(0) ack 3053022552 win 0
11:08:30.469383 IP (tos 0x0, ttl 127, id 3169, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1222 > 213.251.163.213.80: R, 
cksum 0x0c96 (correct), 1485272056:1485272056(0) ack 3014076670 win 0
11:08:30.470110 IP (tos 0x0, ttl 127, id 3170, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1224 > 213.251.163.213.80: R, 
cksum 0x3d03 (correct), 2078528536:2078528536(0) ack 3018683596 win 0
11:08:30.470767 IP (tos 0x0, ttl 127, id 3171, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1226 > 213.251.163.213.80: R, 
cksum 0x6073 (correct), 4121342605:4121342605(0) ack 3017472308 win 0
11:08:30.471835 IP (tos 0x0, ttl 127, id 3172, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1220 > 213.251.134.64.80: R, 
cksum 0x2fcf (correct), 2946854746:2946854746(0) ack 1919357468 win 0
11:08:30.472480 IP (tos 0x0, ttl 127, id 3173, offset 0, flags [DF], 
proto: TCP (6), length: 40) 10.10.10.110.1225 > 213.251.134.64.80: R, 
cksum 0xed5c (correct), 1448158471:1448158471(0) ack 1917843528 win 0


Network conf
ip r
10.10.10.0/24 dev eth1  proto kernel  scope link  src 10.10.10.1
200.200.200.0/24 dev eth0  proto kernel  scope link  src 200.200.200.200
default via 200.200.200.10 dev eth0 onlink


my iptables configuration is :
iptables -F
iptables -X
iptables -Z

iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -p tcp -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A INPUT -p udp -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A INPUT -p icmp -j ACCEPT -m state --state ESTABLISHED,RELATED

iptables -t nat -F
iptables -t nat -X
iptables -t nat -Z

modprobe ipt_state
modprobe iptable_nat
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 10.10.10.0/24 -j DROP

iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 20 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p udp --dport 21 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 88 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 88 -i eth1 -s 10.10.10.2 -j ACCEPT
iptables -A INPUT -p tcp --dport 2222 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p udp --dport 25 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p tcp --dport 110 -i eth0 -d 200.200.200.200 -j ACCEPT
iptables -A INPUT -p icmp -i eth0 -d 200.200.200.200 -j ACCEPT

iptables -A INPUT -p tcp --dport 2222 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p udp --dport 25 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 110 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p udp --dport 110 -i eth1 -d 10.10.10.1 -j ACCEPT
iptables -A INPUT -p icmp -i eth1 -d 10.10.10.1 -j ACCEPT

iptables -A FORWARD -s 10.10.10.2 -j ACCEPT
iptables -A FORWARD -s 10.10.10.103 -j ACCEPT
iptables -A FORWARD -s 10.10.10.104 -m mac --mac-source 00:04:00:b3:3d:b2 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.105 -m mac --mac-source 00:40:00:8e:2c:8c 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.106 -m mac --mac-source 00:0a:00:04:c2:bc 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.107 -m mac --mac-source 00:4f:00:13:70:7a 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.108 -m mac --mac-source 00:40:00:6d:ea:34 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.109 -m mac --mac-source 00:40:00:cf:16:9c 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.110 -m mac --mac-source 00:4F:00:60:72:4E 
-j ACCEPT
iptables -A FORWARD -s 10.10.10.111  -j ACCEPT
iptables -A FORWARD -s 10.10.10.112 -m mac --mac-source 00:10:00:A2:98:1F 
-j ACCEPT

iptables -A FORWARD -d 10.10.10.2 -j ACCEPT
iptables -A FORWARD -d 10.10.10.103 -j ACCEPT
iptables -A FORWARD -d 10.10.10.104 -j ACCEPT
iptables -A FORWARD -d 10.10.10.105 -j ACCEPT
iptables -A FORWARD -d 10.10.10.106 -j ACCEPT
iptables -A FORWARD -d 10.10.10.107 -j ACCEPT
iptables -A FORWARD -d 10.10.10.108 -j ACCEPT
iptables -A FORWARD -d 10.10.10.109 -j ACCEPT
iptables -A FORWARD -d 10.10.10.110 -j ACCEPT
iptables -A FORWARD -d 10.10.10.111 -j ACCEPT
iptables -A FORWARD -d 10.10.10.112 -j ACCEPT


Please Help
Lukas

Re: Not NATed packets

[Petr Pisar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lukas@tank.eu.org wrote:
> I have strange problem with NAT.
Me too.

> I have kernel 2.6.14.7-5 and iptables-1.3.3-6@2.6.14.7_5 and I use nat
Tested with 2.6.11 and 2.6.16.4.

> NAT configuration is simple but some packets are not NATed - on my
> public interface packets with source address of my internal (NATed)
> network appears and i have no clue what is wrong.
I have very simple rules too. nat/PREROUTING is empty and
nat/POSTROUTING contains only one rule with MASQUARADE target on
interface with public IP (Policies are ACCEPT). I don't use ROUTE target
anywhere.

> 16:30:39.015880 IP (tos 0x0, ttl 127, id 28594, offset 0, flags [DF],
> proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F,
> cksum 0x1623 (correct), 3885889894:3885889894(0) ack 3151418643 win 65535
Exactly. I can see only FIN packets which are not translated. After
looking into conntrack table, I think MASQ ignores FIN packets that are
missing in conntrack table (Is it INVALID or NEW state?).

Very strange behaviour have counters too. These strange packets are not
loggable after MASQ rule. It seems like a bug.

- -- Petr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFES+UBuR4f4nEwzHIRArlUAKCQ9d9+f8bpcsboqoJOih6zndijEACfWOcV
E/15jUu11M4BE0mfuZztTtk=
=h4uY
-----END PGP SIGNATURE-----

Re: Not NATed packets

[lukas]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> lukas@tank.eu.org wrote:
>> I have strange problem with NAT.
> Me too.
>
>> I have kernel 2.6.14.7-5 and iptables-1.3.3-6@2.6.14.7_5 and I use nat
> Tested with 2.6.11 and 2.6.16.4.
>
>> NAT configuration is simple but some packets are not NATed - on my
>> public interface packets with source address of my internal (NATed)
>> network appears and i have no clue what is wrong.
> I have very simple rules too. nat/PREROUTING is empty and
> nat/POSTROUTING contains only one rule with MASQUARADE target on
> interface with public IP (Policies are ACCEPT). I don't use ROUTE target
> anywhere.
>
>> 16:30:39.015880 IP (tos 0x0, ttl 127, id 28594, offset 0, flags [DF],
>> proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F,
>> cksum 0x1623 (correct), 3885889894:3885889894(0) ack 3151418643 win 65535
> Exactly. I can see only FIN packets which are not translated. After
> looking into conntrack table, I think MASQ ignores FIN packets that are
> missing in conntrack table (Is it INVALID or NEW state?).
>
> Very strange behaviour have counters too. These strange packets are not
> loggable after MASQ rule. It seems like a bug.

I test it also on kernel 2.4.32-6 and its bad too.

Re: Not NATed packets

[Pascal Hambourg]

Hello,

lukas@tank.eu.org a écrit :
[...]
>> Exactly. I can see only FIN packets which are not translated. After
>> looking into conntrack table, I think MASQ ignores FIN packets that are
>> missing in conntrack table (Is it INVALID or NEW state?).
[...]
> I test it also on kernel 2.4.32-6 and its bad too.

Are you sure ? I'm surprised. Where did you get this kernel from ?
I just tested on a custom kernel 2.4.32 built from kernel.org sources 
(almost standard, just a few Netfilter patch-o-matic add-ons). And my 
conclusion is that unexpected TCP FIN or RST packets are classified NEW 
by the connection tracking, thus creating an entry in the conntrack/NAT 
table /proc/net/ip_conntrack. However, unexpected ICMP packets such as 
Echo Reply or Destination Unreachable are classified INVALID.

Re: Not NATed packets

[Petr Pisar]

Petr Pisar wrote:
> lukas@tank.eu.org wrote:
> 
>>NAT configuration is simple but some packets are not NATed - on my
>>public interface packets with source address of my internal (NATed)
>>network appears and i have no clue what is wrong.
> 
> 
>>16:30:39.015880 IP (tos 0x0, ttl 127, id 28594, offset 0, flags [DF],
>>proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F,
>>cksum 0x1623 (correct), 3885889894:3885889894(0) ack 3151418643 win 65535
> 
> Exactly. I can see only FIN packets which are not translated. After
> looking into conntrack table, I think MASQ ignores FIN packets that are
> missing in conntrack table (Is it INVALID or NEW state?).
> 

So, I'm able to reproduce this bug. Simply send untracked FIN pakcet 
from intranet station to the Internet:

$ hping2 -c 1 -F 1.2.3.4
HPING 1.2.3.4 (eth1 1.2.3.4): F set, 40 headers + 0 data bytes

--- 1.2.3.4 hping statistic ---
1 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

And dump traffic on your gateway:

$ tcpdump -i ppp0 -n net  192.168.0.0/24
tcpdump: listening on ppp0
20:30:36.304397 192.168.0.2.1039 > 1.2.3.4.0: F 2063212909:2063212909(0) 
win 512


> Very strange behaviour have counters too. These strange packets are not
> loggable after MASQ rule. It seems like a bug.
> 

Here is my POSTROUTING chain (ppp0 is public interface):

Chain POSTROUTING (policy ACCEPT 783 packets, 126K bytes)
  pkts bytes target     prot opt in     out     source 
destination
   897 54437 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 2 level 4 prefix `PRE'
  4531  365K MASQUERADE  all  --  *      ppp0    0.0.0.0/0 
0.0.0.0/0
    38  2258 LOG        all  --  *      *       0.0.0.0/0 
0.0.0.0/0           LOG flags 2 level 4 prefix `POST'

and after doing this excercise I can't see any change on counters in 
POSTROUTING chain. Naturaly I can't see anything in the kernel log (as 
you can see, I log everything before MASQ and after that).

I seems, these magic packets are completly bypassing POSTROUTING chain.

I found out too that TCP traffic goes inside this chain only with first 
SYN packet. After that there the packets are I don't see them anymore. 
Is it normal?

-- Petr

Re: Not NATed packets

[Petr Pisar]

lukas@tank.eu.org wrote:
> NAT configuration is simple but some packets are not NATed - on my 
> public interface packets with source address of my internal (NATed) 
> network appears and i have no clue what is wrong.
> 
> tcpdump -i eth0 -n -vvv |grep 10.10.10
> 16:30:39.015880 IP (tos 0x0, ttl 127, id 28594, offset 0, flags [DF], 
> proto: TCP (6), length: 40) 10.10.10.104.3689 > 83.29.48.50.6881: F, 
> cksum 0x1623 (correct), 3885889894:3885889894(0) ack 3151418643 win 65535

So, I have one workaround. These magic packets are INVALID from point of 
state module's view. Therefore this rules

   5   200 LOG        all  --  *      ppp0    0.0.0.0/0 
0.0.0.0/0           state INVALID LOG flags 2 level 4 prefix `FWD-INVALID'
     1    40 REJECT     all  --  *      ppp0    0.0.0.0/0 
0.0.0.0/0           state INVALID reject-with icmp-admin-prohibited

where ppp0 is nating device can log and discard this packets.

I'm not sure if any INVALID packet can also be considered as a health 
packet. Can you see any false positivities? (I know, that these packets 
can occure, when interface with dynamicly assignes address changes its 
IP address during established TCP connection, but then we are not able 
to repair this state [i.e. close connection on both sides with proper 
source IP] either. Therefore we can consider following packets as realy 
invalid.)

-- Petr

Re: Not NATed packets

[Pascal Hambourg]

Petr Pisar a écrit :
> 
> and after doing this excercise I can't see any change on counters in 
> POSTROUTING chain. Naturaly I can't see anything in the kernel log (as 
> you can see, I log everything before MASQ and after that).
> 
> I seems, these magic packets are completly bypassing POSTROUTING chain.
> 
> I found out too that TCP traffic goes inside this chain only with first 
> SYN packet. After that there the packets are I don't see them anymore. 
> Is it normal?
> 
> So, I have one workaround. These magic packets are INVALID from point of 
> state module's view.

Connection tracking state is the key to explain all that you observed.
Only NEW packets can create an entry in the connection tracking table 
(which contents can been seen through /proc/net/ip_conntrack) and can go 
through the 'nat' chains. That's why :
- INVALID packets bypass the nat chains, thus aren't NATed nor counted
- only the first NEW packet of a connection, which is usually a SYN in 
TCP connections, goes through the nat chains. Duplicate SYN, although 
NEW too, or subsequent packets belonging (ESTABLISHED) or related 
(RELATED) to the same connection in either direction don't. However all 
get automatically NATed according to the conntrack entry in a way 
determined by how the first packet was NATed.

> 
> I'm not sure if any INVALID packet can also be considered as a health 
> packet. Can you see any false positivities?

Unlike malformed packets which the experimental "unclean" match tries to 
detect, INVALID packets are not "unhealthy" in nature, they're just 
unexpected. And yes, false positive can occur. With kernels older than 
2.4.29, some locally-generated ICMP replies are wrongly considered 
INVALID instead of RELATED.

Re: Not NATed packets

[Petr Pisar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal a wrote:
> Petr Pisar a écrit :
>>
> Only NEW packets can create an entry in the connection tracking table
> (which contents can been seen through /proc/net/ip_conntrack) and can go
> through the 'nat' chains. That's why :
> - INVALID packets bypass the nat chains, thus aren't NATed nor counted
> - only the first NEW packet of a connection, which is usually a SYN in
> TCP connections, goes through the nat chains. Duplicate SYN, although
> NEW too, or subsequent packets belonging (ESTABLISHED) or related
> (RELATED) to the same connection in either direction don't. However all
> get automatically NATed according to the conntrack entry in a way
> determined by how the first packet was NATed.

Thanks for hint. I skipped notice in iptables man page about nat filter
and NEW packets, that explains this behaviour.

>>
>> I'm not sure if any INVALID packet can also be considered as a health
>> packet. Can you see any false positivities?
> 
> Unlike malformed packets which the experimental "unclean" match tries to
> detect, INVALID packets are not "unhealthy" in nature, they're just
> unexpected. And yes, false positive can occur.

Yes, of course (e.g. valid FIN packet looses somewhere after NAT, client
retransmits it and iptables will consider this second FIN as INVALID. Or
does nefilter remeber for this sitation?).

Maybe I should explain whole scenario to you:

I have a provider which connection is terminated with PPP device on my
router. I have assigned only one public dynamic IP. Therefore I
masquerade all packet originating in my local network. The problem is
when packet with source IP different from now assigned public address is
sent from ppp0 device to the provider, the provider will terminate the
PPP connection.

If I have one invalid packet, then it will not be SNATed, provider close
connection, ppp0 link will be going down, iptables flush conntrack
table, pppd redial provider, I get new IP, all applications in local
network retransmitte TCP packets, netfiler on router recognise them as
INVALID, it will not NATed them, provider close conncetion again and so
on. The pppd deamon begin throthling and connection become unusable.

Therefore I need be sure, all packets leaving ppp0 device have right
public IP.

- --Petr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEW4qruR4f4nEwzHIRAugmAKCSQ6jKEXkrEPDcMQWFxS3H1Lvt5wCfRoZc
asBbX5Bird0l/wfD7ipJbAc=
=mcrc
-----END PGP SIGNATURE-----