Catching un-DNAT'ed packets

Catching un-DNAT'ed packets

[Покотиленко Костик]

Hi.

Is it possible to catch un-DNAT'ed packets with iptables' -j ULOG
target? Where does the un-DNAT occurs and is there table/chain that is
processed after un-DNAT?

The problem I have is that replay packets got catched with real source
address, not the one the client has initially connected to. I was
catching replay packets in mangle/POSTROUTING.


-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: Catching un-DNAT'ed packets

[Pascal Hambourg]

Hello,

Pokotilenko Kostik a écrit :
> 
> Is it possible to catch un-DNAT'ed packets with iptables' -j ULOG
> target?

I'm afraid no.

> Where does the un-DNAT occurs and is there table/chain that is
> processed after un-DNAT?

In 2.4 kernels, when DNAT occurs in the PREROUTING chain, un-DNAT occurs 
at the same place as (and in place of) the POSTROUTING chain of the 
'nat' table, and there is no chain after it. In 2.4 kernels >= 2.4.19, 
when DNAT occurs in the OUTPUT chain, un-DNAT occurs after the INPUT 
chain of the 'filter' table, and there is no chain after it either. I 
suppose it has not changed in 2.6 kernels.

> The problem I have is that replay packets got catched with real source
> address, not the one the client has initially connected to. I was
> catching replay packets in mangle/POSTROUTING.

The POSTROUTING chain of the 'mangle' table is just before the un-DNAT 
place.

Re: Catching un-DNAT'ed packets

[Покотиленко Костик]

В Вто, 26/12/2006 в 12:09 +0100, Pascal Hambourg пишет:

> > Where does the un-DNAT occurs and is there table/chain that is
> > processed after un-DNAT?
> 
> In 2.4 kernels, when DNAT occurs in the PREROUTING chain, un-DNAT occurs 
> at the same place as (and in place of) the POSTROUTING chain of the 
> 'nat' table, and there is no chain after it. In 2.4 kernels >= 2.4.19, 
> when DNAT occurs in the OUTPUT chain, un-DNAT occurs after the INPUT 
> chain of the 'filter' table, and there is no chain after it either. I 
> suppose it has not changed in 2.6 kernels.
> 
> > The problem I have is that replay packets got catched with real source
> > address, not the one the client has initially connected to. I was
> > catching replay packets in mangle/POSTROUTING.
> 
> The POSTROUTING chain of the 'mangle' table is just before the un-DNAT 
> place.

Thanks for the replay. You just confirmed my thoughts. It's really
strange to have a need solution for which is not invented yet :-/. I'm
not used to be one of the first in this area :)

So, this is subject for a wishlist...

-- 
Покотиленко Костик <casper@meteor.dp.ua>

iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Покотиленко Костик]

Hi.

After analizing the situation I have come to decide to request NEW TABLE
in iptables.

Considering the scheme at:

http://www.meteor.dp.ua/casper/firewill.pdf

how would I make a "feature request" to ask for, say, "mangle2" table
that is just after "nat" in POSTROUTING? The only reason for this move
is the need for ability to catch un-DNAT'ed packets with -j ULOG or
(better) to -j QUEUE.

В Вто, 26/12/2006 в 12:09 +0100, Pascal Hambourg пишет:
> Hello,
> 
> Pokotilenko Kostik a écrit :
> > 
> > Is it possible to catch un-DNAT'ed packets with iptables' -j ULOG
> > target?
> 
> I'm afraid no.
> 
> > Where does the un-DNAT occurs and is there table/chain that is
> > processed after un-DNAT?
> 
> In 2.4 kernels, when DNAT occurs in the PREROUTING chain, un-DNAT occurs 
> at the same place as (and in place of) the POSTROUTING chain of the 
> 'nat' table, and there is no chain after it. In 2.4 kernels >= 2.4.19, 
> when DNAT occurs in the OUTPUT chain, un-DNAT occurs after the INPUT 
> chain of the 'filter' table, and there is no chain after it either. I 
> suppose it has not changed in 2.6 kernels.
> 
> > The problem I have is that replay packets got catched with real source
> > address, not the one the client has initially connected to. I was
> > catching replay packets in mangle/POSTROUTING.
> 
> The POSTROUTING chain of the 'mangle' table is just before the un-DNAT 
> place.
> 
> 
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Jan Engelhardt]

>http://www.meteor.dp.ua/casper/firewill.pdf
>
>how would I make a "feature request" to ask for, say, "mangle2" table
>that is just after "nat" in POSTROUTING? The only reason for this move
>is the need for ability to catch un-DNAT'ed packets with -j ULOG or
>(better) to -j QUEUE.

