Usage of CONNMARK

DISCUSSION Vinod Chandran 3 participants 6 messages Feb 4, 2005 – Feb 7, 2005 netfilter

Share & tools

Vinod Chandran

author

2005-02-04 08:13 UTC #0 lore raw

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

Henrik Nordstrom

2005-02-04 14:17 UTC #1 lore raw

Quoted 2 lines · Vinod Chandran

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?

Quoted 1 line

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.

Quoted 1 line

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

Vinod Chandran

author

2005-02-05 07:36 UTC #2 lore raw

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

Quoted 21 lines · Henrik Nordstrom

Quoted 2 lines · Vinod Chandran
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?
Quoted 1 line
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.
Quoted 1 line
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

Henrik Nordstrom

2005-02-06 00:51 UTC #3 lore raw

Quoted 3 lines · Vinod Chandran

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;
}

Quoted 1 line

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

Vinod Chandran

author

2005-02-07 04:16 UTC #4 lore raw

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

Quoted 32 lines · Henrik Nordstrom

Quoted 3 lines · Vinod Chandran
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.
Quoted 1 line
From ip_conntrack_in:
        if (ret != NF_DROP && ct->helper) {
                ret = ct->helper->help(*pskb, ct, ctinfo);
    [...]

    return ret;
}
Quoted 1 line
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

[email protected]

2005-02-04 21:35 UTC #5 lore raw

In reply to Vinod Chandran

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

Quoted 19 lines · 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