conntrack output - question

conntrack output - question

[Gomathivinayagam Muthuvinayagam]

Conntrack classifies a packet to a flow based on protocol no, srcip,
destip, srcport, and destport.

A sample output is shown below,

[NEW] udp      17 30 src=192.168.2.100 dst=192.168.2.1 sport=57767
dport=53 [UNREPLIED] src=192.168.2.1 dst=192.168.2.100 sport=53
dport=57767

Here, what's the need of reply srcip, reply destip, reply srcport,
reply destport? (Since we can imply these information from original
srcp ip, original destip, original srcport, original destport)
Is it just for avoiding for confusion, or anyother reasons behind this?

Thanks & Regards,

Re: conntrack output - question

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Hi,

Le lundi 06 août 2012 à 22:38 -0700, Gomathivinayagam Muthuvinayagam a
écrit :
> Conntrack classifies a packet to a flow based on protocol no, srcip,
> destip, srcport, and destport.
> 
> A sample output is shown below,
> 
> [NEW] udp      17 30 src=192.168.2.100 dst=192.168.2.1 sport=57767
> dport=53 [UNREPLIED] src=192.168.2.1 dst=192.168.2.100 sport=53
> dport=57767
> 
> Here, what's the need of reply srcip, reply destip, reply srcport,
> reply destport? (Since we can imply these information from original
> srcp ip, original destip, original srcport, original destport)
> Is it just for avoiding for confusion, or anyother reasons behind this?

Think about NAT.

BR,
-- 
Eric Leblond 
Blog: http://home.regit.org/ - Portfolio: http://regit.500px.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: conntrack output - question

[Pablo Neira Ayuso]

On Mon, Aug 06, 2012 at 10:38:03PM -0700, Gomathivinayagam Muthuvinayagam wrote:
> Conntrack classifies a packet to a flow based on protocol no, srcip,
> destip, srcport, and destport.
> 
> A sample output is shown below,
> 
> [NEW] udp      17 30 src=192.168.2.100 dst=192.168.2.1 sport=57767
> dport=53 [UNREPLIED] src=192.168.2.1 dst=192.168.2.100 sport=53
> dport=57767
> 
> Here, what's the need of reply srcip, reply destip, reply srcport,
> reply destport? (Since we can imply these information from original
> srcp ip, original destip, original srcport, original destport)
> Is it just for avoiding for confusion, or anyother reasons behind this?

We need the reply tuple for NAT scenarios. In those cases, original
tuples does not match the reply tuple.