Port Forwarding With Iptables

Posted on 2006-05-01
Last Modified: 2010-03-18
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 ..
Question by:guitarclap
    LVL 19

    Expert Comment


    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
    LVL 19

    Expert Comment

    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
    LVL 1

    Author Comment

    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 to google?

    LVL 19

    Expert Comment

    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
    LVL 4

    Expert Comment

    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.
    LVL 19

    Expert Comment

    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)
    LVL 1

    Author Comment

    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 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

    LVL 19

    Accepted Solution

    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

    Featured Post

    Why You Should Analyze Threat Actor TTPs

    After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

    Join & Write a Comment

    I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
    Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
    Here's a very brief overview of the methods PRTG Network Monitor ( offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
    This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

    729 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now