1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

iptables & connlimit behavior

Discussion in 'Tomato Firmware' started by sundeen, Feb 11, 2014.

  1. sundeen

    sundeen Reformed Router Member

    Hello all,

    I have been trying to find a solution to a problem for hours, to no avail. I am running Tomato on my router but this is more of an iptables question. I've added the following line to Scripts/Firewall:

    iptables -I wanin -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT --reject-with tcp-reset

    This is set up to allow users on my MUD to telnet in with two simultaneous connections. It will block a third (and all subsequent) connection attempts, effectively limiting multiplaying.

    HOWEVER, as connlimit will count up, it doesn't seem to subtract. So if a user connects twice, then disconnects one connection (leaving the other connection active), they are unable to make new connections until ALL connections have been terminated. It's like connlimit just keeps a "total" count and not an "active" count. Perhaps this is the intended behavior.

    Is there any clever iptables trickery that can be done to get around this? I looked into using --tcp-flags but have been unable to come up with anything. I was hoping there would be a way for to use a FIN or RST flag and lower the current connection count.

    In effect, I'm looking for this:
    1) On new p23 connection (no priors) -> ACCEPT
    2) On new p23 connection (1 prior) -> ACCEPT
    3) On new p23 connection (2 priors) -> REJECT
    |-> If one existing connection is dropped, go back to 2
    |-> If both existing connections are dropped, go back to 1 (this is currently how that part works anyway)

    Is there a way to accomplish this?
     
  2. koitsu

    koitsu Network Guru Member

    The command you're using looks legitimate to me; I've looked at examples, documentation, and what you're trying to accomplish should work with that rule. Meaning: I understand it the same way you do.

    My guess is that the problem may be related to iptables rule ordering.

    You've added the rule to the top of the wanin chain. Look very closely where that chain is used within the FORWARD chain, and the rules that precede it (this is the most important part).

    Also notice that these are going into the FORWARD chain -- why? Assuming the MUD is behind your Tomato router (i.e. you're using a TCP port forward of some kind), or even *on* your router itself, this kind of connlimit use should probably end up in up in your INPUT chain, and should most likely come before the state RELATED,ESTABLISHED rule.

    There may be /proc/net entries somewhere that "keep track" of the data within connlimit, by the way in which case those may come in handy for you to determine what exactly is going on.

    If you want me to test this behaviour to see if I'm right, I can, but I can't guarantee when I can get to it. I have job interviews and job offers to review and this week is extremely stressful for me.
     
  3. sundeen

    sundeen Reformed Router Member

    Thank you for replying during your busy week! :)

    I had previously tried this rule in the INPUT chain, but it never seemed to work. Inserting this rule at the top of FORWARD exhibits the same behavior as mentioned above. I currently have it in "wanin" just because I was trying things; it does the same thing as in FORWARD.

    Now, going off of your advice, I moved the rule into the INPUT chain on the line before state RELATED,ESTABLISHED, and it doesn't seem to limit the connection in any way.

    I tried moving it to FORWARD right before state RELATED,ESTABLISHED, and it limits connections as mentioned in my original post. So no go there.

    I checked /proc/net and found a "ip_conntrack" file that tracks connections, but I can't seem to catch (or maybe it doesn't log) the rejections. tail doesn't seem to be doing what I want it to do, either.

    Here is my current iptables list:
    Code:
    Chain INPUT (policy DROP)
    num  target  prot opt source  destination
    1  DROP  all  --  0.0.0.0/0  [my outside ip]
    2  DROP  all  --  0.0.0.0/0  0.0.0.0/0  state INVALID
    3  ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
    4  ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
    5  ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
    
    Chain FORWARD (policy DROP)
    num  target  prot opt source  destination
    1  ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
    2  DROP  all  --  0.0.0.0/0  0.0.0.0/0  state INVALID
    3  TCPMSS  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    4  REJECT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:23 flags:0x17/0x02 #conn/32 > 2 reject-with tcp-reset
    5  ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
    6  wanin  all  --  0.0.0.0/0  0.0.0.0/0
    7  wanout  all  --  0.0.0.0/0  0.0.0.0/0
    8  ACCEPT  all  --  0.0.0.0/0  0.0.0.0/0
    
    Chain OUTPUT (policy ACCEPT)
    num  target  prot opt source  destination
    
    Chain wanin (1 references)
    num  target  prot opt source  destination
    1  ACCEPT  tcp  --  0.0.0.0/0  [my MUD's internal IP] tcp dpt:23
    
    Chain wanout (1 references)
    num  target  prot opt source  destination
    
     
    Last edited: Feb 11, 2014
  4. sundeen

    sundeen Reformed Router Member

    These were relevant lines in /proc/net/ip_conntrack:
    Code:
    tcp  6 1191 ESTABLISHED src=[external test ip] dst=[my router's wan IP] sport=54207 dport=23 src=[my MUD's internal IP] dst=[external test ip] sport=23 dport=54207 [ASSURED] use=1 mark=5
    tcp  6 1187 ESTABLISHED src=[external test ip] dst=[my router's wan IP] sport=54206 dport=23 src=[my MUD's internal IP] dst=[external test ip] sport=23 dport=54206 [ASSURED] use=1 mark=5
    
    The 1191 and 1187 state remaining time in seconds before timing out. Evidently the default is 1200. If I can't figure out what's up with iptables and connlimit, maybe I should just speed up the timeout?

    As an aside (and a note to myself), I was searching around for /proc/net/ip_conntrack and found these:
    http://www.iptables.info/en/connection-state.html

    http://www.faqs.org/docs/iptables/theconntrackentries.html

    http://sq4ind.eu/monitoring-ip_conntrack-on-zabbix/ (see the comments section)

    http://major.io/2008/01/24/ip_conntrack-table-full-dropping-packet/

    Since my router has 16MB of RAM, maybe this is just a bad idea in general. Hmm.
     

Share This Page