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

WRT54GL (Tomato) drops active connections with TCP RST

Discussion in 'Networking Issues' started by Rumpsteak, Jan 18, 2012.

  1. Rumpsteak

    Rumpsteak Networkin' Nut Member

    I have a WRT54GL with Tomato 1.25 set up at another site. I've been noticing for a while that TCP connections drop occasionally. This is especially disturbing since I have ssh tunnels open through the router, some with an sshfs running inside them.

    I initially believed to be a timout problem, but I recently noticed it occurs also to very active connections, as e.g. during a backup a synchronization I performed recently.

    Using wireshark on my client, I could see that the router suddenly sends a TCP RST packet during a conversation, immediately terminating the connection. The connection can stay open and work fine for anything from 15 minutes to 12 hours before receiving the RST packet.

    I next ran tcpdump on the router to find out more. At least it shows that the RST packets really originate from the router not from anything in between. It also appears that the server application (e.g. ssh daemon on the router itself, or other server application inside the network) doesn't know that the connection has been closed since they keep trying to retransmit the packets, but those packets never reach the client since the RST packet has already been sent.

    I don't know all the reasons that could cause a RST packet to be sent, but I speculate that it is the response to attempting to access a connection that the router sees as closed. So, it appears that the router for some reason has decided to drop the connection in an abrupt way.

    Some notes:
    - If several connections are opened, they will not be dropped simultaneously
    but independently.
    - It appears to be independent on the connection throughput. It happens
    both on extremely active and extremely inactive connections.
    - It is not SSH protocol/application specific. The same behavior is
    observed on e.g. pptp (port 1723) and I guess it would occur on any TCP port.
    - I use port 443 for ssh to get through the proxy at work.

    I suspect the problem might have something to do with conntrack since even my ssh connections to the server itself go through DNAT according to iptables (1.2.3.4:443 -> 192.168.0.1:22).

    Has anyone observed this behavior or have an idea? Any help is highly appreciated!

    /etc/iptables (Ext IP address replaced with 1.2.3.4):
    *mangle
    :pREROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT

    *nat
    :pREROUTING ACCEPT [0:0]
    :pOSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A PREROUTING -i vlan1 -d 192.168.0.1/255.255.255.0 -j DROP
    -A PREROUTING -p icmp -d 1.2.3.4 -j DNAT --to-destination 192.168.0.1

    -A PREROUTING -p tcp -m tcp -d 1.2.3.4 --dport 443 -j DNAT --to-destination 192.168.0.1:22

    -A PREROUTING -p tcp -d 1.2.3.4 --dport 10080 -j DNAT --to-destination 192.168.0.5:80
    -A POSTROUTING -p tcp --dport 80 -s 192.168.0.1/255.255.255.0 -d 192.168.0.5 -j SNAT --to-source 1.2.3.4

    -A PREROUTING -p tcp -d 1.2.3.4 --dport 5006 -j DNAT --to-destination 192.168.0.5
    -A POSTROUTING -p tcp --dport 5006 -s 192.168.0.1/255.255.255.0 -d 192.168.0.5 -j SNAT --to-source 1.2.3.4

    -A PREROUTING -p tcp -d 1.2.3.4 --dport 5001 -j DNAT --to-destination 192.168.0.5
    -A POSTROUTING -p tcp --dport 5001 -s 192.168.0.1/255.255.255.0 -d 192.168.0.5 -j SNAT --to-source 1.2.3.4

    -A PREROUTING -p tcp -d 1.2.3.4 --dport 1723 -j DNAT --to-destination 192.168.0.5:1723
    -A POSTROUTING -p tcp --dport 1723 -s 192.168.0.1/255.255.255.0 -d 192.168.0.5 -j SNAT --to-source 1.2.3.4
    -A PREROUTING -p udp -d 1.2.3.4 --dport 1723 -j DNAT --to-destination 192.168.0.5:1723
    -A POSTROUTING -p udp --dport 1723 -s 192.168.0.1/255.255.255.0 -d 192.168.0.5 -j SNAT --to-source 1.2.3.4
    :upnp - [0:0]
    -A PREROUTING -d 1.2.3.4 -j upnp
    -A POSTROUTING -o vlan1 -j MASQUERADE
    COMMIT

    *filter
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -i br0 -d 1.2.3.4 -j DROP
    -A INPUT -m state --state INVALID -j DROP
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -i br0 -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -p tcp -m tcp -d 192.168.0.1 --dport 22 -j ACCEPT
    :FORWARD DROP [0:0]
    -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 -m tcpmss --mss 1461: -j TCPMSS --set-mss 1460
    :wanin - [0:0]
    :wanout - [0:0]
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i vlan1 -j wanin
    -A FORWARD -o vlan1 -j wanout
    -A FORWARD -i br0 -j ACCEPT
    :upnp - [0:0]
    -A FORWARD -i vlan1 -j upnp
    -A wanin -p tcp -m tcp -d 192.168.0.5 --dport 80 -j ACCEPT
    -A wanin -p tcp -m tcp -d 192.168.0.5 --dport 5006 -j ACCEPT
    -A wanin -p tcp -m tcp -d 192.168.0.5 --dport 5001 -j ACCEPT
    -A wanin -p tcp -m tcp -d 192.168.0.5 --dport 1723 -j ACCEPT
    -A wanin -p udp -m udp -d 192.168.0.5 --dport 1723 -j ACCEPT
    COMMIT
     

Share This Page