[quite solved] Tiny iptables-problem

[Jimini]

Hi there,
I have a really small, but annoying problem: I've set up an IRCD on a local machine and want to route all incoming traffic on port 9999 to that machine on port 6667. That's it.

My rules:

[twelfthnight]

Are you redirecting to 10.0.0.2:6667 while your server listens to port 9999 ?

[Yuu]

Hi,

@twelfthnight : I've understanded that he wants to redirect 127.0.0.1:9999 to 10.0.0.2:6667, but maybe I'm wrong.

@Jimini : Maybe you should try to modify the end of your second iptable rule : --to-destination 10.0.0.2 10.0.0.2:6667

If the problem persists, maybe you should try disabling rp_filter (be carefull) with :

[Hu]

The rp filter should not be an issue here. Jimini, please post the output of iptables-save on the edge device and clarify what you want. You mention port 6667 in your opening text and it is shown in the iptables output, but the iptables commands you give and the netstat output indicate that you want everything to be on port 9999 at every stage.

[Jimini]

At first, thanks for your replies and sorry for my faulty post - of course, the output of netstat I posted above is wrong - the server listens on 6667.

- UnrealIRCD is running on port 6667 on 10.0.0.2
- iptables runs on the router (10.0.0.1)
- all traffic from the outside arrives on 10.0.0.1:9999 and should be[/code] routed to 10.0.0.2:6667

The output of iptables-save is really huge, so I put it here. I am a little astonished about ppp0 appearing here - I removed this interface about one week ago, since I do not neet ppp anymore to connect.

Best regards,
Jimini
_________________
"The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents." (H.P. Lovecraft: The Call of Cthulhu)

[Hu]

Interfaces in iptables are just strings. At match time, the kernel compares those strings to the interface name using a defined set of rules. Therefore, it is legal, though not often useful, to have a rule which names an interface that does not exist.

Looking at the pastebin, I am surprised at how many junk MARK rules you have. That is not normal, especially to have so many of them that do the same thing. You should probably investigate whatever daemons you allowed to manage your firewall. One of them seems to be malfunctioning for it to have added useless rules like that.

For your immediate problem, there are a few tweaks. Your third PREROUTING rule is sufficient to do what you requested, but is a bit too broad in my opinion. It will affect any TCP traffic that crosses the router bound for port 9999, regardless of which interface it entered on or which machine it was meant to reach. Your fourth FORWARD rule is apparently meant to be used here, but is incorrect. The TCP port specified in the FORWARD rule is the one which will appear on the forwarded packet if it is actually sent. Thus, at that stage in the process, you should be matching on port 6667, not 9999. Also, remember to enable IP forwarding if you have not already done so.

Your sixth FORWARD rule looks useless. Traffic with a source of localhost should not be traversing real interfaces.

[Jimini]

[Hu]

[Jimini]

Hm, I set up tcpdump and let a friend of mine try to connect to the server - it worked and I don't know why. I isolated the problem in that way, that connecting to port 9999 from the outside works fine. From the inside it doesn't - I can only reach the IRCD by connecting to 10.0.0.2 directly.

WAN => 10.0.0.1:9999 => is routed to 10.0.0.2:9999
LAN => 10.0.0.1:9999 => failure
LAN => 10.0.0.2:9999 => works

However, I executed tcpdump port 9999 (someone connects from the outside):

[Hu]

[Jimini]

Seems as this will be the only practicable solution. Thank you for your helpful hints!

Best regards,
Jimini
_________________
"The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents." (H.P. Lovecraft: The Call of Cthulhu)