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

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

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

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!

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

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

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.