Question about conntrack

Question about conntrack

[Michele Petrazzo - Unipex]

Hi list,
I have a server that nat a network lan where there are some pcs. My
provider say me that I'm uploading contents from an high (5XXXX)
external udp port. For see if it's true :) and which lan ip do the
upload (of course excluding the server) I "tcpdump" the connection and I
see that yes, there is an upload that goes out from the wan (that has a
public IP) at that specific port, but no corresponding lan traffic on
the lan port.

Here are my question: why I see the traffic on that port only on the
external port? nat does also port translation?
Is there another, better, solution for look for the data that I need?

Thanks,
Michele

RE: Question about conntrack

[Gary Smith]

> Hi list,
> I have a server that nat a network lan where there are some pcs. My
> provider say me that I'm uploading contents from an high (5XXXX)
> external udp port. For see if it's true :) and which lan ip do the
> upload (of course excluding the server) I "tcpdump" the connection and
> I
> see that yes, there is an upload that goes out from the wan (that has a
> public IP) at that specific port, but no corresponding lan traffic on
> the lan port.
> 
> Here are my question: why I see the traffic on that port only on the
> external port? nat does also port translation?
> Is there another, better, solution for look for the data that I need?

Identify if it is the firewall or the lan by adding a logging rule to iptables.  We do this by setting something like this up when we really want to see what's going on (this will generate lots of data).

-I INPUT  -j LOG --log-prefix "FW I: "
-I FORWARD -j LOG --log-prefix "FW F: "
-I OUTPUT -j LOG --log-prefix "FW O: "

When finished:

-D INPUT  -j LOG --log-prefix "FW I: "
-D FORWARD -j LOG --log-prefix "FW F: "
-D OUTPUT -j LOG --log-prefix "FW O: "

If you think it's coming from the firewall itself, run "netstat -atunep" and see if there are any connections that match that port.  That should also list which app is using that port as well.

Question about conntrack

[Yury Batrakov]

Hello all!

I've got a couple of questiona about netfilter's connection tracker,
could someone clarify it to me?
1. When conntrack is being flushed? In /proc/net/ip_conntrack I see
lots of UNREPLIED connections, I reload conntrack kernel module but
see the table being filled with old entries. The same looks to happen
after rebooting Linux box.
2. Are UNREPLIED connections being wiped when number of connections to
track equals to conntrack's capacity? Some web resources tell they
are, but some tell otherwise. I tried to reduce conntrack's capacity
and saw that these connections aren't wiped and cause conntrack to
overflow is it bug or feature?
3. I played with NOTRACK target of table raw and discovered that if I
add a NOTRACK rule that matches with already established connections,
they stuck in table as unreplied. Most of them disappear when I set
net.ipv4.netfilter.ip_conntrack_tcp_loose to 0. Is it recommended to
kill existing unreplied connections in this way? Could it be any side
effect for new or currently established connections that don't match
NOTRACK?

Thanks in advance

Re: Question about conntrack

[Pablo Neira Ayuso]

Yury Batrakov wrote:
> Hello all!
> 
> I've got a couple of questiona about netfilter's connection tracker,
> could someone clarify it to me?
> 1. When conntrack is being flushed? In /proc/net/ip_conntrack I see
> lots of UNREPLIED connections, I reload conntrack kernel module but
> see the table being filled with old entries. The same looks to happen
> after rebooting Linux box.
> 2. Are UNREPLIED connections being wiped when number of connections to
> track equals to conntrack's capacity? Some web resources tell they
> are, but some tell otherwise. I tried to reduce conntrack's capacity
> and saw that these connections aren't wiped and cause conntrack to
> overflow is it bug or feature?

No, when the table gets full the selected conntracks are those that are
!ASSURED.

> 3. I played with NOTRACK target of table raw and discovered that if I
> add a NOTRACK rule that matches with already established connections,
> they stuck in table as unreplied. Most of them disappear when I set
> net.ipv4.netfilter.ip_conntrack_tcp_loose to 0. Is it recommended to
> kill existing unreplied connections in this way?

You may kill the entries using:

# conntrack -D -s IP -p tcp --dport xyz

See conntrack(8) for reference, or the conntrack-tools website.

> Could it be any side
> effect for new or currently established connections that don't match
> NOTRACK?

No, if you really only kill the conntracks that you don't need anymore.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

RE: question about conntrack

[Jason Opperisano]

> Just a quick question. Is there a tutorial/how-to/example for conntrack
> module??

http://netfilter.org/documentation/HOWTO//netfilter-extensions-HOWTO-3.html#ss3.3

should give you the basic idea.

> I've been using -m state ESTABLISHED, RELATED, NEW, and INVALID without
> doubts , but reading ponng I found conntrack module and I couldn
> undersant its usage..

essentially--it allows you to be much more granular in what you require to match a state entry.

with most of the POM stuff--if you can't figure out the point of it--you probably don't need it.

-j

question about conntrack

[Paulo Ricardo]

Hi guys 

Just a quick question. Is there a tutorial/how-to/example for conntrack
module??

I've been using -m state ESTABLISHED, RELATED, NEW, and INVALID without
doubts , but reading ponng I found conntrack module and I couldn
undersant its usage..


thanks in advance
-- 
Paulo Ricardo Bruck - consultor
tel 011 5031-4932  fone/fax 011 5034-1732  cel 011 9235-4327