[Users] iptables connlimit module not working

[Kir Kolyshkin]

Please file a bug to bugzilla.openvz.org
On Jun 24, 2013 2:29 PM, "Dan Bassett" <dbassett at oreillyschool.com> wrote:

>  I just tested this out again on a newly installed machine.  I have the
> following in my vz.conf:
>
> IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter
> iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_LOG
> ipt_conntrack ipt_state xt_connlimit ipt_connlimit"
>
> IPTABLES_MODULES="$IPTABLES"
>
> I have tried just "ipt_connlimit", just "xt_connlimit, and both in the
> IPTABLES list.  I even rebooted the machine before I started each test.  I
> get the same results.  The connlimit rule is not tripped by multiple SSH
> connections as it should be.
>
> Dan
>
> On 06/21/2013 05:55 PM, Kir Kolyshkin wrote:
>
>
>
> On 21 June 2013 08:09, Dan Bassett <dbassett at oreillyschool.com> wrote:
>
>> I am running 2.6.32-042stab076.8 on a CentOS6 HN with CentOS6 containers,
>> vzctl-4.2-1.x86_64. I have two containers running on the same HN. Each CT
>> has a veth device. Both CT's veth device is connected to the same bridge
>> device on the HN. They are assigned the addresses 192.168.0.1/24 and
>> 192.168.0.2/24 and can ping each other.
>>
>> On the HN I am able to modprobe the connlimit module (xt_connlimit).
>
>
>  You are supposed to load it before loading VZ modules (and this is the
> reason of having it listed in vz.conf so vz initscript takes care of
> loading it.
>
>  If you loaded it after loading vz modules it might not work. So, to make
> sure you'd do a reboot (or reloading of all vz modules -- /etc/init.d/vz
> stop, then make sure vz modules such as vznet are not loaded, then
> /etc/init.d/vz start).
>
>
>> I can then use iptables rules on the hostnode such as:
>>
>> iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above
>> 1 --connlimit-mask=32 -j REJECT
>>
>> If I then attempt to initiate more than one ssh session to this HN from
>> the same host, the second (and all subsequent) ssh connections are
>> rejected.  This leads me to believe that the connlimit module is working
>> properly with the OpenVZ kernel.
>>
>> I am able to successfully insert the same rule into the iptables
>> configuration in either of my containers, so it seems that the xt_connlimit
>> module is properly loaded (I get errors if I try to use an iptables module
>> that has not been loaded on the hostnode).  However, I can create more than
>> one successful ssh session, meaning that the iptables rule in the CT is not
>> being matched for some reason. I have both "xt_limit" and "xt_connlimit" in
>> the list of iptables modules to load in vz.conf. When I am running these
>> tests, I have no iptables rules loaded on the HN, and I have no other
>> iptables rules loaded in the container.
>>
>> One interesting thing I have noticed is that when I enter a container on
>> this hostnode, I get the following errors:
>>
>> [root at hn0 ~]# vzctl enter 2033892
>> Warning: Unknown iptable module: xt_connlimit, skipped
>> Warning: Unknown iptable module: xt_limit, skipped
>>
>> It seems like this might be related to my issue, but it might just be a
>> red herring.
>>
>
>
>  This warning is harmless, it is not a bug, details are here:
> http://git.openvz.org/?p=vzctl;a=commit;h=d284c8a7
>
>  Or see vz.conf(5) man page, description of IPTABLES and IPTABLES_MODULES.
>
>
>
>>
>> Am I missing something obvious here? Or is this a bug with OpenVZ?
>>
>> Thanks,
>> Dan
>> _______________________________________________
>> Users mailing list
>> Users at openvz.org
>> https://lists.openvz.org/mailman/listinfo/users
>>
>
>
>
> _______________________________________________
> Users mailing listUsers at openvz.orghttps://lists.openvz.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20130624/bc1f9924/attachment.html>