forwarding requests to another ip using IPTABLES

[ranjanjajodia]

Dear all,
I am trying to forward packets coming to one ip address(say 192.168.1.222 port 4080) to another ip address (say 192.168.1.11.

I tried the following rule:

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

But it did not work. I also observed that,

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

works, i.e, port redirection works.

I tried out google and also read a couple of tutorials but unfortuately I am still unable to find the problem.

I am using Red Hat 8 on both the computers.

Can any one point me to the right direction?

Thanks,
Ranjan

[swemic]

You'll need a corresponding ACCEPT rule as well. the PREROUTING is just to activate the NAT/SAT procedure.
Btw, is the IP 192.168.1.118 & 192.168.1.222 on the very same box?
If so your extra rule has to be something like this

*nat
-A PREROUTING -d 192.168.1.222 -p tcp -m tcp --dport 4080 -j DNAT --to-destination 192.168.1.118:4080
COMMIT
*filter
-A INPUT -i eth0 -p tcp -m tcp --dport 4080 -j ACCEPT
COMMIT

[ranjanjajodia]

hi Swemic,

The two IPs are of different boxes.

I have not restricted any port on 192.168.1.118. The IPTables configuration file in 192.168.1.118 is totally blank. I am able to access port 4080 on 192.168.1.118 directly. But if i try to access by redirection (from 192.168.1.222) my requests don't get redirected.

Seeing your reply, I tried specifically accepting all request to port 4080 (using IPTables) on 192.168.1.118, but it didn't work.

Thanks for your efforts,
Ranjan

[swemic]

Ok! So you have a re-direction to a server that resides on the same side as the re-director and originator?
Hmm! Sounds a bit over-done, and I suspect that you will encounter problems, due to the nature of IP. Because in your configuration the originator expects it's SYN, returns and all those IP stuff to be received from .222, but will ni fact receive them from .118. Which in your case will be rejected by the originator.

(Originator, computer that tries to connect to service 192.168.1.222:4080,
re-director is you IPTABLES FW 192.168.1.222)

I have to give this an extra thought, but I am very sure that if you want a sucess you either has to NAT the originator IP with 192.168.1.222 or you could send an ICMP redirection back to the originator, but I am not 100% sure how to do that with IPTABLES.

If you do some kind of "sniffing" with like Ethereal at the originator, you will see that my point is correct, i.e. you will receive pakets from .118 but they are rejected due to unknown connection.

[ranjanjajodia]

Hi Swemic,

Yes! you are right that the server, redirector and originator reside on the same side ( I should have realised this earlier but somehow forgot to see it in that light).

I know it is overdone but the problem is that I cannot get the originator's owner to make changes in his firewall settings to allow one more IP to which an application running on his computer can make requests.

I am running a webserver at the redirector and at the real server. I have to make the redirect invisible to the originator's firewall (hence http redirects won't work). In worst case I will have to code an http client in my redirector webserver which will request to my real server and then send back the result to the originator using the redirector web server.

I think I understand the problem now thanks to your explanation. The problem isn't as easy as I thought it will be.

If you can recommend a better option to IPTables i can try that too.

Thanks again for your efforts,
Ranjan

[swemic]

Well, you can solve this by using a NAT direction as if the .118 would be on another interface/network. So basicly you will have to hide the originators IP from destination, and that goes even for the destination, you will have to hide the destination IP for originator. That would basicly be a PROXY/NAT feature, which should be doable in IPTABLES, have not done it my self, but I would really think it should work.

An easy way to work with a few examples of this configuration example would be is you tried the FWBuilder, where you could play ariund with some few changes and see if they would work.
It is basicly a GUI for IPTABLES/IPChains and so on.

Hope this will help you out a bit.
/M

[ranjanjajodia]

Hi Swemic,

I will try out FWBuilder and also study about out about Proxy/Nat feature. If am successful I will post here the way to do it.

Thanks for the help,
Ranjan

[swemic]

Hi, I played around a bit on this, have not tested it though, but you can try it:

iptables -t nat -A PREROUTING  -p tcp  -d 192.168.1.222 --destination-port 4080 -j DNAT --to-destination 192.168.1.118 
iptables -t nat -A POSTROUTING -o eth+ -p tcp  -d 192.168.1.118 --destination-port 4080 -j SNAT --to-source 192.168.1.222

iptables -N TEST_RULE
iptables -A OUTPUT -p tcp  -d 192.168.1.222  --destination-port 4080  -m state --state NEW  -j TEST_RULE
iptables -A INPUT -p tcp  --source-port :65535  -d 192.168.1.222 --destination-port 4080  -m state --state NEW  -j TEST_RULE
iptables -A TEST_RULE  -j LOG  --log-level info --log-prefix "TEST_RULE -- ACCEPT "
$IPTABLES -A TEST_RULE  -j ACCEPT

This above will do just about what I previous explained about the NAT/PROXY problem.

[ranjanjajodia]

Hi Swemic,

Unfortunately it didn't work.
I didn't understand the intention behind the following rule:

iptables -A INPUT -p tcp  --source-port :65535  -d 192.168.1.222 --destination-port 4080  -m state --state NEW  -j TEST_RULE

Why are we specifying 65535?

Regards,
Ranjan

[swemic]

Basicly it is just an ALLOW rule,
--source-port :65535 means that the source port from originator can be any port number 0-65535, you could omitt this.

The most essential parts here is the two first lines,
PREROUTING is that we'll do a NAT translation for incomming sessions,
While the POSTROUTING is another NAT translation to ensure it is the FW's IP that is presentated at the destination, i.e. 192.168.1.118

Please try to do some ethereal/tcpdump on all involved hosts to ensure that all NAT'ing is correct