I've configured iptables v1.2.9 on a FC2 box for my network and everything is working perfectly. Well, almost. *1* of my 60 clients is having trouble connecting to a RAS running some custom software. Here is what happens: The client comes in on my external interface and gets to the PREROUTING and FORWARD chains. The two following rules complete my forwarding process: iptables -t nat -A PREROUTING -p tcp -i $EXT_IFACE -d $EXT_IP --dport $EVOPORT -j DNAT --to-destination $EVORAS_IP:EVOPORT iptables -A FORWARD -p tcp -i $EXT_IFACE -d $EVORAS_IP --dport $EVOPORT -j ACCEPT The client will successfully connect to the server and everything is fine. From that point, if the client closes the software (normally or abnormally) and immediately tries to load the software and connect again, they will show up in my logs as a dropped packet from the INPUT chain resulting from these rules: iptables -A INPUT -d $EXT_IP -i $EXT_IFACE -j LOG_DROP iptables -A INPUT -j DROP Excerpt from LOG_DROP table (excerpts from /var/log/messages are located at the end of this e-mail): iptables -A LOG_DROP -j LOG --log-tcp-options --log-ip-options --log-prefix '[IPTABLES DROP] : ' iptables -A LOG_DROP -j DROP Now, this cycle continues on every login. The client will be able to login, then won't, then will, then won't, etc. >From the client's side - They can always start the program and log in. It will appear as if they are connected until they try and fetch their first payload of data. At that time, if they've encountered the problem I'm describing, the program will hang. So, basically, I'm confused as to how a packet destined for an internal machine is all of a sudden being routed to the local host. Has anyone seen anything like this before? Since, it's only 1 client out of 60, I would normally be quick to say "It's on your side!" and turn away, but I'm just very interested in why this is happening and I'd like to understand as much as possible about the situation before I approach whatever is on their side. Questions: 1) Considering the ?on/off? nature of this problem - Could this be some sort of time out issue? Or is that barking up the wrong tree? 2) With the proper and proven rules intact ? What could cause a packet to get routed to the wrong chain? 3) The dropped packets always seem to be ACKs. This seems like an important piece of the puzzle, but I?m not sure how it fits in. Is this a significant point? Anyone have any advice for me? Need more information? Please let me know. The dropped packets look like this in /var/log/messages: Jun 13 14:17:13 firewall kernel: [IPTABLES DROP] : IN=eth1 OUT= MAC=00:40:f6:2c:0f:a9:00:a0:c8:10:5e:02:08:00 SRC=X.X.X.X DST=X.X.X.X LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=2209 DF PROTO=TCP SPT=59141 DPT=9999 WINDOW=65535 RES=0x00 ACK URGP=0 OPT (0101050AE9FDF3B9E9FDF96D) Jun 13 14:17:22 firewall kernel: [IPTABLES DROP] : IN=eth1 OUT= MAC=00:40:f6:2c:0f:a9:00:a0:c8:10:5e:02:08:00 SRC=X.X.X.X DST=X.X.X.X LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=28870 DF PROTO=TCP SPT=59141 DPT=9999 WINDOW=65535 RES=0x00 ACK URGP=0 OPT (0101050AE9FDF3B9E9FDF96D) Jun 13 14:17:39 firewall kernel: [IPTABLES DROP] : IN=eth1 OUT= MAC=00:40:f6:2c:0f:a9:00:a0:c8:10:5e:02:08:00 SRC=X.X.X.X DST=X.X.X.X LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=25485 DF PROTO=TCP SPT=59141 DPT=9999 WINDOW=65535 RES=0x00 ACK URGP=0 OPT (0101050AE9FDF3B9E9FDF96D) Thank you for your time, Joshua
