Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

In a CentOS server I have, I want to forward port 8080 to a third-party webserver.
So I added this rule:

iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination thirdparty_server_ip:80

But it doesn't seem to work.
In an effort to debug the process, I added these two LOG rules:

iptables -t mangle -A PREROUTING -p tcp --src my_laptop_ip --dport ! 22 -j LOG --log-level warning --log-prefix "[_REQUEST_COMING_FROM_CLIENT_] "
iptables -t nat -A POSTROUTING -p tcp --dst thirdparty_server_ip  -j LOG --log-level warning --log-prefix "[_REQUEST_BEING_FORWARDED_] "

(the --dport ! 22 part is there just to filter out the SSH traffic so that my log file doesn't get flooded)

According to this page the mangle/PREROUTING chain is the first one to process incomming packets and the nat/POSTROUTING chain is the last one to process outgoing packets.

And since the nat/PREROUTING chain comes in the middle of the other two, the three rules should do this:

  1. the rule in mangle/PREROUTING logs the incomming packets
  2. the rule in nat/PREROUTING modifies the packets (it changes the dest IP and port)
  3. the rule in nat/POSTROUTING logs the modified packets about to be forwarded

Although the first rule does log incomming packets comming from my laptop, the third rule doesn't log the packets which are supposed to be modified by the second rule. It does log, however, packets that are produced in the server, hence I know the two LOG rules are working properly.

Why are the packets not being forwarded, or at least why are they not being logged by the third rule?

PS: there are no more rules than those three. All other chains in all tables are empty and with policy ACCEPT.

share|improve this question
    
First off, can we get some insight into your network geometry? In particular, we're looking to be sure that the CentOS box is not only between the client and the server, but also between the server and the client (that is, replies from the server to the client will pass through the CentOS box for reverse-modification). –  MadHatter Feb 26 '11 at 7:39
    
@MadHatter, it's very simple. My laptop is behind a router (cable-modem), my CentOS server is a public server on the internet, and the thirdparty server is just a random webserver like the one from this very website. –  GetFree Feb 26 '11 at 8:02
add comment

2 Answers

up vote 3 down vote accepted

You may need to turn on ip forwarding on the server. Try

echo 1 > /proc/sys/net/ipv4/ip_forward

share|improve this answer
2  
Gosh. This must be the silliest problem I've encounter in a long time. That was it! My DNAT rule works as expected now. Thanks. –  GetFree Feb 26 '11 at 9:33
add comment

It's all highly dependent on whether the clients, you're doing DNAT for, use your NAT-box as a gateway (+ actually replies back would use your NAT-box as well) OR NOT.

I guess they don't so then the following describes fault: {

When doing DNAT you're masking the Effective-IP with a Relay-IP belonging to NAT-box (from clients' PoV). So, a client expects to communicate with Relay-IP, not Effective-IP. Instead, client all of the sudden receives replies from Effective-IP he hasn't ever heard of.

So, when doing such a masking w/o being an intermediate gateway between client and Effective-service you need as well use SNAT (hiding clients with NAT-box-external-IP), so all replies from the Effective-IP service box go back to your NAT-gateway and then only would be de-NATed and sent back to client who initiated this.

}

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.