Wanted to see if anyone else has ever come across this. I have an ftp server running on RHEL 5.5 64-bit. I have the ftp daemon running as a non-privileged user so since it cannot bind to ports less than 1024, I'm having the daemon listen on higher ports and using iptables to redirect the traffic accordingly.

I'm logging all the denied traffic and noticing that a small percentage of the packets are not getting redirected properly. For example, I'm redirecting 443 traffic to 8443 and have a rule to allow 8443 in the filter table. While an upload is running, I see about 1 packet per second that doesn't get redirected and shows up in the filter table as 443 and is subsequently getting denied. Even if the traffic is allowed through in the filter table, the OS is not listening on that port and the ACK packet that was sent gets a RST packet back. It does not appear to impact the clients though and the daemon logs are not complaining.

Anyone see this redirect problem before?

Chad

We did a sniffer trace yesterday and I'm having our network guys take a look at it. Here's the current config - iptables was set to redirect the following and accept all packets and log everything:

[root@madfdcvftppx01 ~]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:ftp redir ports 2121
REDIRECT tcp -- anywhere anywhere tcp dpt:ssh redir ports 2222
REDIRECT tcp -- anywhere anywhere tcp dpt:https redir ports 8443
REDIRECT tcp -- anywhere anywhere tcp dpt:ftps redir ports 3333

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Here's what we see in the logs:

Nov 10 09:41:09 madfdcvftppx01 kernel: IN= OUT=eth0 SRC=<Server> DST=<Workstation> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=47358 DF PROTO=TCP SPT=8443 DPT=3085 WINDOW=8576 RES=0x00 ACK FIN URGP=0
Nov 10 09:41:09 madfdcvftppx01 kernel: IN=eth0 OUT= MAC=00:50:56:ba:0a:a6:00:21:d8:0d:61:80:08:00 SRC=<Workstation> DST=<Server> LEN=40 TOS=0x00 PREC=0x00 TTL=126 ID=12597 DF PROTO=TCP SPT=3085 DPT=8443 WINDOW=63584 RES=0x00 ACK URGP=0
Nov 10 09:41:09 madfdcvftppx01 kernel: IN=eth0 OUT= MAC=00:50:56:ba:0a:a6:00:21:d8:0d:61:80:08:00 SRC=<Workstation> DST=<Server> LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=12598 DF PROTO=TCP SPT=3085 DPT=443 WINDOW=63584 RES=0x00 ACK URGP=0
Nov 10 09:41:09 madfdcvftppx01 kernel: IN= OUT=eth0 SRC=<Server> DST=<Workstation> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=443 DPT=3085 WINDOW=0 RES=0x00 RST URGP=0
Nov 10 09:41:09 madfdcvftppx01 kernel: IN=eth0 OUT= MAC=00:50:56:ba:0a:a6:00:21:d8:0d:61:80:08:00 SRC=<Workstation> DST=<Server> LEN=40 TOS=0x00 PREC=0x00 TTL=126 ID=12599 DF PROTO=TCP SPT=3085 DPT=8443 WINDOW=63561 RES=0x00 ACK URGP=0
Nov 10 09:41:09 madfdcvftppx01 kernel: IN=eth0 OUT= MAC=00:50:56:ba:0a:a6:00:21:d8:0d:61:80:08:00 SRC=<Workstation> DST=<Server> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=3085 DPT=8443 WINDOW=0 RES=0x00 ACK URGP=0

Anyone have any ideas? We shouldn't be seeing a 443 show up at all. The logging is in the filter table. The server sends back an RST because it is not listening on 443, it is listening on 8443.

Chad