Usage of CONNMARK

Usage of CONNMARK

[Vinod Chandran]

Hi,

I am using the CONNMARK patch.
Inside conntrack_core, in case of special conditions, I have modified 
the mark value in the conntrack.

I then added the following rules in FORWARD chain.

iptables -t mangle -A FORWARD -m connmark --m mark 1 -j DROP

where the CONNMARK is set in case of the illegal packet.

However this CONNMARK value is getting effective only for the next 
packet and not for the same packet.

Is there some way by which, I can make the settings applicable to the 
same packet itself?

Thanks and Regards,
Vinod C

Re: Usage of CONNMARK

[Henrik Nordstrom]

On Fri, 4 Feb 2005, Vinod Chandran wrote:

> I am using the CONNMARK patch.
> Inside conntrack_core, in case of special conditions, I have modified the 
> mark value in the conntrack.

When in conntrack is this modification done?

> However this CONNMARK value is getting effective only for the next packet and 
> not for the same packet.

The connmark match looks at the connection mark value at the time the 
connmark match is evaluated.

> Is there some way by which, I can make the settings applicable to the same 
> packet itself?

It is, assuming it's done before you need to evaluate the match.

Regards
Henrik

Re: Usage of CONNMARK

[Vinod Chandran]

Hi,
 
Currently, from the FTP helper if DROP is given, the packets are not 
getting dropped since the conntrack entry exists and also since from 
where the helper routine is called, there is no check for return value 
of NF_DROP. Hence when NF_DROP is returned, inside ip_conntrack_in, I 
set the conntrack value
       ct->mark = 1
 However this CONNMARK value is getting applicable only from the next 
packet ownwards.

If on the other hand, say I try to change the mark value, 
(*pskb)->nfmark ( I assume it contains the MARK indicator), and put a 
rule in the KEEP_STATE_FORWARD chain to drop packets with the specific 
mark value, the kernel is panicing , with a BUG in sched.c. I also get 
panic if I call nf_conntrack_put.

The problem in my case, is the error is detected after the conntrack 
state is changed. I am wondering whether this is the reason why its 
causing all the problems.

Thanks,
Vinod C

Henrik Nordstrom wrote:

> On Fri, 4 Feb 2005, Vinod Chandran wrote:
>
>> I am using the CONNMARK patch.
>> Inside conntrack_core, in case of special conditions, I have modified 
>> the mark value in the conntrack.
>
>
> When in conntrack is this modification done?
>
>> However this CONNMARK value is getting effective only for the next 
>> packet and not for the same packet.
>
>
> The connmark match looks at the connection mark value at the time the 
> connmark match is evaluated.
>
>> Is there some way by which, I can make the settings applicable to the 
>> same packet itself?
>
>
> It is, assuming it's done before you need to evaluate the match.
>
> Regards
> Henrik
>

Re: Usage of CONNMARK

[Henrik Nordstrom]

On Sat, 5 Feb 2005, Vinod Chandran wrote:

> Currently, from the FTP helper if DROP is given, the packets are not getting 
> dropped since the conntrack entry exists and also since from where the helper 
> routine is called, there is no check for return value of NF_DROP. Hence when 
> NF_DROP is returned, inside ip_conntrack_in, I set the conntrack value
>      ct->mark = 1
> However this CONNMARK value is getting applicable only from the next packet 
> ownwards.

I do not follow. Conntract helpers can return NF_DROP to drop the packets, 
and this will cause the packet to be dropped. This is actively used today 
by the FTP helper when an partial request is received.

From ip_conntrack_in:

         if (ret != NF_DROP && ct->helper) {
                 ret = ct->helper->help(*pskb, ct, ctinfo);
 	[...]

 	return ret;
}

> If on the other hand, say I try to change the mark value, (*pskb)->nfmark ( I 
> assume it contains the MARK indicator), and put a rule in the 
> KEEP_STATE_FORWARD chain to drop packets with the specific mark value, the 
> kernel is panicing , with a BUG in sched.c. I also get panic if I call 
> nf_conntrack_put.

Setting the nfmark like this (MARK) should work, and should not panic your 
system.

In addition, setting the connection mark from helpers called in 
ip_conntrack_in should be available in all iptables chains.


All three of your problems makes no sense to me. All should work (return 
NF_DROP from helpers, setting the connection mark, setting the nfmark).

Regards
Henrik

Re: Usage of CONNMARK

[Henrik Nordstrom]

On Sat, 5 Feb 2005, Vinod Chandran wrote:

