Analyzing DNAT traffic

Analyzing DNAT traffic

[Alex]

Hi,

I have DNAT set up for a few ports on a fedora14 box with
shorewall-4.4.11.1 for bittorrent traffic, and I'm still seeing quite
a bit of traffic that I think should be translated but is not. I had
initially posted this on the shorewall list, but it seems more
appropriate here.

How can I analyize this traffic to determine if it should be forwarded
on to its intended internal recipient, or if it is completely
unrelated traffic that should continue to be blocked?

I have a firewall with two interfaces connected to the Internet via a
cable modem. The destination ports are unknown to me; I'm using a
different port for the bittorrent dnat traffic. Here are a few sample
log entries for traffic I think should be translated:

[2373602.833434] Shorewall:ext2fw:REJECT:IN=eth0 OUT=
MAC=40:61:86:4e:84:09:00:21:a0:75:e3:12:08:00 SRC=221.192.199.46
DST=68.XXX.YYY.44 LEN=40 TOS=0x00 PREC=0x00 TTL=108 ID=256 DF
PROTO=TCP SPT=12200 DPT=27977 WINDOW=8192 RES=0x00 SYN URGP=0
[2373626.966318] Shorewall:ext2fw:REJECT:IN=eth0 OUT=
MAC=40:61:86:4e:84:09:00:21:a0:75:e3:12:08:00 SRC=123.30.133.59
DST=68.XXX.YYY.44 LEN=40 TOS=0x00 PREC=0x00 TTL=99 ID=256 PROTO=TCP
SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0

The .44 address is the address of the external interface to the
Internet on the firewall. Other log entries have similar ports, but
there is also quite a range of destination ports, and I'm not able to
correlate any of them to the output of "netstat -tnap" on the host
that is dnat'd.

Can you recommend options for tcpdump that might be used to trace the
traffic and see if it's traversing the firewall, or if the traffic
contains packets associated with that host and bittorrent?

Thanks,
Alex

Re: Analyzing DNAT traffic

["Oleg A. Arkhangelsky"]

04.03.2011, 23:13, "Alex" <mysqlstudent@gmail.com>:

> How can I analyize this traffic to determine if it should be forwarded
> on to its intended internal recipient, or if it is completely
> unrelated traffic that should continue to be blocked?

Could you please check, does such packets match the following
rule?

iptables -I FORWARD -m conntrack --ctstate INVALID -j LOG

-- 
wbr, Oleg.

Re: Analyzing DNAT traffic

[Alex]

Hi,

>> How can I analyize this traffic to determine if it should be forwarded
>> on to its intended internal recipient, or if it is completely
>> unrelated traffic that should continue to be blocked?
>
> Could you please check, does such packets match the following
> rule?
>
> iptables -I FORWARD -m conntrack --ctstate INVALID -j LOG

How will I be able to recognize such an entry in the logs? Is there a
way I can add a tag to the log entry so I can be sure?

Thanks,
Alex

Re: Analyzing DNAT traffic

[Jan Engelhardt]

On Saturday 2011-03-05 15:23, Alex wrote:

>Hi,
>
>>> How can I analyize this traffic to determine if it should be forwarded
>>> on to its intended internal recipient, or if it is completely
>>> unrelated traffic that should continue to be blocked?
>>
>> Could you please check, does such packets match the following
>> rule?
>>
>> iptables -I FORWARD -m conntrack --ctstate INVALID -j LOG
>
>How will I be able to recognize such an entry in the logs? Is there a
>way I can add a tag to the log entry so I can be sure?

See --log-prefix.

Re: Analyzing DNAT traffic

[Alex]

Hi,

>>> Could you please check, does such packets match the following
>>> rule?
>>>
>>> iptables -I FORWARD -m conntrack --ctstate INVALID -j LOG
>>
>>How will I be able to recognize such an entry in the logs? Is there a
>>way I can add a tag to the log entry so I can be sure?
>
> See --log-prefix.

