21:32 - Wednesday, 23 April 2014

Port Forwarding IPTABLES Public IP


i have a computer linuxbox_1.eth0 public ip 89.40.x.y
eth1 public ip 85.121.a.b
i have another linuxbox_2. ethx public ip 86.34.c.d

what i want to do is forward port 8001 from linuxbox_1 eth0 89.40.x.y:8001 to linuxbox_1 eth1 85.121.a.b,

and then forward again port 8001 from linuxbox_1 eth1 85.121.a.b:8001 to linuxbox_2 ethx 86.34.c.d:80

i have searched for answers using google “that knows everything” but this time it has failed.
i would like to use IPTABLES or any other tool like rinetd.
i tryed rinetd but it somehow mistakes the eths
sorry for my bad english.

What do you mean by “rinetd mistakes the eths”? Do you get an error on starting rinetd? Does it start but not listen as you were expecting? What configuration did you give it on each machine? (you should add this detail to your question).

The correct syntax for the two redirects you describe is:

89.40.x.y     8001    85.121.a.b    800185.121.a.b    8001    86.34.c.d     80

but if both the 89.40.x.y and 85.121.a.b are associated with interfaces on the same server, would not the single line

89.40.x.y     8001    86.34.c.d     80

do the trick?

EDIT: as you say you are looking to have the traffic to 86.34.c.d to travel down the route associated with 85.121.a.b then you have a routing issue. You can force packets for a particular address to be routed down a particular interface with:

route add -host 86.34.c.d eth1

If you run the command route (with no params) it will display your current routing table so you can do that before and after to see the difference. route del 86.34.c.d will remove the new route. This assumes that the equipment traffic from eth1 eventually travels down is able to route packets for 86.34.c.d to the right place.

To make the change permanent (so it survives a reboot) you need to add the command to an appropriate place in your startup scripts (the best way to do this depends on which Linux variant you are running). Don’t do this until you have confirmed it works as desired though – you don’t want to accidentally change the routing table so you can’t get to the machine from your current location and have the incorrect route reapply after reboot.

iptables port forwarding rewrites the TCP headers, so your application will see the packet coming from the last hop in the forwarding chain. So if that’s what you’re trying to hack, iptables port forwarding can’t help you.

IP spoofing might help, but it’s complicated. And it might not working if your application needs can’t send directly back to the originating sender directly.

(I haven’t used rinetd so I can’t comment there.)

It can be done with iptables’ DNAT target (in nat’s PREROUTING). But a few things in the checklist are:

  • net.ipv4.ip_forward=1
  • iptables’s FORWARD chain permits forwarding as well for those packets
  • Source of the request (IP) is being translated as well (SNAT/MASQUERADE) otherwise destination will try to talk back directly (or unless its properly routed back, like in case it uses DNATing box as its gateway).