> Currently, from the FTP helper if DROP is given, the packets are not getting 
> dropped since the conntrack entry exists and also since from where the helper 
> routine is called, there is no check for return value of NF_DROP. Hence when 
> NF_DROP is returned, inside ip_conntrack_in, I set the conntrack value
>      ct->mark = 1
> However this CONNMARK value is getting applicable only from the next packet 
> ownwards.

I do not follow. Conntract helpers can return NF_DROP to drop the packets, 
and this will cause the packet to be dropped. This is actively used today 
by the FTP helper when an partial request is received.

>From ip_conntrack_in:

         if (ret != NF_DROP && ct->helper) {
                 ret = ct->helper->help(*pskb, ct, ctinfo);
 	[...]

 	return ret;
}

> If on the other hand, say I try to change the mark value, (*pskb)->nfmark ( I 
> assume it contains the MARK indicator), and put a rule in the 
> KEEP_STATE_FORWARD chain to drop packets with the specific mark value, the 
> kernel is panicing , with a BUG in sched.c. I also get panic if I call 
> nf_conntrack_put.

Setting the nfmark like this (MARK) should work, and should not panic your 
system.

In addition, setting the connection mark from helpers called in 
ip_conntrack_in should be available in all iptables chains.


All three of your problems makes no sense to me. All should work (return 
NF_DROP from helpers, setting the connection mark, setting the nfmark).

Regards
Henrik

Re: Usage of CONNMARK

[Vinod Chandran]

Hi Henrik,

In case of partail request, too I found the packets where not dropping. 
I had checked it by using nf-drill.pl, given in the FTP advisory. Modify 
the script to give a partial PORT command. The packet goes across the 
firewall and reaches the FTP server. I have connected my FTP server to 
DMZ and running the script from the LAN side.
Setting connection mark does work, but for the next packet and not the 
current one.

Thanks and Regards,
Vinod C

Henrik Nordstrom wrote:

> On Sat, 5 Feb 2005, Vinod Chandran wrote:
>
>> Currently, from the FTP helper if DROP is given, the packets are not 
>> getting dropped since the conntrack entry exists and also since from 
>> where the helper routine is called, there is no check for return 
>> value of NF_DROP. Hence when NF_DROP is returned, inside 
>> ip_conntrack_in, I set the conntrack value
>>      ct->mark = 1
>> However this CONNMARK value is getting applicable only from the next 
>> packet ownwards.
>
>
> I do not follow. Conntract helpers can return NF_DROP to drop the 
> packets, and this will cause the packet to be dropped. This is 
> actively used today by the FTP helper when an partial request is 
> received.
>
>> From ip_conntrack_in:
>
>
>         if (ret != NF_DROP && ct->helper) {
>                 ret = ct->helper->help(*pskb, ct, ctinfo);
>     [...]
>
>     return ret;
> }
>
>> If on the other hand, say I try to change the mark value, 
>> (*pskb)->nfmark ( I assume it contains the MARK indicator), and put a 
>> rule in the KEEP_STATE_FORWARD chain to drop packets with the 
>> specific mark value, the kernel is panicing , with a BUG in sched.c. 
>> I also get panic if I call nf_conntrack_put.
>
>
> Setting the nfmark like this (MARK) should work, and should not panic 
> your system.
>
> In addition, setting the connection mark from helpers called in 
> ip_conntrack_in should be available in all iptables chains.
>
>
> All three of your problems makes no sense to me. All should work 
> (return NF_DROP from helpers, setting the connection mark, setting the 
> nfmark).
>
> Regards
> Henrik
>

Re: Usage of CONNMARK

[dwhite]

Hi vinod,

I could be wrong, but if you want to mark a connection, use CONNMARK, if 
you want to mark a packet, use MARK.

perhaps there is a better way, but I don't know of one at this point.

-dave

On Fri, 4 Feb 2005, Vinod Chandran wrote:

> Hi,
>
> I am using the CONNMARK patch.
> Inside conntrack_core, in case of special conditions, I have modified the 
> mark value in the conntrack.
>
> I then added the following rules in FORWARD chain.
>
> iptables -t mangle -A FORWARD -m connmark --m mark 1 -j DROP
>
> where the CONNMARK is set in case of the illegal packet.
>
> However this CONNMARK value is getting effective only for the next packet and 
> not for the same packet.
>
> Is there some way by which, I can make the settings applicable to the same 
> packet itself?
>
> Thanks and Regards,
> Vinod C
>
>