Yes, thanks for that. It is matching some packets.

Mar  5 10:01:51 fc14 kernel: [2726254.099180] dnat invalid IN=eth1
OUT=eth0 SRC=192.168.1.7 DST=203.81.151.80 LEN=40 TOS=0x00 PREC=0x00
TTL=63 ID=0 DF PROTO=TCP SPT=39061 DPT=52759 WINDOW=0 RES=0x00 RST
URGP=0

Mar  5 10:08:11 fc14 kernel: [2726633.762301] dnat invalid IN=eth1
OUT=eth0 SRC=192.168.1.151 DST=69.171.224.11 LEN=52 TOS=0x00 PREC=0x00
TTL=63 ID=19662 DF PROTO=TCP SPT=48270 DPT=80 WINDOW=54 RES=0x00 ACK
FIN URGP=0

Mar  5 10:08:45 fc14 kernel: [2726667.362163] dnat invalid IN=eth1
OUT=eth0 SRC=192.168.1.151 DST=69.63.181.56 LEN=52 TOS=0x00 PREC=0x00
TTL=63 ID=19949 DF PROTO=TCP SPT=44230 DPT=80 WINDOW=98 RES=0x00 ACK
FIN URGP=0

The last two are just regular requests for access to facebook from
another PC on the internal network.

Thanks,
Alex

Re: Analyzing DNAT traffic

[Jan Engelhardt]

On Saturday 2011-03-05 16:12, Alex wrote:
>
>Yes, thanks for that. It is matching some packets.
>[...]
>Mar  5 10:08:11 fc14 kernel: [2726633.762301] dnat invalid IN=eth1
>OUT=eth0 SRC=192.168.1.151 DST=69.171.224.11 LEN=52 TOS=0x00 PREC=0x00
>TTL=63 ID=19662 DF PROTO=TCP SPT=48270 DPT=80 WINDOW=54 RES=0x00 ACK
>FIN URGP=0
>
>Mar  5 10:08:45 fc14 kernel: [2726667.362163] dnat invalid IN=eth1
>OUT=eth0 SRC=192.168.1.151 DST=69.63.181.56 LEN=52 TOS=0x00 PREC=0x00
>TTL=63 ID=19949 DF PROTO=TCP SPT=44230 DPT=80 WINDOW=98 RES=0x00 ACK
>FIN URGP=0
>
>The last two are just regular requests for access to facebook from
>another PC on the internal network.

nfct discovered that visiting facebook is an invalid waste of time —
a conclusion I consent to — and possibly implies to play a game
instead, say, Minecraft. :-)

Re: Analyzing DNAT traffic

["Oleg A. Arkhangelsky"]

05.03.2011, 18:13, "Alex" <mysqlstudent@gmail.com>:

> The last two are just regular requests for access to facebook from
> another PC on the internal network.

This packets can be out-of-order or duplicate packets with FIN flag.
They are not connected to any conntrack entry, so there is no way
to do NAT transformation for them.

-- 
wbr, Oleg.

Re: Analyzing DNAT traffic

[Alex]

Hi,

>> The last two are just regular requests for access to facebook from
>> another PC on the internal network.
>
> This packets can be out-of-order or duplicate packets with FIN flag.
> They are not connected to any conntrack entry, so there is no way
> to do NAT transformation for them.

I'm not sure if I'm misunderstanding what you are saying, or you're not clear.

I'm trying to dnat bittorrent traffic, but there are many rejects in
the kernel logs that I believe are a result of my dnat rules not being
correct, and I thought the rule below would help me isolate those
packets:

# iptables -I FORWARD -m conntrack --ctstate INVALID -j LOG
--log-prefix "dnat invalid "

there is a periodic match (maybe a few every other minute).

However, they are apparently matching packets that are not related to
my bittorrent traffic and shouldn't be dnat'd. How can I determine why
these facebook packets are invalid and why my bittorrent traffic is
not properly being dnat'd?

Thanks,
Alex