And  -t nat -A POSTROUTING -m conntrack ! --ctstate DNAT
as a last rule won't do?


	-`J'
-- 

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Покотиленко Костик]

В Птн, 26/01/2007 в 12:24 +0100, Jan Engelhardt пишет:
> >http://www.meteor.dp.ua/casper/firewill.pdf
> >
> >how would I make a "feature request" to ask for, say, "mangle2" table
> >that is just after "nat" in POSTROUTING? The only reason for this move
> >is the need for ability to catch un-DNAT'ed packets with -j ULOG or
> >(better) to -j QUEUE.
> 
> And  -t nat -A POSTROUTING -m conntrack ! --ctstate DNAT
> as a last rule won't do?

This will (probably) catch packets that hasn't been DNAT'ed.
BUT, the thing I need it to catch replay packets that has already passed
"un-DNAT" procedure.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Jan Engelhardt]

>В Птн, 26/01/2007 в 12:24 +0100, Jan Engelhardt пишет:
>> >http://www.meteor.dp.ua/casper/firewill.pdf
>> >
>> >how would I make a "feature request" to ask for, say, "mangle2" table
>> >that is just after "nat" in POSTROUTING? The only reason for this move
>> >is the need for ability to catch un-DNAT'ed packets with -j ULOG or
>> >(better) to -j QUEUE.
>> 
>> And  -t nat -A POSTROUTING -m conntrack ! --ctstate DNAT
>> as a last rule won't do?
>
>This will (probably) catch packets that hasn't been DNAT'ed.
>BUT, the thing I need it to catch replay packets that has already passed
>"un-DNAT" procedure.

Ah, now I get what you mean with un-DNAT. (Unwrapping I'd say ;-)
Too bad, I don't see a way. But as an intermediate workaround, you could
copy ULOG/QUEUE to a new module, say, MYULOG/MYQUEUE and modify it so as to
display the original address pair (which should easily be possible with kernel
code).


	-`J'
-- 

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Покотиленко Костик]

В Птн, 26/01/2007 в 17:12 +0100, Jan Engelhardt пишет:
> >В Птн, 26/01/2007 в 12:24 +0100, Jan Engelhardt пишет:
> >> >http://www.meteor.dp.ua/casper/firewill.pdf
> >> >
> >> >how would I make a "feature request" to ask for, say, "mangle2" table
> >> >that is just after "nat" in POSTROUTING? The only reason for this move
> >> >is the need for ability to catch un-DNAT'ed packets with -j ULOG or
> >> >(better) to -j QUEUE.
> >> 
> >> And  -t nat -A POSTROUTING -m conntrack ! --ctstate DNAT
> >> as a last rule won't do?
> >
> >This will (probably) catch packets that hasn't been DNAT'ed.
> >BUT, the thing I need it to catch replay packets that has already passed
> >"un-DNAT" procedure.
> 
> Ah, now I get what you mean with un-DNAT. (Unwrapping I'd say ;-)
> Too bad, I don't see a way. But as an intermediate workaround, you could
> copy ULOG/QUEUE to a new module, say, MYULOG/MYQUEUE and modify it so as to
> display the original address pair (which should easily be possible with kernel
> code).

That requires kernel hacking practice which I don't have. Also I won't
do that, because this is for *production use*, so I would relay on
someone experienced.

Also, considering that the need I have is not so specific and it is
highly probable that it will be usefull for many others I would rather
prefer to make a "feature request" for that extra table (ala "mangle2")
to be implemented by professional team of kernel developers.

And, is it possible to get a verdict about this request here? Or maybe
there is more suitable place to ask?

Thanks for quick answer.
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Покотиленко Костик]

Excuse me for double asking, but is this the place for such a feature
request?

Thanks in advance for your help/time.

В Птн, 26/01/2007 в 13:21 +0200, Покотиленко Костик пишет:
> Hi.
> 
> After analizing the situation I have come to decide to request NEW TABLE
> in iptables.
> 
> Considering the scheme at:
> 
> http://www.meteor.dp.ua/casper/firewill.pdf
> 
> how would I make a "feature request" to ask for, say, "mangle2" table
> that is just after "nat" in POSTROUTING? The only reason for this move
> is the need for ability to catch un-DNAT'ed packets with -j ULOG or
> (better) to -j QUEUE.
> 
> В Вто, 26/12/2006 в 12:09 +0100, Pascal Hambourg пишет:
> > Hello,
> > 
> > Pokotilenko Kostik a écrit :
> > > 
> > > Is it possible to catch un-DNAT'ed packets with iptables' -j ULOG
> > > target?
> > 
> > I'm afraid no.
> > 
> > > Where does the un-DNAT occurs and is there table/chain that is
> > > processed after un-DNAT?
> > 
> > In 2.4 kernels, when DNAT occurs in the PREROUTING chain, un-DNAT occurs 
> > at the same place as (and in place of) the POSTROUTING chain of the 
> > 'nat' table, and there is no chain after it. In 2.4 kernels >= 2.4.19, 
> > when DNAT occurs in the OUTPUT chain, un-DNAT occurs after the INPUT 
> > chain of the 'filter' table, and there is no chain after it either. I 
> > suppose it has not changed in 2.6 kernels.
> > 
> > > The problem I have is that replay packets got catched with real source
> > > address, not the one the client has initially connected to. I was
> > > catching replay packets in mangle/POSTROUTING.
> > 
> > The POSTROUTING chain of the 'mangle' table is just before the un-DNAT 
> > place.
> > 
> > 
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Jan Engelhardt]

