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

Tomato Shibby-RT-N66U - iptables-restore: line 65 failed

Discussion in 'Tomato Firmware' started by Dudeman456, Jul 6, 2013.

  1. Dudeman456

    Dudeman456 LI Guru Member

    I been trying to open port 80 on my RT-N66U, as soon as I tried, I started receiving the error iptables-restore: line 65 failed . I have tried reboting, including turning it off, but it does not solve the problem. I SSH into the router, all that I found in etc is iptables.error . It does not go as far as line 69.

    This what is located in the messages log

    Jul 6 04:05:54 RT-N66U daemon.err miniupnpd[1699]: add_filter_rule() : chain upnp not found
    Jul 6 04:06:32 RT-N66U daemon.err miniupnpd[1699]: delete_filter_rule() : iptc_delete_num_entry(): No chain/target/match by that name
    Jul 6 04:06:32 RT-N66U daemon.err miniupnpd[1699]: failed to remove port mapping
    Jul 6 04:07:14 RT-N66U user.info kernel: xt_recent: hitcount (51) is larger than packets to be remembered (20)
    Jul 6 04:07:14 RT-N66U user.crit init[1]: Error while loading rules. See /etc/iptables.error file.
    Jul 6 04:07:46 RT-N66U daemon.err miniupnpd[1699]: add_filter_rule() : chain upnp not found
    Jul 6 04:08:18 RT-N66U daemon.err miniupnpd[1699]: delete_filter_rule() : iptc_delete_num_entry(): No chain/target/match by that name
    Jul 6 04:08:18 RT-N66U daemon.err miniupnpd[1699]: failed to remove port mapping

    These are the content of the iptables.error file

    *mangle
    :pREROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT
    *nat
    :pREROUTING ACCEPT [0:0]
    :pOSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :WANPREROUTING - [0:0]
    -A PREROUTING -d 69.122.67.47 -j WANPREROUTING
    -A PREROUTING -i vlan2 -d 192.168.3.1/255.255.255.0 -j DROP
    -A WANPREROUTING -p icmp -j DNAT --to-destination 192.168.3.1
    -A WANPREROUTING -p tcp -m tcp --dport 100 -j DNAT --to-destination 192.168.3.1:80
    -A WANPREROUTING -p tcp --dport 39 -j DNAT --to-destination 192.168.3.66:39
    -A WANPREROUTING -p udp --dport 39 -j DNAT --to-destination 192.168.3.66:39
    -A WANPREROUTING -p tcp --dport 3389 -j DNAT --to-destination 192.168.3.66:3389
    -A WANPREROUTING -p udp --dport 3389 -j DNAT --to-destination 192.168.3.66:3389
    -A WANPREROUTING -p tcp --dport 919 -j DNAT --to-destination 192.168.3.66:919
    -A WANPREROUTING -p udp --dport 63240 -j DNAT --to-destination 192.168.3.66:63240
    -A WANPREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.3.66:80
    -A WANPREROUTING -p udp --dport 80 -j DNAT --to-destination 192.168.3.66:80
    -A WANPREROUTING -j TRIGGER --trigger-type dnat
    :upnp - [0:0]
    -A PREROUTING -d 69.122.67.47 -j upnp
    -A WANPREROUTING -j DNAT --to-destination 192.168.3.66
    -A POSTROUTING -o vlan2 -j MASQUERADE
    -A POSTROUTING -o br0 -s 192.168.3.1/255.255.255.0 -d 192.168.3.1/255.255.255.0 -j SNAT --to-source 192.168.3.1
    COMMIT
    *filter
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state --state INVALID -j DROP
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -N shlimit
    -A shlimit -m recent --set --name shlimit
    -A shlimit -m recent --update --hitcount 51 --seconds 60 --name shlimit -j DROP
    -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
    -A INPUT -i lo -j ACCEPT
    -A INPUT -i br0 -j ACCEPT
    -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
    -A INPUT -p tcp --dport 100 -j ACCEPT
    -A INPUT -p tcp --dport 2121 -j ACCEPT
    -A INPUT -p tcp --dport 51515 -j ACCEPT
    -A INPUT -p tcp --dport 3000 -j ACCEPT
    :FORWARD DROP [0:0]
    -A FORWARD -m account --aaddr 192.168.3.0/255.255.255.0 --aname lan
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    :wanin - [0:0]
    :wanout - [0:0]
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i vlan2 -j wanin
    -A FORWARD -o vlan2 -j wanout
    -A FORWARD -i br0 -j ACCEPT
    :upnp - [0:0]
    -A FORWARD -i vlan2 -j upnp
    :triggers - [0:0]
    -A wanout -j triggers
    -A wanin -j TRIGGER --trigger-type in
    -A triggers -p tcp -m tcp --dport 2121 -j TRIGGER --trigger-type out --trigger-proto tcp --trigger-match 2121 --trigger-relate 2121
    -A triggers -p udp -m udp --dport 2121 -j TRIGGER --trigger-type out --trigger-proto udp --trigger-match 2121 --trigger-relate 2121
    -A wanin -p tcp -m tcp -d 192.168.3.66 --dport 39 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.3.66 --dport 39 -j ACCEPT
    -A wanin -p tcp -m tcp -d 192.168.3.66 --dport 3389 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.3.66 --dport 3389 -j ACCEPT
    -A wanin -p tcp -m tcp -d 192.168.3.66 --dport 919 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.3.66 --dport 63240 -j ACCEPT
    -A wanin -p tcp -m tcp -d 192.168.3.66 --dport 80 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.3.66 --dport 80 -j ACCEPT
    -A FORWARD -o br0 -d 192.168.3.66 -j ACCEPT
    COMMIT
     
  2. Dudeman456

    Dudeman456 LI Guru Member

    I just tried the Asus Official Firmware, it does not seem to be an issue with that firmware. Perhaps its a bug in the Tomato implementation .

    Who do I report the issue to?

    I have already entered a bug report at Shibby's site.
     
  3. RMerlin

    RMerlin Network Guru Member

    Try "iptables-restore file_with_the_rules", and post the content of the line number where the error occurs.
     
  4. Dudeman456

    Dudeman456 LI Guru Member

    I actually switched to your modified firmware, and it works there, but I am willing to try.

    Now the way I been looking at the content of the file has been by going to etc and using cat , is there a better way to get the information? Will I find "iptables-restore file_with_the_rules" in the same folder?
     
  5. RMerlin

    RMerlin Network Guru Member


    iptables-restore is a command that will be in the search path. file_with_the_rules is whichever file you were checking to get that list of rules - I don't know how that file is named under Tomato or where it's located. In Asuswrt it's /tmp/filter_rules.
     
  6. density

    density Serious Server Member

    Apparently, the answer to your problem is already in your post.
    There is a login attempt limit for ssh/telnet, if you set one in Administration -> Admin access -> Admin Restrictions.

    Looks like a bug in the web interface.
     
  7. Dudeman456

    Dudeman456 LI Guru Member

    Are you theorizing that the reason I was not able to open port 80 was because the session I was using in the browser was not fully active to make the changes I was attempting to make. In other words the session I was using was not logged in as root, because of too many login attempts?
     
  8. density

    density Serious Server Member

    No. How many actual login attempts you make is irrelevant. However, it's not possible set a limit of more than 19 (or 20?) login attempts per minute. If you do that, iptables-restore will fail writing your iptables, and you end up with empty tables.

    Set your login limit below 20 in Administration -> Admin access -> Admin Restrictions and everything should go back to normal.
     
  9. density

    density Serious Server Member

    If you cannot open the web interface, because your firewall settings are messed up, you can also do it this way:
    Delete the following lines in iptables.error:
    Code:
    -N shlimit
    -A shlimit -m recent --set --name shlimit
    -A shlimit -m recent --update --hitcount 51 --seconds 60 --name shlimit -j DROP
    -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
    Then use iptables-restore to fix your firewall settings:
    Code:
    cat /etc/iptables.error | iptables-restore
    After that you can correct your settings in the web interface.
     
  10. Dudeman456

    Dudeman456 LI Guru Member

    The thing is I have never adjusted the Access Restriction settings, I have never had a reason to. As for the firewall I using do all I can to disable the firewall, the same on the PC side.

    This issue occurred every time I setup port forwarding in the same order I have always had it, and attempted to open port 80 last.

    This does not occur in the RMerlin version of the official firmware.

    I eventually figure out a small work around. If I did the configuration backwards, in that I would start by opening port 80, and then added all the other ports that I use, and past configuration it does not give me this error. Looking at the bug reports, it seems that this is becoming a more common error.
     
  11. density

    density Serious Server Member

    Well, I'm not sure how you did it, but your firewall settings clearly state that SSH connections (--dport 22) are dropped (-j DROP) after 51 attempts (--hitcount 51) per minute (--seconds 60). You kernel messages also suggest that this setting is the cause of your iptables error.

    If you didn't change that setting on purpose, it's still possible that you did it inadvertently.
     
  12. beanie1984

    beanie1984 Addicted to LI Member

    I got the same error using shibby firmware after disabling IP traffic monitoring, setting up a large DHCP pool (172.16.0.1/12), and re-enabling IP traffic monitoring. After I disabled IP traffic monitoring again, the problem went away.
     

Share This Page