Re: Rules PREROUTING doesn't work

[Mart Frauenlob <mart.frauenlob@chello.at>]

On 19.03.2010 06:11, netfilter-owner@vger.kernel.org wrote:
> Thanks
> Can someone tell me how to reset ip_conntrack_udp_timeout, for get
> that my vpn cliente conect to the new VPN server behind the Firewall
> through NAT UDP?

1: could you please stop top posting.

2: do what you were asked for and show us the COMPLETE output of
'iptables-save'.

> 
> How use that?? I dont have contrack command.
> "conntrack -F"

you would need to install conntrack tools. maybe there's a package in
the CentOS repo.

Best regards

Mart

> 
> O I have to put value 0 to ip_conntrack_udp_timeout, and automatically
> the vpn clients will reconnect to the new server VPN behind the
> Firewall
> 
> Thanks for your answers
> --
> Angel
> 
> 2010/3/18 Покотиленко Костик <casper@meteor.dp.ua>:
>> В Чтв, 18/03/2010 в 10:36 -0500, Angel Motta пишет:
>>> Thanks a lot Mart
>>>
>>> I found that parameter in Centos5 with:
>>> #> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
>>> 30
>>
>> If I'm not mistaken this time is in seconds.
>>
>>> This means that the connections UDP of my vpnclients will keep trying
>>> connect to Firewall until finish this time 30 minutes....despite I
>>> have my PREROUTING rule stating redirect that traffic UDP to the
>>> server VPN behind the Firewall??
>>
>> This means that if conntrack already have entry for a specific
>> connection it will keep it until there is nothing sent/received for 30
>> second withing this connection. Since UDP is connectionless protocol,
>> UDP-connection from netfilter point of view are packets with same source
>> IP/port destination IP/port pairs withing a period of time (30sec).
>>
>> Since nat table sees only packets starting new connection, it will not
>> get ones belonging to a connection which is still in conntrack.
>>
>> If your VPN-client are always re-trying to connect with interval less
>> that ip_conntrack_udp_timeout, conntrack entry corresponding to such
>> connections will never disappear by itself.
>>
>> You can simply do "conntrack -F" if you don't care about rest
>> connections in conntrack. Or remove each manually, or drop such
>> connection attempts for the time needed for them to be removed from
>> conntrack.
>>
>>> This is the cause of the problem??
>>>
>>> Thanks, I hope your comments to schedule this work at night with my firewall
>>> I hope to fix this soon as possible
>>>
>>> Thanks List for your assistance
>>> --
>>> Angel
>>>
>>> 2010/3/18 Mart Frauenlob <mart.frauenlob@chello.at>:
>>>> On 18.03.2010 06:59, angelmotta@gmail.com wrote:
>>>>
>>>>> One question, I donde have that file
>>>>> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*
>>>>> I don't have netfilter directory, where is that ??
>>>>>
>>>>
>>>> on older systems it used to be in:
>>>> /proc/sys/net/ipv4/
>>>>
>>>> and maybe also was named with the ip_* prefix, not with nf_*.
>>>>
>>>> to look for it yourself, you could have done something like:
>>>> find /proc/sys/ -name netfilter -type d
>>>> or
>>>> find /proc/sys/ -name '*conntrack*'
>>>> ...
>>>>
>>>> Best regards
>>>>
>>>> Mart
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
>>>
>> --
>> Покотиленко Костик <casper@meteor.dp.ua>
>>
>>
> 
> 
>