IRC Logs

Network: freenode Channel: #iptables

	Enter your search terms Submit search form
	Web www.irclog.org

[00:45]<tyajgmzyus>lol
[00:46]<mrrynfmr>spike: yes; it's a feature. It can be turned off by echo 0 > /proc/sys/net/netfilter/ip_conntrack_tcp_loose
[00:47]<mrrynfmr>Ticondrius: it's just a bug in displaying the error
[00:47]<tyajgmzyus>oh...
[00:47]<-- dvxn|syzzzyus xzs>http://www.bagdadsoftware.de")
[00:47]<tyajgmzyus>so what's the real problem then?\
[00:47]<slycn>danieldg: yeah,ta, I've read that as well, it's in the tutorial, but I'm not sure I understood the theory
[00:47]<mrrynfmr>Ticondrius: not sure - that usually means that the module wasn't loaded
[00:47]<mrrynfmr>or it has a bad parameter
[00:47]<tyajgmzyus>..and since I compiled everything in
[00:47]<tyajgmzyus>hmm
[00:48]<slycn>if you powercycle a router conntrack resets everything, so there's nothing in the conntrack table
[00:48]<mrrynfmr>and I don't see anything wrong with your rule
[00:48]<slycn>so how is a packet considered part of an ESTABLISHED connection?
[00:48]<mrrynfmr>spike: correct
[00:48]<tyajgmzyus>well, the command was: iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[00:48]<mrrynfmr>spike: it lets the packets through if they're coming from the local side (they are state NEW) even though they aren't SYNs
[00:49]<mrrynfmr>then, after both sides respond, it assumes (correctly, in this case) that it was a connection
[00:49]<mrrynfmr>Ticondrius: you have IP_CONNTRACK in the kernel too, I assume
[00:50]<mrrynfmr>er, IP_NF_CONNTRACK actually
[00:50]<slycn>danieldg: oh, only from the local side? that's something I was definitely missing
[00:50]<mrrynfmr>spike: it actually depends on the iptables rules
[00:50]<slycn>so what's the deal with the tcp-window?
[00:51]<tyajgmzyus>yes daniel, and makr, events and netlink
[00:51]<tyajgmzyus>mark
[00:51]<slycn>afaik the tcp window is the amount of data a side is willing to accept
[00:51]<mrrynfmr>spike: the packets of the connection are put into the ruleset with state NEW
[00:51]<mrrynfmr>Ticondrius: well, that's very strange then
[00:51]<mrrynfmr>spike: not certain why it's called tcp-window-tracking, unless that was a related issue that let them do this
[00:52]<slycn>danieldg: fromt he aforementioned tutorial:
[00:52]<slycn>A connection may also enter the ESTABLISHED state, but not be [ASSURED]. This happens if we have connection pickup turned on (Requires the tcp-window-tracking patch, and the ip_conntrack_tcp_loose to be set to 1 or higher). The default, without the tcp-window-tracking patch, is to have this behaviour, and is not changeable.
[00:53]<slycn>but that's the only reference in the tut, and I didnt get the point
[00:53]<mrrynfmr>spike: yes, I saw that. BTW, the patch has entered the mainline kernel
[00:54]<slycn>danieldg: could you please be so kind to quickly go through this thread? it's where it started. http://lists.debian.org/debian-firewall/2006/07/msg00001.html
[00:55]<slycn>after reading that I tried to understand the point but so far I've failed... I can understand what happens in practice but the theory behind it is confused
[00:55]<mrrynfmr>spike: heh, just saw this on netfilter-devel: http://people.netfilter.org/pablo/docs/login.pdf
[00:55]<mrrynfmr>that might help explain conntrack
[00:55]<luzu2zzvjz>danieldg, if I may ask one more question, how shall I use the masquerade parameter with these forwards?
[00:55]<slycn>k, reading, ta
[00:55]<tyajgmzyus>daniel....there's no update for iptables in portage
[00:56]<tyajgmzyus>I've got the latest
[00:56]<mrrynfmr>Ticondrius: right - 1.3.5. is latest
[00:56]<tyajgmzyus>1.3.5-r2
[00:56]<mrrynfmr>the bug is only fixed in source code ATM
[00:56]<luzu2zzvjz>danieldg, or was there even a need for it anymore?
[00:57]<tyajgmzyus>daniel: Gentoo is a compiled distro..we don't use binaries
[00:57]<tyajgmzyus>I can't get anything newer than what I have..and yet it's still broke
[00:57]<mrrynfmr>Lucubrator: you still need it - just filter on -d ! 10.0.0.0/16
[00:57]<mrrynfmr>Ticondrius: you could download the source from subversion if you really wanted to
[00:57]<mrrynfmr>Ticondrius: it's fixed in the developer version of the source
[00:58]<tyajgmzyus>I have no idea how do compile packages that way...
[00:58]<tyajgmzyus>besides...doing so would make it unmanageable with portage
[00:58]<mrrynfmr>right
[00:58]<tyajgmzyus>there's no little diff patch?
[00:58]<mrrynfmr>can you edit the source after downloading, and before compiling?
[00:58]<tyajgmzyus>Yes
[00:59]<mrrynfmr>just a sec, I'll find the patch
[00:59]<tyajgmzyus>thnx man
[01:01]<mrrynfmr>Ticondrius: svn diff -r 6587:6588 https://svn.netfilter.org/netfilter/trunk/iptables
[01:02]<tyajgmzyus>huh?
[01:03]<mrrynfmr>that command will give you a patch
[01:03]<mrrynfmr>on stdout
[01:03]<tyajgmzyus>I don't have an svn command
[01:03]<mrrynfmr>well, you could install subversion
[01:04]<tyajgmzyus>oh
[01:04]<mrrynfmr>otherwise, try to get the patch out of http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/iptables/
[01:04]<mrrynfmr>the fix is revision 6588
[01:05]<mrrynfmr>http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/iptables/libiptc/libiptc.c?r1=6587&r2=6588
[01:05]<tyajgmzyus>got it
[01:05]<tyajgmzyus>this fix is *2* months old?!?!
[01:05]<mrrynfmr>yes
[01:06]<tyajgmzyus>It's not even in the UNSTABLE tree!
[01:06]<tyajgmzyus>grrr...
[01:07]<mrrynfmr>it hasn't been offically released yet - it's just in the development code
[01:09]<tyajgmzyus>Doesn't matter...gentoo's unstable branch is supposed to be built on cvs pulls
[01:09]<mrrynfmr>you could look at all the changes since revision 6456 to see any other features not included in iptables 1.3.5
[01:10]<mrrynfmr>oh. Then someone isn't pulling netfilter's svn
[01:10]<tyajgmzyus>how do I wget form this thing?
[01:10]<tyajgmzyus>it's all cgi stuff
[01:10]<mrrynfmr>you're supposed to use svn
[01:10]<tyajgmzyus>bleh
[01:10]<mrrynfmr>https://svn.netfilter.org/netfilter/
[01:11]<slycn>danieldg: so, sorry, is it right to assume that without that patch a single packet will be always allowed through?
[01:11]<slycn>waiting for a reply and if it does come consider the connection ESTABLISHED or otherwise it'll be dropped
[01:11]<mrrynfmr>spike: no. A single packet will always be in NEW state. The iptables rules then decide what to do with it
[01:12]<mrrynfmr>if iptables allows it, then the conntrack is created and waits for a reply
[01:12]<mrrynfmr>Ticondrius: you can wget from that https URL
[01:12]<tyajgmzyus>thnx..alsready solved with scp
[01:12]<tyajgmzyus>;)
[01:13]<-- 2yd2nzy xrs fuyv>http://iownmymusic.org/ http://iownmydvds.org/")
[01:28]<tyajgmzyus>danieldg: compiling
[01:29]<mrrynfmr>what did you do with scp?
[01:30]<tyajgmzyus>Dled to local machine..then used scp to transfer the file
[01:31]<tyajgmzyus>whee! bug fixed...now I've got a legible error
[01:31]<tyajgmzyus>no chain/target/match by that name
[01:31]<mrrynfmr>try iptables -m state -h
[01:32]<tyajgmzyus>state 1.3.5 options:
[01:32]<tyajgmzyus>--state...and my two etries are there
[01:32]<mrrynfmr>ok... and iptables -L INPUT works?

Back to #iptables
Or go to some related logs:
#netbsd
#debian
#suse
#blender
#php