Re: Private traffic seen on public NATed interface - Linux 2.6.10-11 tested

[James MacLean <macleajb@ednet.ns.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 2137 bytes --]

Marius Mertens wrote:

> On Wednesday, March 16, 2005 1:49 PM,
> James MacLean wrote:
>
>> [...]
>> May I suggest someone else even try it at home :), or on a half busy
>> box? We _are_ honestly seeing this at different sites with different
>> rules, but with the common SNAT for private IP space.
>> [...]
>
>
> Sorry I cannot provide anything to solve your problem, but maybe you 
> want to check the following:
> I also had (and already have, I just ignore it at the moment) a quite 
> similar problem: Some packets that should have been modified by NAT 
> were not processed, but in the direction "Internet --> NATted Clients" 
> (exactly the opposite direction that makes problems on your setup) so 
> that missed packets hit the INPUT rules of my router.
> If you want to have more detailed information please see 
> http://lists.netfilter.org/pipermail/netfilter/2005-January/057795.html
> Now to the property you might want to check: All packets being not 
> correctly processed by NAT had the state INVALID. I am not sure 
> when/why the connection became INVALID, but since there has been 
> traffic in both directions before, it it unlikely that it was INVALID 
> in the first place.
> Perhaps your not processed packets are also considered INVALID?
> This is of course far away from a solution (since it is still unclear, 
> why they become INVALID), but if we can find further criteria that 
> applies to all these similar problems, maybe we are able to track it 
> down.
>
> Marius
>
Bingo. And thanks :). Yes, this is looking very similar to our 
situation. A small dump and the matching INVALID rule logging :

12:24:59.083117 IP 10.0.5.221.1672 > 64.202.98.35.http: F 
1992443149:1992443149(0) ack 2731371818 win 63513

Mar 16 12:24:5 the kernel: INVALID IN=eth1 OUT=eth0 SRC=10.0.5.221 
DST=64.202.98.35 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=15881 DF PROTO=TCP 
SPT=1672 DPT=80 WINDOW=63513 RES=0x00 ACK FIN URGP=0

Watching the logs on busy sites we see many of these :).

So now we know what it is, and we can simply apply INVALID rules if we 
need to. I wonder how long this has been going on :(.

thanks again,
JES


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3684 bytes --]