Port Forwarding With Iptables

I am fairly new to all of this and have checked out other solutions but none are working for me.

I need to route all incoming requests on port 10443 to a remote server (say 111.222.333.444 on port 443). How would i se this up?

So fari have done:

iptables -A INPUT -i eth0 -p tcp --dport 10443 -j ACCEPT

Thats as far as I got ..
Who is Participating?
Gabriel OrozcoSolution ArchitectCommented:
hello again

you need to connect to the other server at port 443.

what program will be listening on that port?

do you need to be able to log on to that server but only have tcp/443 to do so?
if that's the case, you can do either:
- redirect ssh on that server to tcp/443
- setup a vpn. I would use openvpn because it is one of the best and *also* pretty easy to install.

if it is https, then I'm no sure if https will accept the redirection. the rule would be something like
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 10443 -j DNAT  --to-destination 111.222.333.444:443
iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 443 -j ACCEPT
iptables -A POSTROUTING -o eth0 -p tcp --dport 443 -j MASQUERADE

try that. if it does not work, I would setup squid as a proxy. that way it should work without problem for https provided you have correct acl's
Gabriel OrozcoSolution ArchitectCommented:

INPUT is only for connections that will be handled by a program on your linux itself
you need to
to rewrite the target address, you need to use PREROUTING from the nat table.

so the rule should be:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 10443 -j DNAT  --to-destination 111.222.333.444:443
Gabriel OrozcoSolution ArchitectCommented:
forgot to say FORWARD should be enabled or no packets will pass the filter:

iptables -A FORWARD -i eth0 -p tcp --dport 10443 -j ACCEPT
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

guitarclapAuthor Commented:
hmmm.. i get connection timed out ... how can i test to see if the request are coming into port 10443 and if they are going out? also, could i use this to check (server IP is google)

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 10443 -j DNAT --to-destination

shouldn't that forward http://www.sitename.com:10443 to google?

Gabriel OrozcoSolution ArchitectCommented:
well... is eth0 your internal interfase?

can you post your firewall output? need to see if you are not blocking the forward on some other place

we need the output of
iptables -L -vn -t nat
iptables -L -vn
dude, it won't work this easy if your DNAT destination is not behind your port-forwarding machine.

example: some host (H), port forwarding machine (PF), destination server (S)
H sends packet to PF. PF changes packet's destination to S and forwards it to S. S gets the packet and sends the reply (src = S, dst = H) - to H (!), not to PF (!). The point is, if S is behind PF (i.e. PF is it's default gateway), the packet will pass thru PF, PF will recognize it as the reply to recently-DNATted packet, change this packet's src to PF and send it to H.
In your case, S's reply doesn't pass thru PF, so the host H gets a reply directly from S, with src = S. As it didn't send any request to S (remember, it sent a request to PF), it won't accept this packet. I had this issue some time ago, a very savvy friend of mine explained that too me. Feel free to ask any questions if you need anything clarified.

As for how to make this work: if you have control over the server S, you can setup a tunnel (not necessary an encrypted one,  the IP GRE or IP IP tunnel would suffice), and forward the packet to server's tunnel address. It'll reply thru the tunnel, and DNAT will fix the packet's src back. Sounds really heavy, and I remember fucking around for several days before I made it work. IIRC, I added a firewall rule that MARKed everything that came from the tunnel interface (not IP), and a routing policy to route every packet with this mark thru the tunnel (you need iproute2).

Anyway, if it's too difficult, or if the server is beyond your control, you should use a proxy that will actually access S itself. Sorry, don't remember the details.
Gabriel OrozcoSolution ArchitectCommented:
there is another way:

add a NAT/MASQUERADE so all is managed by your host. Previous description is right, but if you rewrite the "from" address when packed traverse PF, then the answer from S will go back to PF which in turn can reply to H.

to do this, add something like
iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE
(assuming eth1 is your default connection. it can be eth0 of course)
guitarclapAuthor Commented:
Well I guess I should say what exactly I need done. And sorry, I am new to all of this -- I am being forced to set this up.

We have a remote server that we need to connect to via port 443.  We have a username and password to bypass the firewall.

We need to be able to run something like www.oursite.com:10443 and have it communicate with the remote server on port 443 because the remote server only allows connections from our server.  They informed us we need to setup a tunnel for this...

eth1 incoming
eth0 outgoing

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.