forwarding requests to another ip using IPTABLES

[ranjanjajodia]

Hi Swemic,

I don't know how to use ethreal and tcpdump. But I will study and try to use them.

But I am not sure if the first two lines that you had posted are enough - the lines together forward packets from .222 to .118 and also make them appear to have originated from .222, right? But when .118 sends back the packets, it sends them to .222; how does .222 know where to forward those to? Am I missing something in my analysis of the situation?

Thanks for the help,
Ranjan

[swemic]

Thats handled in the NAT table together with the sessionID's.
It's the nature again on IP/NAT/TCP, everuthing is handled through sessionID's.

Forward chain
192.168.1.10:1024(sessA) -> 192.168.1.222:4080(sessA)
[NAT translation]
192.168.1.222:1024(sessB) -> 192.168.1.118:4080(sessB)

Return chain
192.168.1.118:4080(sessB) -> 192.168.1.222:1024(sessB)
[NAT translation]
192.168.1.222:1024(sessA) -> 192.168.1.10:1024(sessA)

This is somewhat a simplified explanation on how it works,
however, IPTABLES has it's connection/state table where NAT translated sessions exist. It is more or less a cross-ref table with all sessionID's and used portnumbers (src/dst).

[swemic]

Btw, Ethereal is a nice GUI tool to evaluate what's going on at the network.

[ranjanjajodia]

Hi Swemic,
Thanks for the information. I am currently trying out ethreal.
Regards
Ranjan

[wanny1119]

Sorry I bother you. I am Taiwanese. I have looked at your article and want to do the port redirection procedure in the Fedora core. I just want to trasfer the addressort pair of the UDP packet to another port. such as a connection from 140.112.41.126:61588 to 140.112.41.121:3060 and I want to change the destination port from 3060 to 3366
I obeserve this paragraph:

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.118 --dport 4080 -j DNAT --to-destination 192.168.1.118:4088

however, I don't know how to add this code to what files. Please tell me what I can do?

[swemic]

You can type those commands directly in a shell as is.
And if you wish to save the configuration, all you have to do is

iptable-save

which will printout your cofiguration to std-out.
The output is possible to save into the file /etc/sysconfig/iptables
A quicker way would then obviously be

iptables-save > /etc/sysconfig/iptables

If you start iptables from your /etc/init.d/iptables that is.
A bit depending on your distro actually.

[wanny1119]

Sorry, I confused my question. I want to change the destination port when I transmit the packet.

and I type this code

iptables -t filter -A OUTPUT -o --dport 32770 -j REDIRECT --to-ports 80

However, it is wrong. I think maybe I made a mistake. And then, if this method won't work. How can I change my packets transmitted in terms of the output filter.

thanks Swedins

[swemic]

I'm not sure I really follow you here!
Do you want a port redirection from the sending host to another port?
Or is it a portredirection at final destination?

If the later one, you should add this:
(Assuming that the final destionation IP is eq 192.168.1.1)

iptables -A PREROUTING -d 192.168.1.1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.1:8080

iptables -A INPUT -d 192.168.1.1 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -d 192.168.1.1 -p tcp -m tcp --dport 8080 -j ACCEPT

Code above changes the port from 80 -> 8080 when a client connects to your host via port 80. This code is often utilized on servers where you might have Tomcat as your primary HTTP server, but Tomcat terminates on port 8080. So without the knowledge from the source of the final port, you have done a port redirection.

[wanny1119]

Hi swemic:

I think that I must clearify my problems sufferred. I need to measure the RTP streaming data on the client side. However, my client is wireless LAN link and is behind the NAT of WLAN. Thus the packets can not be retrasmitted because of no mappings in the NAT table of WLAN. The reason is the port used for the setup of RTP connection is not equal to the the RTP payload flow. Such as the illustration:
______ ______ _______
| | | | |
|___ | |____ | |
| | | | |
______ ______ _______

server NAT client

public IP Bort B(server)<===>public IP Aort A(NAT) <======> private IPort (client)


However, when the connection is established, the destination IPort of RTP payload was not public IP Aort A, but public IP Aort C. Thus there is no existing mapping of NAT table corresponding to public IP Aort C(only one mapping public IP Aort A<=>private IPort), and the packet dropped. Now I think maybe in the server I can utilize the filter table 'OUTPUT' to change the port C to port A when the packet is found to be transferred to public IP A. In the client, I can order the client to receive all packets if the IP address is public IP B and don't matter what the port is. Thus, it is another kind of 'port forwarding', but not that usually mentioned for load balancing. So in the client it is easy to set up. However, I have no idea to deal with the problem in the server. Maybe I should to survey the tunneling techniques in the linux OS. But, I need a practical solution to solve the situation. I have no confidence and it has bothered me a week.

[swemic]

OK, I believe we are in a quite different scenario here now, is this RTP not in fact just about what Passive FTP is about?
That is, first you set up a connection and after that you have another session set up for the payload?

Passive FTP scenario

1. Client:1024 -> FTP-server:21 (open)
2. Client:1204 -> FTP-server:21 (login procedure)
3. Client:1024 -> FTP-server:21 (requests Passive mode)
FTP-server:21 -> Client:1024 (Server tells client to use port 2048 as data port)
4. Client:1025 -> FTP-server:2048 (list all files)
5. Client:1025 -> FTP-server:2048 (download file(s))
6. Client:1024 -> FTP-server:21 (logout)

What happens from above is that we actually opens up two different sessions/connections to the FTP-server, that is done at lines 1 & 4.
Which if we would have a NAT/FW in between the client and server would end up with two NAT mappings in the NAT table of the FW.
However, your problem is a bit more delicate thus you utilize UDP, and I guess that to be really sure on what is going on, you (that is I) need to know a bit more how the protocoll is working.
As you know UDP is a Connection-Less oriented protocoll, which requires that the NAT/FW knows a bit of how the protocoll is working to be able setting it up correctly with return packets. That's why like UDP:53 (DNS) works like a charm in most FW's.

Is it a propritary (self made) protocoll or is it a well known? Anyhow, I think this is kind of out from the thread, the problem that is. So either we'll just start up a new thread or send me a PM
I do think this is rather intresting though, so I suggest that we'll just start up a new thread. And that you specify as much as possible there.