On 19.03.2010 06:11, netfilter-owner@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxx>: >> В Чтв, 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@xxxxxxxxx>: >>>> On 18.03.2010 06:59, angelmotta@xxxxxxxxx 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@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> >>> >> -- >> Покотиленко Костик <casper@xxxxxxxxxxxx> >> >> > > > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