>Excuse me for double asking, but is this the place for such a feature
>request?

At least it's not the wrong place.


Jan
-- 
ft: http://freshmeat.net/p/chaostables/

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Jan Engelhardt]

On Jan 30 2007 11:46, Jan Engelhardt wrote:
>>Excuse me for double asking, but is this the place for such a feature
>>request?
>
>At least it's not the wrong place.

For the mailinglist record, the solutions is:

  -t nat -A POSTROUTING -m conntrack --ctstate DNAT --ctorigdst x.x.x.x


Jan
-- 
ft: http://freshmeat.net/p/chaostables/

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Покотиленко Костик]

В Вто, 30/01/2007 в 19:02 +0100, Jan Engelhardt пишет:
> On Jan 30 2007 11:46, Jan Engelhardt wrote:
> >>Excuse me for double asking, but is this the place for such a feature
> >>request?
> >
> >At least it's not the wrong place.
> 
> For the mailinglist record, the solutions is:
> 
>   -t nat -A POSTROUTING -m conntrack --ctstate DNAT --ctorigdst x.x.x.x

Just to make sure. This rule will match the packets with canntrack state
"DNAT" and whose original (before DNAT) destination address was x.x.x.x,
right?

If I add -j ULOG to this rule what would be logged packet source address
for replay packet (Server->Client)? Original, that client was initially
connected to, or real, that was set during DNAT? 

By the way does -m conntrack --ctstate DNAT --ctorigdst x.x.x.x match
request or replay packets or packets belonging to connection which was
originally made to x.x.x.x?

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Pascal Hambourg]

Hello

Pokotilenko Kostik a écrit :
>>
>>  -t nat -A POSTROUTING -m conntrack --ctstate DNAT --ctorigdst x.x.x.x
> 
> Just to make sure. This rule will match the packets with canntrack state
> "DNAT" and whose original (before DNAT) destination address was x.x.x.x,
> right?

This is my understanding. However I would recommend not to put such a 
rule in the nat table because chains in the nat table do not see reply 
packets.

> If I add -j ULOG to this rule what would be logged packet source address
> for replay packet (Server->Client)? Original, that client was initially
> connected to, or real, that was set during DNAT? 

The rule would log the current packet source address as usual, so it 
won't show the original destination address unless you had put it in the 
--log-prefix option.

> By the way does -m conntrack --ctstate DNAT --ctorigdst x.x.x.x match
> request or replay packets or packets belonging to connection which was
> originally made to x.x.x.x?

 From my understanding, the latter. "Original" and "reply" usually refer 
to connection tracking, not individual packets. However I am not sure 
whether it would match the first packet creating the connection, can 
anyone confirm ?

Re: iptables NEW TABLE request. WAS[Re: Catching un-DNAT'ed packets]

[Покотиленко Костик]

В Срд, 31/01/2007 в 12:38 +0100, Pascal Hambourg пишет:
> Hello
> 
> Pokotilenko Kostik a écrit :
> >>
> >>  -t nat -A POSTROUTING -m conntrack --ctstate DNAT --ctorigdst x.x.x.x
> > 
> > Just to make sure. This rule will match the packets with canntrack state
> > "DNAT" and whose original (before DNAT) destination address was x.x.x.x,
> > right?
> 
> This is my understanding. However I would recommend not to put such a 
> rule in the nat table because chains in the nat table do not see reply 
> packets.
> 
> > If I add -j ULOG to this rule what would be logged packet source address
> > for replay packet (Server->Client)? Original, that client was initially
> > connected to, or real, that was set during DNAT? 
> 
> The rule would log the current packet source address as usual, so it 
> won't show the original destination address unless you had put it in the 
> --log-prefix option.
> 
> > By the way does -m conntrack --ctstate DNAT --ctorigdst x.x.x.x match
> > request or replay packets or packets belonging to connection which was
> > originally made to x.x.x.x?
> 
>  From my understanding, the latter. "Original" and "reply" usually refer 
> to connection tracking, not individual packets. However I am not sure 
> whether it would match the first packet creating the connection, can 
> anyone confirm ?

Can someone confirm this? If there is a way to do what I want then there
is no need for new table in iptables.

-- 
Покотиленко Костик <casper@meteor.dp.ua>