Connect two TCP connections? - TCP-IP

This is a discussion on Connect two TCP connections? - TCP-IP ; I have an interesting problem... I need two clients to connect to each other via TCP. Both are behind firewalls/routers/etc, and port forwarding is not a viable solution. Normally, I would just have them both connect to a third party, ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Connect two TCP connections?

  1. Connect two TCP connections?

    I have an interesting problem... I need two clients to connect to each
    other via TCP. Both are behind firewalls/routers/etc, and port
    forwarding is not a viable solution. Normally, I would just have them
    both connect to a third party, and the third party would just relay
    data between the two clients. However, this also is not a viable
    solution.

    How, then, do I get the two clients to connect?

    One thing I was thinking about is to have both clients connect to the
    third party, and then have the third party somehow connect the two
    connections... Is this at all possible? Are there any other things you
    guys can think of?

    Your help is greatly appreciated.

    Burak


  2. Re: Connect two TCP connections?

    On Jun 15, 12:48 pm, b...@stolenradio.com wrote:
    > I have an interesting problem... I need two clients to connect to each
    > other via TCP. Both are behind firewalls/routers/etc, and port
    > forwarding is not a viable solution. Normally, I would just have them
    > both connect to a third party, and the third party would just relay
    > data between the two clients. However, this also is not a viable
    > solution.


    Why?

    > How, then, do I get the two clients to connect?
    >
    > One thing I was thinking about is to have both clients connect to the
    > third party, and then have the third party somehow connect the two
    > connections... Is this at all possible? Are there any other things you
    > guys can think of?


    It's hard to suggest a solution without knowing your requirements. You
    state that some things aren't a viable solution but don't explain why.

    It is, in some cases, possible for a third party to set up a
    connection between two hosts and then "get out of the way". It's not
    always possible. There are tricks for both TCP and UDP to get this to
    happen. Google for 'STUN'. Or read RFC3489.

    DS


  3. Re: Connect two TCP connections?

    On Jun 15, 8:25 pm, David Schwartz wrote:
    > On Jun 15, 12:48 pm, b...@stolenradio.com wrote:
    >
    > > I have an interesting problem... I need two clients to connect to each
    > > other via TCP. Both are behind firewalls/routers/etc, and port
    > > forwarding is not a viable solution. Normally, I would just have them
    > > both connect to a third party, and the third party would just relay
    > > data between the two clients. However, this also is not a viable
    > > solution.

    >
    > Why?
    >
    > > How, then, do I get the two clients to connect?

    >
    > > One thing I was thinking about is to have both clients connect to the
    > > third party, and then have the third party somehow connect the two
    > > connections... Is this at all possible? Are there any other things you
    > > guys can think of?

    >
    > It's hard to suggest a solution without knowing your requirements. You
    > state that some things aren't a viable solution but don't explain why.
    >
    > It is, in some cases, possible for a third party to set up a
    > connection between two hosts and then "get out of the way". It's not
    > always possible. There are tricks for both TCP and UDP to get this to
    > happen. Google for 'STUN'. Or read RFC3489.
    >
    > DS



    David,

    Believe me, I would love to divulge to you the exact specifications
    of what I'm trying to do (as I feel I'm a little over my head here),
    however I am contractually obliged not to divulge certain aspects.
    However, I will try to be as descriptive as possible:

    (Oh, and I looked up STUN-- this seems to be a technique for UDP. I
    would much rather use UDP, however this is also not possible. My
    solution MUST be TCP as defined by a set of constraints I have on this
    project.)

    There are two clients, A and B, behind routers/firewalls/what have
    you. They wish to make a TCP connection to each other. This (as far as
    I understand) is not possible, as neither A nor B can connect to the
    other, without port forwarding on the recipient's gateway. Port
    forwarding is not an acceptable solution to this problem, as defined
    by my engineering constraints.

    Normally, one would set up a server (S) somewhere "out in the
    open" (ie, using proper port forwaring, etc). A would connect to S, B
    would connect to S, and S would manage the communication between A and
    B, by simply inspecting packets received, and forwarding them to the
    proper recipient.

    Due to my constraints, transmissions from A to B can NOT travel
    through S, however it is acceptable for return transmissions (from B
    to A) to be forwarded through S.

    So I would love a technique (though I'm not sure such a technique
    exists) in which A and B both connect to S, and then S "gets out of
    the way" such that no further transmissions will be routed through S.
    In this case, S would only act as a facilitator for the connection
    between A and B; essentially the same as if I make introductions
    between two unrelated friends of mine, and then leave the room and
    hear none of the conversation.

    As I'm not sure that the above technique is possible, a further
    acceptable solution would be a scenario in which A and B both connect
    to S, and due to the fact that S now "knows how to talk" to B, can now
    "teach" A how to talk to B directly. Responses made by B to A can be
    sent to S, and S can forward them to A.

    Essentially, the situation is: two clients behind firewalls must make
    a TCP (not UDP) connection, either directly or indirectly, to one
    another, such that all packets sent from A to B (but not necessarily
    vice versa) are sent directly and not through any sort of middleman.

    I apologize for the fact that I can not be more explicit with you, as
    I understand the frustration in trying to help someone who's being as
    vague as I am, but I do hope that I explained things in a clear enough
    manner. Please don't be shy to ask if there's still some aspect of my
    project which has not been stated clearly enough.

    And thanks very much for your help,

    Burak



  4. Re: Connect two TCP connections?

    burak@stolenradio.com writes:

    > There are two clients, A and B, behind routers/firewalls/what have
    > you. They wish to make a TCP connection to each other.


    I can't believe I'm suggesting this, but here's an off the wall idea
    that could work if you can mess with the TCP implementation:

    TCP has always had a fascinating, "secret" characteristic that two
    *active* connections, neither listening, can logically connect to each
    other, which is conceptually, at least, just what you want. There are
    only two problems. First, both sides of the connection have to know up
    front what IP address and TCP port the other side will be using.
    Second, both sides have to try to start the connection at the same
    time: it only works if the two SYN packets cross in flight.

    (Here's where hacking the TCP implementation might come into play: the
    only reason they have to cross is because if one arrives before the
    other connection has started, the early one will receive a RST reply
    since there's no socket there to receive it yet. You could eliminate
    the need for precise synchronization by teaching the TCP layer to
    ignore those RSTs so that it just retransmits the SYN.)

    Well, there's a third problem: many early TCP implementations couldn't
    handle this. 4.2BSD, for example, hung the system when this event was
    encountered, if I recall correctly. Hopefully you won't run into them,
    but there's an easy way to check: open a TCP connection to itself:
    bind local and remote ports and addresses the same, then connect. If
    it works and you can pass packets, you don't have a problem. (You've
    also created one of the oddest structures in networking, in my
    opinion: it's kinda the Kline Bottle of TCP connections.)

    I've been slinging TCP for 25 years now, and I've never seen anyone
    use such a TCP connection for anything useful (well, unless you
    consider hanging 4.2BSD "useful": *I* certainly did :-). I've always
    held out hope that someday someone would. Perhaps you'll make history!

    Oh, and there's also a fourth problem that just occurred to me: this
    probably won't work if there's filtering preventing a SYN only packet
    from entering into the NAT environment, a somewhat common defense
    against attacks. Although the socket will be established at the NAT
    edge by the outgoing SYN, that may not be enough to get the system to
    accept an incoming SYN that doesn't ACK the outgoing SYN.

    -don provan

  5. Re: Connect two TCP connections?

    On Sat, 16 Jun 2007 03:40:29 -0000, burak@stolenradio.com wrote:
    ....
    > Believe me, I would love to divulge to you the exact specifications
    > of what I'm trying to do (as I feel I'm a little over my head here),
    > however I am contractually obliged not to divulge certain aspects.

    ....

    > Essentially, the situation is: two clients behind firewalls must make
    > a TCP (not UDP) connection, either directly or indirectly, to one
    > another, such that all packets sent from A to B (but not necessarily
    > vice versa) are sent directly and not through any sort of middleman.


    Please remember, too, that sometimes you are obliged to say to the
    customer:

    "This cannot be done under these conditions. Here is why: [brief
    explanation]. I could possibly hack something together, but that
    would be a major risk. It wouldn't be good, could break at any time,
    and it would look as odd as a two-legged dog to anyone triyng to
    debug or administer it."

    It is not clear to me that there is no other way out, but this /is/
    one way out.

    /Jorgen

    --
    // Jorgen Grahn \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!

  6. Re: Connect two TCP connections?

    On Jun 15, 8:40 pm, b...@stolenradio.com wrote:

    > Essentially, the situation is: two clients behind firewalls must make
    > a TCP (not UDP) connection, either directly or indirectly, to one
    > another, such that all packets sent from A to B (but not necessarily
    > vice versa) are sent directly and not through any sort of middleman.


    Google for "TCP splicing", however it's my understanding that it
    doesn't really work in the real world. As I understand your
    requirements, they are impossible to meet.

    Why is UDP not an option?

    DS


  7. Re: Connect two TCP connections?

    wrote in message
    news:1181965229.544203.204680@w5g2000hsg.googlegro ups.com...
    > On Jun 15, 8:25 pm, David Schwartz wrote:
    > > On Jun 15, 12:48 pm, b...@stolenradio.com wrote:
    > >
    > > > I have an interesting problem... I need two clients to connect to each
    > > > other via TCP. Both are behind firewalls/routers/etc, and port
    > > > forwarding is not a viable solution. Normally, I would just have them
    > > > both connect to a third party, and the third party would just relay
    > > > data between the two clients. However, this also is not a viable
    > > > solution.

    > >


    --snip--
    >
    > There are two clients, A and B, behind routers/firewalls/what have
    > you. They wish to make a TCP connection to each other. This (as far as
    > I understand) is not possible, as neither A nor B can connect to the
    > other, without port forwarding on the recipient's gateway. Port
    > forwarding is not an acceptable solution to this problem, as defined
    > by my engineering constraints.
    >
    > Normally, one would set up a server (S) somewhere "out in the
    > open" (ie, using proper port forwaring, etc). A would connect to S, B
    > would connect to S, and S would manage the communication between A and
    > B, by simply inspecting packets received, and forwarding them to the
    > proper recipient.
    >
    > Due to my constraints, transmissions from A to B can NOT travel
    > through S, however it is acceptable for return transmissions (from B
    > to A) to be forwarded through S.
    >
    > So I would love a technique (though I'm not sure such a technique
    > exists) in which A and B both connect to S, and then S "gets out of
    > the way" such that no further transmissions will be routed through S.
    > In this case, S would only act as a facilitator for the connection
    > between A and B; essentially the same as if I make introductions
    > between two unrelated friends of mine, and then leave the room and
    > hear none of the conversation.
    >
    > As I'm not sure that the above technique is possible, a further
    > acceptable solution would be a scenario in which A and B both connect
    > to S, and due to the fact that S now "knows how to talk" to B, can now
    > "teach" A how to talk to B directly. Responses made by B to A can be
    > sent to S, and S can forward them to A.
    >
    > Essentially, the situation is: two clients behind firewalls must make
    > a TCP (not UDP) connection, either directly or indirectly, to one
    > another, such that all packets sent from A to B (but not necessarily
    > vice versa) are sent directly and not through any sort of middleman.
    >

    this sounds like a contradiction.

    it also sounds like a spec from someone who doesnt know how networks
    actually work - for example, all those routers on the path which are
    basically special purpose computers, are just a cut down version of "S"

    it does sound like there are 2 sets of people involved who will not trust
    each other - and if you cannot fix that, then it is time to scrap the whole
    "communications" idea.

    3 suggestions:

    1. cannot get there from here on the Internet with what you want to do and
    the set of restriction.

    So, if the restrictions are due to the underlying network being public /
    insecure, go rent a leased line between the 2 sites, and allow the
    connections directly.

    if that isnt acceptible then i suggest sending letters by snail mail and
    some good scanners - latency of 2+ days may be an issue......

    2. ask whether the issue is traffic thru "S", or just accessible application
    data.
    if so, encryption of the TCP data on the link should resolve the problem.

    3. get a proxy set up for this in a DMZ at 1 site or the other.

    >
    > And thanks very much for your help,
    >
    > Burak

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  8. Re: Connect two TCP connections?


    wrote in message
    news:1181936887.562566.33840@m36g2000hse.googlegro ups.com...
    >I have an interesting problem... I need two clients to connect to each
    > other via TCP. Both are behind firewalls/routers/etc, and port
    > forwarding is not a viable solution. Normally, I would just have them
    > both connect to a third party, and the third party would just relay
    > data between the two clients. However, this also is not a viable
    > solution.
    >
    > How, then, do I get the two clients to connect?
    >
    > One thing I was thinking about is to have both clients connect to the
    > third party, and then have the third party somehow connect the two
    > connections... Is this at all possible? Are there any other things you
    > guys can think of?
    >
    > Your help is greatly appreciated.


    If they know each other's ip address try opening many ports on each side,
    and then try to also connect to as many ports on the other side.

    Repeat this for the whole port range from say 1024 to 65535 or so.

    Not sure if it would work for tcp... for udp it would probably work if done
    long enough.

    Bye,
    Skybuck.



+ Reply to Thread