packets skipping dnat rule and someting else

packets skipping dnat rule and someting else

[Hans de Bruin]

Hi,

There are things happening in my firewall I do not understand.

The firewall has three networks: internet, dmz and lan. Hosts in de dmz 
and lan networks are SNATed on there way out onto the internet. In the 
dmz there is a host running rtorrent which I have told it should report 
the internet ip-address of the firewall to its clients. Torrent clients 
on the internet are DNATed to the host in the dmz. On average there are 
10 clients.

I see two types of packets running into the INPUT chain of the firewall 
I am not expecting there:

A packet I think should be on its way to de rtorrent-host in the dmz. 
DST contains my internet address an DPT has the port I am running 
rtorrent on:

[22734.688709] CHAINv4=in_int IN=eth3 OUT= 
MAC=00:30:18:a6:c0:f2:00:0e:00:00:00:01:08:00 SRC=186.207.156.227 
DST=92.254.124.152 LEN=40 TOS=0x00 PREC=0x00 TTL=112 ID=27025 DF 
PROTO=TCP SPT=62434 DPT=16881 WINDOW=0 RES=0x00 RST URGP=0

Wat is the above packet doing in the INPUT chain of the firewall?

A packet on its way out. The dmz host should send it to somewhere on the 
internet but not directly to the firewall adress.

[25139.574051] CHAINv4=in_dmz IN=br_dmz OUT= 
MAC=fe:ff:ff:ff:ff:ff:00:00:00:00:00:12:08:00 SRC=10.20.0.12 
DST=92.254.124.152 LEN=60 TOS=0x08 PREC=0x00 TTL=64 ID=48601 DF 
PROTO=TCP SPT=35639 DPT=16881 WINDOW=14600 RES=0x00 SYN URGP=0

?

Parts of my firewall script:

net_lan=10.10.0.0/16
net_dmz=10.20.0.0/16

if_int=eth3

ip_int=92.254.124.152
ip_darkstar=10.20.0.12

iptables -A PREROUTING -t nat -i $if_int -p tcp --dport 16881 -j DNAT 
--to-destination $ip_darkstar
iptables -A PREROUTING -t nat -i $if_int -p udp --dport 16881 -j DNAT 
--to-destination $ip_darkstar


iptables -A POSTROUTING -t nat -o $if_int -s $net_lan -j SNAT --to $ip_int
iptables -A POSTROUTING -t nat -o $if_int -s $net_dmz -j SNAT --to $ip_int

Should I add a port range to the SNAT rules?

-- 
Hans

Re: packets skipping dnat rule and someting else

["Oleg A. Arkhangelsky"]

24.09.2011, 17:59, "Hans de Bruin" <jmdebruin@xmsnet.nl>:

> [22734.688709] CHAINv4=in_int IN=eth3 OUT=
> MAC=00:30:18:a6:c0:f2:00:0e:00:00:00:01:08:00 SRC=186.207.156.227
> DST=92.254.124.152 LEN=40 TOS=0x00 PREC=0x00 TTL=112 ID=27025 DF
> PROTO=TCP SPT=62434 DPT=16881 WINDOW=0 RES=0x00 RST URGP=0

This packet doesn't belong to any valid connection from conntrack point of
view. Maybe this RST is duplicated and conntrack entry was destroyed a
moment before.

You can use -m conntrack --ctstate INVALID to catch such packets.

-- 
wbr, Oleg.

Re: packets skipping dnat rule and someting else

[Hans de Bruin]

On 09/24/2011 05:23 PM, "Oleg A. Arkhangelsky" wrote:
>
>
> 24.09.2011, 17:59, "Hans de Bruin"<jmdebruin@xmsnet.nl>:
>
>> [22734.688709] CHAINv4=in_int IN=eth3 OUT=
>> MAC=00:30:18:a6:c0:f2:00:0e:00:00:00:01:08:00 SRC=186.207.156.227
>> DST=92.254.124.152 LEN=40 TOS=0x00 PREC=0x00 TTL=112 ID=27025 DF
>> PROTO=TCP SPT=62434 DPT=16881 WINDOW=0 RES=0x00 RST URGP=0
>
> This packet doesn't belong to any valid connection from conntrack point of
> view. Maybe this RST is duplicated and conntrack entry was destroyed a
> moment before.
>
> You can use -m conntrack --ctstate INVALID to catch such packets.
>

Thanks, that rule has droped 570000 packets in my ignore chain in about 
two and a half day's. Now my logs are readable again.

Except for the RST packets there were also a lot of ACK FIN packets. I 
wonder if the 570000 packets are a small or a big percentage of the 
total number of tcp/ip sessions.

-- 
Hans