port forwarding - TCP-IP

This is a discussion on port forwarding - TCP-IP ; Hi, I have a question about port forwarding.. Just as a definition.. i understand that port forwarding works like this.. my computer is in a LAN which is connected to the internet through a router. the internet sees the ip ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: port forwarding

  1. port forwarding

    Hi,
    I have a question about port forwarding..
    Just as a definition.. i understand that port forwarding works like
    this..
    my computer is in a LAN which is connected to the internet through a
    router. the internet sees the ip address of the router and forwards
    the packets to that machine. the router has to somehow figure out that
    it has to send the packets to my machine in the private network and it
    accomplishes this by 'port forwarding'..

    i was wondering if there are any pointers/documentation on how this is
    actually accomplished?
    Lets say the router's IP is 168.1.2.3 and my local computers IP is
    168.2.3.4.
    When a packet comes to 168.1.2.3 how does it actually reach 168.2.3.4.
    Does the packet have the IP 168.2.3.4 embedded in it?

    also just what is reverse-port forwarding.. sorry if this is a trivial
    question.. but the wiki's definition is confusing..

    "Reverse port forwarding, or reverse port tunnelling, is done by two
    components, usually software-based, where one component acts as a
    session-server - listening on a session-port, while the other
    component acts as a session-client to the session-server component -
    connecting to the session-server."


    -santhosh

  2. Re: port forwarding

    In article <7dcd32d1-18ea-463a-bdc8-ec1c50969a29@b1g2000hsg.googlegroups.com>,
    santhosh.kulandaiyan@yahoo.com wrote:

    >I have a question about port forwarding..
    >Just as a definition.. i understand that port forwarding works like
    >this..
    >my computer is in a LAN which is connected to the internet through a
    >router. the internet sees the ip address of the router and forwards
    >the packets to that machine. the router has to somehow figure out that
    >it has to send the packets to my machine in the private network and it
    >accomplishes this by 'port forwarding'..


    >i was wondering if there are any pointers/documentation on how this is
    >actually accomplished?


    Any time you want to know how something is "actually accomplished",
    chances are excellent that the answer is "It depends on the system
    and software version", rather than being "just as a definition"

    >Lets say the router's IP is 168.1.2.3 and my local computers IP is
    >168.2.3.4.
    >When a packet comes to 168.1.2.3 how does it actually reach 168.2.3.4.


    Depends.

    >Does the packet have the IP 168.2.3.4 embedded in it?


    No. The router has a table with 168.1.2.3 -> 162.2.3.4 in it.

    >also just what is reverse-port forwarding.. sorry if this is a trivial
    >question.. but the wiki's definition is confusing..
    >
    >"Reverse port forwarding, or reverse port tunnelling, is done by two
    >components, usually software-based, where one component acts as a
    >session-server - listening on a session-port, while the other
    >component acts as a session-client to the session-server component -
    >connecting to the session-server."
    >


    That's for the case where you have a firewall that blocks outside
    systems from initiating access to inside systems, and one of the
    inside systems wants to break that security policy. It does that
    by initiating a connection to some outside system, thus "holding
    the door open" in the firewall. There are different variations
    on what happens after that to allow outside systems to connect
    to the inside system (or systems.)

  3. Re: port forwarding

    On Thu, 29 May 2008 04:02:56 -0700, santhosh.kulandaiyan@yahoo.com wrote:

    > Hi,
    > I have a question about port forwarding.. Just as a definition.. i
    > understand that port forwarding works like this..
    > my computer is in a LAN which is connected to the internet through a
    > router. the internet sees the ip address of the router and forwards the
    > packets to that machine. the router has to somehow figure out that it
    > has to send the packets to my machine in the private network and it
    > accomplishes this by 'port forwarding'..
    >
    > i was wondering if there are any pointers/documentation on how this is
    > actually accomplished?
    > Lets say the router's IP is 168.1.2.3 and my local computers IP is
    > 168.2.3.4.
    > When a packet comes to 168.1.2.3 how does it actually reach 168.2.3.4.
    > Does the packet have the IP 168.2.3.4 embedded in it?


    The router remembers this connection. Then it replaces the original
    destination IP address (di) in the Ip packet with your local IP address
    (li) and continues as if nothing happened. Now it suddenly sees this
    packet as a packet destined to your local address and sends it on it's
    merry way.

    It remembers the connection (a connection is defined by source-ip (si),
    source-port (sp), destination-ip (di) and destination-port (dp)) because
    it must de-nat the return packets. If it sees a packet from you local
    machine from port dp that is addressed to si:sp, it knows that it must
    replace the source ip in that packet (your local machines ip) with it's
    internet ip.

    That way, the machine on the internet only knows that it has a connection
    from si:sp to di:dp. The return packets are correctly addressed, they
    come from di:dp and go to si:sp.

    (Remember, on the return packets, source and destination are reversed).

    Your local machine also sees a normal conversation, but your machine sees
    a conversation from si:sp to li:dp and sends the return packets from
    li:dp to si:sp.

    This works beautifully, and is used all the time. This works just great
    for many protocols, like http (webserver), smtp (mailserver) and many
    others.

    However, it IS a hack and breaks sometimes. Most noticeably, it breaks on
    protocols that embed the IP addresses in the data stream and use those to
    set up a secondary stream.

    A good example is ftp. When you do an ls, get or put, what happens
    underneath is that the two peers say to each other, lets set up a new
    session, use this IP address and that (other) port.

    When there is no NAT involved, there is no problem. One side tells the
    other to connect to iport and starts to listen for connections on that
    ip on that port.

    When NAT is involved, this does not work. Suppose your local machine
    tells the other side, I'm listening on 192.168.0.1 port 12345. But the
    other side cannot reach that IP address, it's a local address on your LAN.

    So why does this often work in practice? Because the router that does the
    NAT, not only translates the IP addresses in the IP header as described
    above. It also listens in on the data, and translates the "I'm listening
    on ort" to "I'm listening on ort".
    It intercepts your data stream and modifies it on the fly.

    It also adds a new translation (what we called a remembered connection
    above) so when the remote computer connects to ort,
    it translates this to ort. Effectively it adds a new
    entry to the port-forwarding table on the fly, right next to your port-
    forwarding of the ftp connection.

    So the router does a lot of work, invisible for you. However, this does
    depend on your router correctly recognizing ftp sessions. Normally, it
    assumes that anything addressed to port 21 is a ftp session. If you run
    ftp on another port than 21 (2121 is a popular choice), things tend to
    break when NAT is involved.

    Other protocols that break on nat without additional helping (linux-
    speak) or fix-ups (Cisco speak) are f.i. SIP, pptp, h323, and many others.

    Some protocols are even impossible to NAT. IPSec is the prime example,
    although the specs are now amended so this has been made possible (look
    at nat-t aka udp-encapsulation).

    >
    > also just what is reverse-port forwarding.. sorry if this is a trivial
    > question.. but the wiki's definition is confusing..
    > "Reverse port forwarding, or reverse port tunnelling, is done by two
    > components, usually software-based, where one component acts as a
    > session-server - listening on a session-port, while the other component
    > acts as a session-client to the session-server component - connecting to
    > the session-server."
    >


    Reverse port forwarding is something completely else. To understand it,
    you have to understand first that there is another kind of port
    forwarding than what we discussed above.

    The context is when you have some connection (most notably a ssh
    connection) to another host. Ssh has some very nice features, one is that
    if you ask it nicely, it starts to listen on a certain port, any packet
    that gets send to that port, is emitted on the remote machine.

    For instance, I can make a ssh connection from work to home. But I cannot
    make an imap connection from work to home, the firewall forbids it.

    (In fact, the firewall forbids ssh as well, but there are plenty of
    tricks to get around that).

    Now I forward the imap port through this ssh connection from my local
    machine to home. So if I connect to 127.0.0.1:imap at work, I end up with
    a connection to the imap server at home.

    What happens is almost the same as what your router does when it forwards
    ports, but instead of one router, we now have two tunnel ends. Send a
    packet to the start of the tunnel, and it gets out at the other end of
    the tunnel. IPs get translated properly in this process, just like your
    Internet router does when it forwards to the local lan. And it knows how
    to handle the return traffic, just like your Internet router does all
    kind of magic to make that work.

    Reverse port forward is exactly the same, but now the tunnel endpoints
    are reversed. I make a ssh connection from work to home, and the endpoint
    at home starts to listen on the imap port and forwards those packets to
    work over the tunnel. Exactly the same process as above, but in the
    reverse direction of the direction we set up the ssh connection.

    HTH,
    M4

  4. Re: port forwarding

    > On May 30, 4:53*am, Martijn Lievaart wrote:

    Thanks Martijn. The explanation is very clear!!
    As you explained NAT has some problems in connections which need to be
    maintained end-to-end. And also is IPv6 an architecture to get rid of
    the problems with NAT (because now we can have unique IP addresses for
    every machine instead of many machines sharing a gateway IP).?

    Thanks
    Santhosh

  5. Re: port forwarding

    In article ,
    santhosh.kulandaiyan@yahoo.com wrote:
    >And also is IPv6 an architecture to get rid of
    >the problems with NAT (because now we can have unique IP addresses for
    >every machine instead of many machines sharing a gateway IP).?


    Suppose I have a server... doesn't matter much what it is. And
    the server gets sick and needs to be removed from active service
    while I nurse it back to health. But I have a backup server ready
    to go and take over the responsibilities of the first.

    If we proceed along the lines of what is implied by your question
    about getting rid of the problems with NAT, then it follows that we
    have been forced to get rid of NAT. So how do I bring my backup
    server into active execution -- seeing as, by the definition you
    gave, the backup server must have a different public IP than the
    first server ? If I were using NAT, I could just do a one-line change
    configuration at the NAT device and the packets addressed to the
    old IP would start going to to the new internal IP. But since NAT
    is now (hypothetically) disallowed, I either have to swap the IPs
    on the machines, or I have to somehow notify all of the clients of
    the new IP address. Swapping IPs is next to impossible to do
    simultaneously with no disruption in service... and since I might
    be running multiple servers on the same machine and only some of the
    functionality might be sick, swapping IPs might be the wrong thing to do.
    Notifying all of the clients of the new IP address probably means
    updating the IP in DNS servers -- but DNS servers are a heirarchical
    system each of which is *designed* to cache for at least a few minutes.
    There are mininum cache timeouts in the DNS standards -- it is not
    permitted to configure your DNS so that all of your information
    times out in (say) 1 second no matter where it travels to.

    The issue of having multiple services running on the same machine, only
    some of which are to be moved, together with a minimal-disruption
    requirement, can only be solved in the NAT-is-forbidden situation
    by an internal requirement that each server may run only one service --
    because when NAT is forbidden, then the only way to move services
    independantly of each other is by having different IP addresses for
    each different service.


    Mental exercise: if you get rid of NAT, how should google and similar
    systems handle their load balancing ? You know that google runs
    clusters of search hosts (aand they get pulled down and taken up at need),
    not just One Horking Big Computer. If each of those hundreds of
    servers must have an individual IP because you have gotten "rid" of NAT,
    then how are you going to handle the situation?

  6. Re: port forwarding

    In article ,
    Walter Roberson wrote:

    >Mental exercise: if you get rid of NAT, how should google and similar
    >systems handle their load balancing ? You know that google runs
    >clusters of search hosts (aand they get pulled down and taken up at need),
    >not just One Horking Big Computer. If each of those hundreds of
    >servers must have an individual IP because you have gotten "rid" of NAT,
    >then how are you going to handle the situation?


    I hope those words were not intended to say what they seem to say, that
    NAT is the only, best, or even a reasonable way to do load balancing
    and fail-over. At least until recently, knowledgable people considered
    NAT an intolerably nasty kludge of a mess of a brain fart without any
    redeeming value except the lack of cheap enough alternatives in certain
    cases.

    I've no idea whether Google uses NAT, but they certainly don't need to
    for lack of alternatives, any more than the DNS roots, Akamai, and many
    other efforts that involve the robust provision of services from many
    computers are forced to use NAT.


    Vernon Schryver vjs@rhyolite.com

  7. Re: port forwarding

    Hello,

    Walter Roberson a écrit :
    > santhosh.kulandaiyan@yahoo.com wrote:
    >
    >>And also is IPv6 an architecture to get rid of
    >>the problems with NAT (because now we can have unique IP addresses for
    >>every machine instead of many machines sharing a gateway IP).?


    IPv4 and IPv6 architectures are not fundamentally different. The main
    difference is the much bigger IPv6 global address space which allows to
    assign to any host on earth as many global IPv6 addresses as you need.

    > Suppose I have a server... doesn't matter much what it is. And
    > the server gets sick and needs to be removed from active service
    > while I nurse it back to health. But I have a backup server ready
    > to go and take over the responsibilities of the first.
    >
    > If we proceed along the lines of what is implied by your question
    > about getting rid of the problems with NAT, then it follows that we
    > have been forced to get rid of NAT. So how do I bring my backup
    > server into active execution -- seeing as, by the definition you
    > gave, the backup server must have a different public IP than the
    > first server ? If I were using NAT, I could just do a one-line change
    > configuration at the NAT device and the packets addressed to the
    > old IP would start going to to the new internal IP. But since NAT
    > is now (hypothetically) disallowed, I either have to swap the IPs
    > on the machines, or I have to somehow notify all of the clients of
    > the new IP address. Swapping IPs is next to impossible to do
    > simultaneously with no disruption in service...


    Why ? You could use a "floating" dedicated address that is dynamically
    assigned to the active server by some high availability mechanism such
    as heartbeat.

    > and since I might
    > be running multiple servers on the same machine and only some of the
    > functionality might be sick, swapping IPs might be the wrong thing to do.


    You could use a separate address for each service.

    > Notifying all of the clients of the new IP address probably means
    > updating the IP in DNS servers -- but DNS servers are a heirarchical
    > system each of which is *designed* to cache for at least a few minutes.


    Actually only the authoritative part of the DNS architecture is
    hierarchical by design. Not caching DNS.

    > The issue of having multiple services running on the same machine, only
    > some of which are to be moved, together with a minimal-disruption
    > requirement, can only be solved in the NAT-is-forbidden situation
    > by an internal requirement that each server may run only one service --


    Each /address/.

    > because when NAT is forbidden, then the only way to move services
    > independantly of each other is by having different IP addresses for
    > each different service.


    You say it, different /addresses/.

    > Mental exercise: if you get rid of NAT, how should google and similar
    > systems handle their load balancing ?


    What about DNS round robin, anycast routing and reverse proxy ?

  8. Re: port forwarding

    On Fri, 30 May 2008 05:12:02 -0700, santhosh.kulandaiyan@yahoo.com wrote:

    >> On May 30, 4:53Â*am, Martijn Lievaart wrote:

    >
    > Thanks Martijn. The explanation is very clear!! As you explained NAT has
    > some problems in connections which need to be maintained end-to-end. And
    > also is IPv6 an architecture to get rid of the problems with NAT
    > (because now we can have unique IP addresses for every machine instead
    > of many machines sharing a gateway IP).?


    Yes, but in .us en .eu ipv6 has still to take off. So don't hold your
    breath.

    Besides, although ipv6 works very well -- I have been running it with no
    problems for some two years now[1][2] --, I think the real problems with
    ipv6 will start to show up when it gets widely deployed. I'm mainly
    concerned that firewalls are not as mature for ipv6 as they are for ipv4
    [3].

    M4

    [1] I even run some services exclusively over IPv6.
    [2] It can be a bitch to set up though. Especially on Windows (very
    limited support afaik) and Linux (some strange design decisions means
    applications must especially target Linux IPv6, or you have to turn of
    IPv4 support in the application to get IPv4 support).
    [3] Which is in some cases even not very mature for IPv4 either.

  9. Re: port forwarding

    Hello,

    Martijn Lievaart a écrit :
    >
    > some strange design decisions means
    > applications must especially target Linux IPv6,


    Please can you elaborate a bit ?

    > or you have to turn of
    > IPv4 support in the application to get IPv4 support


    Huh ? Turn off IPv4 support to get IPv4 support ?

  10. Re: port forwarding

    On 2008-05-30 08:12:02 -0400, "santhosh.kulandaiyan@yahoo.com"
    said:

    >> On May 30, 4:53*am, Martijn Lievaart wrote:

    >
    > Thanks Martijn. The explanation is very clear!!
    > As you explained NAT has some problems in connections which need to be
    > maintained end-to-end. And also is IPv6 an architecture to get rid of
    > the problems with NAT (because now we can have unique IP addresses for
    > every machine instead of many machines sharing a gateway IP).?
    >
    > Thanks
    > Santhosh



    This post brings up that interesting debate about NAT, where IPv6 is
    hailed as perhaps the demise of this functionality.

    I don't think that's necessarily a good thing.

    There are many good reasons (security, privacy, dissidents
    communicating from embattled countries) where NAT adds value in the
    non-technical sense. I for one, do not want every device I own / carry
    / buy / purchase / configure uniquely identifiable for any crackpot
    government or ISP to mess with. I have nothing to hide, however, the
    world is very much becoming a place where people like to take advantage
    of postulating an assumption that gives them an invalid permission to
    look at things just because they are contained in a piece of technology.

    We'd do well as technologists to make sure that the core of our
    communication protocols can't be twisted to evil ends. The IPv4
    "founders" did a pretty good job. I hope we're as good as they were /
    are.

    /dmfh

    --
    _ __ _
    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


  11. Re: port forwarding

    In article ,
    Digital Mercenary For Honor wrote:

    >There are many good reasons (security, privacy, dissidents
    >communicating from embattled countries) where NAT adds value in the
    >non-technical sense. I for one, do not want every device I own / carry
    >/ buy / purchase / configure uniquely identifiable for any crackpot
    >government or ISP to mess with.


    If you have the least honest concern about your devices being uniquely
    identifiable, it would be very unwise to rely on NAT for any sort of
    anonymity, or any other sort of security.

    Any sort of security including anonymity *is* a technical issue. The
    non-technical senses arise only when the grievously uniformed, the
    self-promoting security experts, the snake oil vendors, the politicians,
    and the charletans get involved. (there may be some redundancy there)


    Vernon Schryver vjs@rhyolite.com

  12. Re: port forwarding

    On Thu, 12 Jun 2008 20:46:20 -0400, Digital Mercenary For Honor wrote:

    [ NAT ]

    > We'd do well as technologists to make sure that the core of our
    > communication protocols can't be twisted to evil ends. The IPv4
    > "founders" did a pretty good job. I hope we're as good as they were /
    > are.


    Aside from Vernons excelent points, I want to note that IPv4 NAT is a
    horrible hack, an ugly kludge, something that needs to die.

    If we want NAT support in IPv6, and I do want that, it should be done
    correctly. And because the protocols running on top of IP must be aware
    of this, many popular protocols need to change, f.i. FTP, SIP, H232 and
    many, many others.

    I'm not holding my breath on this happening. We're between a rock and a
    hard place. Either we forbid NAT in IPv6, in which case it will be
    written and will just be as horrible as in IPv4, or we do it right, which
    is not going to happen.

    In the end, IPv6 will have NAT just like IPv4, because it can be written
    so someone will write it, and it will be horrible.

    M4

  13. Re: port forwarding

    In article ,
    Martijn Lievaart wrote:

    >If we want NAT support in IPv6, and I do want that, it should be done
    >correctly. And because the protocols running on top of IP must be aware
    >of this, many popular protocols need to change, f.i. FTP, SIP, H232 and
    >many, many others.


    That sentiment is self-contradictory, because most of the preceived or
    claimed advantages of IPv4 NAT are based on its evil nature starting
    with translating addresses covertly and (often only supposedly) not
    changing application protocols or applications.

    On the other hand, many application protocols have long since been
    changed to support overt network address translating or been designed
    to support it from the start. For some protocols including HTTP,
    proxies or application layer relays have long been popular.


    Vernon Schryver vjs@rhyolite.com

  14. Re: port forwarding

    > However, it IS a hack and breaks sometimes. Most noticeably, it breaks on
    > protocols that embed the IP addresses in the data stream and use those to
    > set up a secondary stream.
    >
    > A good example is ftp. When you do an ls, get or put, what happens
    > underneath is that the two peers say to each other, lets set up a new
    > session, use this IP address and that (other) port.


    Seems like you simply forgotten of active and passive modes of FTP...
    NAT agent do not make any troubles, when FTP is running in passive
    mode, when
    it does not embed addressing information into FTP payload.
    The problem, indeed, may exist when FTP is running in active mode,
    when it does
    embed addressing information into FTP payload, but, please fix me if I
    wrong - most
    modern implementations of NAT agents include ALG modules as a way of
    mitigating
    this type of problems.

    mb

  15. Re: port forwarding

    maximb a écrit :
    >
    > Seems like you simply forgotten of active and passive modes of FTP...
    > NAT agent do not make any troubles, when FTP is running in passive
    > mode, when it does not embed addressing information into FTP payload.


    Passive mode does embed addressing information. Standard passive mode
    (PASV) embeds both address and port information, while extended passive
    mode (EPSV) embeds only the port information.

    > The problem, indeed, may exist when FTP is running in active mode,
    > when it does embed addressing information into FTP payload, but,
    > please fix me if I wrong - most modern implementations of NAT agents
    > include ALG modules as a way of mitigating this type of problems.


    Those ALG modules don't work on encrypted FTP connections, and usually
    by default they only work on FTP connections using the standard port 21.

  16. Re: port forwarding

    On Fri, 04 Jul 2008 04:09:03 -0700, maximb wrote:

    >> However, it IS a hack and breaks sometimes. Most noticeably, it breaks
    >> on protocols that embed the IP addresses in the data stream and use
    >> those to set up a secondary stream.
    >>
    >> A good example is ftp. When you do an ls, get or put, what happens
    >> underneath is that the two peers say to each other, lets set up a new
    >> session, use this IP address and that (other) port.

    >
    > Seems like you simply forgotten of active and passive modes of FTP...
    > NAT agent do not make any troubles, when FTP is running in passive mode,
    > when
    > it does not embed addressing information into FTP payload. The problem,


    In passive mode, there is trouble if the server is natted, in active
    mode, there is trouble if the client is natted.

    > indeed, may exist when FTP is running in active mode, when it does
    > embed addressing information into FTP payload, but, please fix me if I
    > wrong - most


    In both modes IP information is send over the control stream.

    > modern implementations of NAT agents include ALG modules as a way of
    > mitigating
    > this type of problems.


    Yes, but to get back on the original quote, nat is an awful hack that
    needs an ALG for many protocols, many of which where never designed with
    NAT in mind.

    Another area where the hackinesh of NAT comes forward, timeouts on natted
    UDP. Impossible to do right (exactly the same goes for firewalling UDP
    [1]). In many cases you can only estimate and hope it never breaks (or
    recovers when it breaks).

    M4

    [1] In fact, firewalling and natting are remarkably similar in most
    areas, you need to keep almost exactly the same state.

+ Reply to Thread