itables, what a curmudgeon ye be.

[Pikachu2000]

I'm really at a loss for ideas here. The box in question is running Debian Squeeze, and here's the deal. I *had* an iptables port redirection rule that simply won't die for some reason. I'm really hoping someone can help me make it go away.

In the process of setting up an IRC server, I'm adding the webchat interface and running it as a non-privileged user, and as such, it couldn't bind port 80. I figured I'd just forward 80 to the webchat module on 1234, so I added a rule in iptables:

in directory: /etc/network/if-up.d/
Added file: firewall
Containing:

#!/bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# Flush any existing firewall rules we might have
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

# Perform the rewriting magic.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 1234

To make a long story short, forwarding the port worked, but caused issues resolving the connecting client's hostname properly. I Removed the firewall file, and ran the following script to get rid of the forwarding. I then brought all interfaces down and up with ifdown -a and ifup -a.

#!/bin/sh
echo "Stopping firewall and allowing everyone..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

The port was still being forwarded, so I ran each command via CLI as root, and cycled the interfaces again. That didn't work either; port 80 is still being forwarded to 1234.

Both after running the script and after entering each command individually, iptables -L shows nothing:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I have not restarted the box yet. That's a last resort since this really shouldn't require it to be done, but I guess if I have to, I will.

[ehansen]

iptables -L

will only show the default table (filter). Since your rule is in the NAT table, show us the output of this:

iptables -t nat -L

[Pikachu2000]

Same thing as iptables -L. Strange, isn't it?

$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[ehansen]

Same thing as iptables -L. Strange, isn't it?

$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Hm, how are you determining that stuff is still being forwarded? Also, what about any portfowarding done on your router?

[Pikachu2000]

The webirc service only listens on port 1234, in fact it is unable to even bind to port 80 itself. But I can still access it via port 80 (and 1234), whereas prior to adding and removing the rule it was only accessible on 1234. There is no port forwarding being done on the router at all, nor by Apache, and the box has it's own public IP address.

[KenJackson]

See if you have any process that's listening to port 80:

netstat -t4ln

If no process is listening to port 80, then that machine isn't forwarding it to 1234.