Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
connect directly to another computer bypassing firewalls using a third server
8 views
Skip to first unread message
alberto fuentes
Apr 18, 2013, 5:20:02 PM4/18/13
to
Its a long shot because i can really picture how could it work
I know I can connect using the third server, but I just want to use the server to establish the connection
Bob Proulx
Apr 18, 2013, 5:30:02 PM4/18/13
to
alberto fuentes wrote:
> Subject: connect directly to another computer bypassing firewalls
> using a third server
you are asking to do.
Are you asking for something like this?
Host lilypadmachine.example.com
ProxyCommand none
Host *.example.com
ProxyCommand ssh -W %h:%p lilypadmachine.example.com
Bob
> Subject: connect directly to another computer bypassing firewalls
> using a third server
> Its a long shot because i can really picture how could it work
>
> I know I can connect using the third server, but I just want to use the
> server to establish the connection
The crystal ball isn't working well today. Please say more about what
>
> I know I can connect using the third server, but I just want to use the
> server to establish the connection
you are asking to do.
Are you asking for something like this?
Host lilypadmachine.example.com
ProxyCommand none
Host *.example.com
ProxyCommand ssh -W %h:%p lilypadmachine.example.com
Bob
alberto fuentes
Apr 18, 2013, 5:50:01 PM4/18/13
to
That way all the packages would be forwarded via the server.
The server is overseas. Im trying to connect to a computer in my city. Packages have to travel and comeback. I was hoping some kind of magic that would allow me to use the server overseas *just* to establish the connection between the two computers :)
Bob Proulx
Apr 18, 2013, 6:10:01 PM4/18/13
to
alberto fuentes wrote:
> That way all the packages would be forwarded via the server.
>
> The server is overseas. Im trying to connect to a computer in my city.
> Packages have to travel and comeback. I was hoping some kind of magic that
> would allow me to use the server overseas *just* to establish the
> connection between the two computers :)
First you must tell us what server. Apache? OpenSSH? OpenVPN?
> That way all the packages would be forwarded via the server.
>
> The server is overseas. Im trying to connect to a computer in my city.
> Packages have to travel and comeback. I was hoping some kind of magic that
> would allow me to use the server overseas *just* to establish the
> connection between the two computers :)
MySQL? There are zillions of servers.
Please. Just tell us what you are asking. I cannot guess.
You first mentioned connecting to a server so I guessed ssh. That was
apparently not what you were asking about. Now you mention packages.
I could guess that you want to set up an apt proxy of some sort. Is
that what you are asking about? A way to set up an apt proxy? If you
don't say then I give up.
Bob
Pascal Hambourg
Apr 19, 2013, 7:50:02 AM4/19/13
to
Hello,
Bob Proulx a ï¿œcrit :
have the same word for "packet" and "package". However I cannot figure
out clearly what he is asking for either.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5171297C...@plouf.fr.eu.org
Bob Proulx a ï¿œcrit :
>
> You first mentioned connecting to a server so I guessed ssh. That was
> apparently not what you were asking about. Now you mention packages.
> I could guess that you want to set up an apt proxy of some sort. Is
> that what you are asking about? A way to set up an apt proxy? If you
> don't say then I give up.
I guess the OP means "packets" instead of "packages". Some languages
> You first mentioned connecting to a server so I guessed ssh. That was
> apparently not what you were asking about. Now you mention packages.
> I could guess that you want to set up an apt proxy of some sort. Is
> that what you are asking about? A way to set up an apt proxy? If you
> don't say then I give up.
have the same word for "packet" and "package". However I cannot figure
out clearly what he is asking for either.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5171297C...@plouf.fr.eu.org
alberto fuentes
Apr 19, 2013, 11:10:02 AM4/19/13
to
On Fri, Apr 19, 2013 at 1:24 PM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
I guess the OP means "packets" instead of "packages". Some languages
have the same word for "packet" and "package". However I cannot figure
out clearly what he is asking for either.
Yes. I never noticed packages and packets are the same word in my language.
Sorry to express myself so badly. Its evident my question was confusing
I want to avoid the packets travel overseas to connect via vpn to another computer in my own city. I mean ssh, yes.
I can connect to the computer in my city opening ports in the firewall for every specific case. And I usually do so. But i was looking for a generic way to use in a third party (openvpn server overaseas) to just handle the establishment of the connection somehow avoiding all firewalls. Some way for B to know I want to establish ssh conection with him and once the connection and dont make all the packets of the session go to the server, just the initial handshake (generic use of word handshake, not necesarily tpc/ip handshake)
I can connect to the computer in my city opening ports in the firewall for every specific case. And I usually do so. But i was looking for a generic way to use in a third party (openvpn server overaseas) to just handle the establishment of the connection somehow avoiding all firewalls. Some way for B to know I want to establish ssh conection with him and once the connection and dont make all the packets of the session go to the server, just the initial handshake (generic use of word handshake, not necesarily tpc/ip handshake)
A (me) -> Server (overseas) -> B (arbitrary computer in my city)
This seems rather hard and I cant even picture how would it work. Ill take a look at the nat-traverse package and report back :)
alberto fuentes
Apr 19, 2013, 11:10:05 AM4/19/13
to
On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes <paj...@gmail.com> wrote:
A (me) -> Server (overseas) -> B (arbitrary computer in my city)
To make it a little more clear. Both computer A and B know about Server. Right now I use openvpn to bring all the computers together into the same network. But it seems too much overhead being both computers on the same city. Even if the server where in the same city as well, it adds another extra jump that i would like to avoid.
Thank you
Lars Nooden
Apr 19, 2013, 11:40:01 AM4/19/13
to
On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes <paj...@gmail.com> wrote:
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
To make a direct connection between A and B with ssh, you need to have at
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
least on of them be publicly available even if the other is blocked behind
a firewall. Depending on the direction you are connecting in that case
you may need to use a reverse tunnel.
Regards,
/Lars
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Apr 19, 2013, 12:40:02 PM4/19/13
to
alberto fuentes wrote:
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
>
> To make it a little more clear. Both computer A and B know about Server.
> Right now I use openvpn to bring all the computers together into the same
> network. But it seems too much overhead being both computers on the same
> city. Even if the server where in the same city as well, it adds another
> extra jump that i would like to avoid.
Then using ssh -W as I originally suggested is easy and will do it.
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
>
> To make it a little more clear. Both computer A and B know about Server.
> Right now I use openvpn to bring all the computers together into the same
> network. But it seems too much overhead being both computers on the same
> city. Even if the server where in the same city as well, it adds another
> extra jump that i would like to avoid.
On A (you):
ssh -o ProxyCommand="ssh -W %h:%p server" B
Look in my previous message for how to put this in your ssh config file.
Bob
Bob Proulx
Apr 19, 2013, 1:00:02 PM4/19/13
to
green wrote:
> Lars Nooden wrote:
> a direct connection to be made between 2 systems which are *both*
> behind NAT/masquerading gateways. In this case, the third publicly
> accessible server would not be necessary, and traffic would not be
> required to leave the local area.
>
> http://m19s28.dyndns.org/iblech/nat-traverse/
Since alberto said that both A and B know about Server then NAT
traversal shouldn't be needed.
> > Both computer A and B know about Server.
If both A and B can get to Server then it is very easy to just hop
through Server to get to the other.
Bob
> Lars Nooden wrote:
> > alberto fuentes wrote:
> > > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> >
> > To make a direct connection between A and B with ssh, you need to have at
> > least on of them be publicly available even if the other is blocked behind
> > a firewall.
>
> nat-traverse is something new (to me at least) that supposedly allows
> > > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
> >
> > To make a direct connection between A and B with ssh, you need to have at
> > least on of them be publicly available even if the other is blocked behind
> > a firewall.
>
> a direct connection to be made between 2 systems which are *both*
> behind NAT/masquerading gateways. In this case, the third publicly
> accessible server would not be necessary, and traffic would not be
> required to leave the local area.
>
> http://m19s28.dyndns.org/iblech/nat-traverse/
Since alberto said that both A and B know about Server then NAT
traversal shouldn't be needed.
> > Both computer A and B know about Server.
through Server to get to the other.
Bob
green
Apr 19, 2013, 1:00:01 PM4/19/13
to
Lars Nooden wrote at 2013-04-19 10:35 -0500:
> On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes <paj...@gmail.com> wrote:
> > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
>
> To make a direct connection between A and B with ssh, you need to have at
> least on of them be publicly available even if the other is blocked behind
> a firewall.
> On Fri, Apr 19, 2013 at 5:00 PM, alberto fuentes <paj...@gmail.com> wrote:
> > A (me) -> Server (overseas) -> B (arbitrary computer in my city)
>
> To make a direct connection between A and B with ssh, you need to have at
> least on of them be publicly available even if the other is blocked behind
> a firewall.
Lars Nooden
Apr 19, 2013, 2:40:02 PM4/19/13
to
nat-traverse on each. But it looks interesting.
alberto fuentes
Apr 19, 2013, 4:20:01 PM4/19/13
to
On Fri, Apr 19, 2013 at 6:32 PM, Bob Proulx <b...@proulx.com> wrote:
alberto fuentes wrote:Then using ssh -W as I originally suggested is easy and will do it.
> A (me) -> Server (overseas) -> B (arbitrary computer in my city)
>
> To make it a little more clear. Both computer A and B know about Server.
> Right now I use openvpn to bring all the computers together into the same
> network. But it seems too much overhead being both computers on the same
> city. Even if the server where in the same city as well, it adds another
> extra jump that i would like to avoid.
Thank you for your answer
-W will not do because all the traffic has to go through the server even if its transparent from the point of view of the client A. Also it will hit the firewall when trying to reach B from the server.
Right now A and B connect to vpn in server and so I can connect from A to B via vpn, But i wanted to avoid having to send packets that far since I plan to be using the connection heavily.
-W will not do because all the traffic has to go through the server even if its transparent from the point of view of the client A. Also it will hit the firewall when trying to reach B from the server.
Right now A and B connect to vpn in server and so I can connect from A to B via vpn, But i wanted to avoid having to send packets that far since I plan to be using the connection heavily.
alberto fuentes
Apr 19, 2013, 4:40:01 PM4/19/13
to
On Fri, Apr 19, 2013 at 6:56 PM, Bob Proulx <b...@proulx.com> wrote:
Since alberto said that both A and B know about Server then NAT
traversal shouldn't be needed.
Actually I want to connect from A to B directly, so nat traversal seems nice, but I cant try it right now... when I have the machine back up I will try it and report back ;)
If both A and B can get to Server then it is very easy to just hop
> > Both computer A and B know about Server.
through Server to get to the other.
The server is just a convenience since both machines are behind firewalls, but I would like to avoid having to use it, because packets have to travel long distance. Also Im planning to make heavy use of it and I have to pay for bandwidth on server ;)
Actually I got the idea from filetea [0] that allows to send files from A to B using a third server to make the connection. Actually I dont know how it works and if the traffic is sent through the server. Now that I think about it, I guess it does and I thought it was only used to establish the connection
if nat-travesal works, it seems the only way so far to do it. I only need the vpn to start it on both ends. I will see how to automate this :)
alberto fuentes
Apr 19, 2013, 4:50:02 PM4/19/13
to
On Fri, Apr 19, 2013 at 10:29 PM, alberto fuentes <paj...@gmail.com> wrote:
Actually I got the idea from filetea [0]
I just checked it out. Its less magical than I thought. It *does* use the server to route all packets :(
Kevin Chadwick
Apr 19, 2013, 5:10:02 PM4/19/13
to
> That looks like you have to somehow be logged into both hosts and run
> nat-traverse on each. But it looks interesting.
Firewalls can track and block UDP (create state) even if it is a
> nat-traverse on each. But it looks interesting.
stateless protocol too, so you may have to have control of the gateways
too.
--
_______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
_______________________________________________________________________
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rick Thomas
Apr 22, 2013, 3:00:02 AM4/22/13
to
Alberto,
What you want to do is possible. In particular, skype and bittorrent do it.
As I understand it, they make use of a server with a public IP address. I'm not going to get it exactly right, but the general idea is this:
Two clients, A and B, both behind NAT firewalls. Server, S, with a public IP, i.e. *not* behind NAT.
A calls S and says I want to talk to B. (This is possible because the call is originated inside A's NAT)
At approximately the same time, B calls S and says I'm willing to talk to A. (Possible because call is originated inside B's NAT)
Server tells each of A and B (over the connections each of them have open with S) in exactly 1 second (or whenever) from receiving this packet, try to open a connection to your opposite number on port 40000 (or whatever).
With luck, each NAT will receive and act upon the outgoing request to setup the connection *before* it receives the incoming request. So by the time the incoming request is received, the channel will be open and ready to receive.
If it doesn't work the first time, try again with slightly different timing.
Keep trying until it does work -- or you get tired and quit.
The result is a direct connection between A and B, which *both* NATs see as having been started from inside.
The server, S, is only involved for a brief time at the beginning.
Other than skype and bittorrent, I'm not aware of any packages that do this. Neither of them are directly useful for your purposes.
It's possible that nat-traverse is a general purpose implementation of this trick, but I haven't read the documentation, so I can't say for sure.
Enjoy!
Rick
What you want to do is possible. In particular, skype and bittorrent do it.
As I understand it, they make use of a server with a public IP address. I'm not going to get it exactly right, but the general idea is this:
Two clients, A and B, both behind NAT firewalls. Server, S, with a public IP, i.e. *not* behind NAT.
A calls S and says I want to talk to B. (This is possible because the call is originated inside A's NAT)
At approximately the same time, B calls S and says I'm willing to talk to A. (Possible because call is originated inside B's NAT)
Server tells each of A and B (over the connections each of them have open with S) in exactly 1 second (or whenever) from receiving this packet, try to open a connection to your opposite number on port 40000 (or whatever).
With luck, each NAT will receive and act upon the outgoing request to setup the connection *before* it receives the incoming request. So by the time the incoming request is received, the channel will be open and ready to receive.
If it doesn't work the first time, try again with slightly different timing.
Keep trying until it does work -- or you get tired and quit.
The result is a direct connection between A and B, which *both* NATs see as having been started from inside.
The server, S, is only involved for a brief time at the beginning.
Other than skype and bittorrent, I'm not aware of any packages that do this. Neither of them are directly useful for your purposes.
It's possible that nat-traverse is a general purpose implementation of this trick, but I haven't read the documentation, so I can't say for sure.
Enjoy!
Rick
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/F24DF815-CD06-4AD8...@pobox.com
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Celejar
Apr 22, 2013, 8:00:02 AM4/22/13
to
On Sun, 21 Apr 2013 23:59:00 -0700
Rick Thomas <rbth...@pobox.com> wrote:
> Alberto,
>
> What you want to do is possible. In particular, skype and bittorrent do it.
>
> As I understand it, they make use of a server with a public IP address. I'm not going to get it exactly right, but the general idea is this:
>
> Two clients, A and B, both behind NAT firewalls. Server, S, with a public IP, i.e. *not* behind NAT.
>
> A calls S and says I want to talk to B. (This is possible because the call is originated inside A's NAT)
> At approximately the same time, B calls S and says I'm willing to talk to A. (Possible because call is originated inside B's NAT)
>
> Server tells each of A and B (over the connections each of them have open with S) in exactly 1 second (or whenever) from receiving this packet, try to open a connection to your opposite number on port 40000 (or whatever).
>
> With luck, each NAT will receive and act upon the outgoing request to setup the connection *before* it receives the incoming request. So by the time the incoming request is received, the channel will be open and ready to receive.
>
> If it doesn't work the first time, try again with slightly different timing.
>
> Keep trying until it does work -- or you get tired and quit.
>
> The result is a direct connection between A and B, which *both* NATs see as having been started from inside.
>
> The server, S, is only involved for a brief time at the beginning.
>
> Other than skype and bittorrent, I'm not aware of any packages that do this. Neither of them are directly useful for your purposes.
>
> It's possible that nat-traverse is a general purpose implementation of this trick, but I haven't read the documentation, so I can't say for sure.
Yes: http://m19s28.dyndns.org/iblech/nat-traverse/#technique
Rick Thomas <rbth...@pobox.com> wrote:
> Alberto,
>
> What you want to do is possible. In particular, skype and bittorrent do it.
>
> As I understand it, they make use of a server with a public IP address. I'm not going to get it exactly right, but the general idea is this:
>
> Two clients, A and B, both behind NAT firewalls. Server, S, with a public IP, i.e. *not* behind NAT.
>
> A calls S and says I want to talk to B. (This is possible because the call is originated inside A's NAT)
> At approximately the same time, B calls S and says I'm willing to talk to A. (Possible because call is originated inside B's NAT)
>
> Server tells each of A and B (over the connections each of them have open with S) in exactly 1 second (or whenever) from receiving this packet, try to open a connection to your opposite number on port 40000 (or whatever).
>
> With luck, each NAT will receive and act upon the outgoing request to setup the connection *before* it receives the incoming request. So by the time the incoming request is received, the channel will be open and ready to receive.
>
> If it doesn't work the first time, try again with slightly different timing.
>
> Keep trying until it does work -- or you get tired and quit.
>
> The result is a direct connection between A and B, which *both* NATs see as having been started from inside.
>
> The server, S, is only involved for a brief time at the beginning.
>
> Other than skype and bittorrent, I'm not aware of any packages that do this. Neither of them are directly useful for your purposes.
>
> It's possible that nat-traverse is a general purpose implementation of this trick, but I haven't read the documentation, so I can't say for sure.
General discussion:
http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
Celejar
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rick Thomas
Apr 22, 2013, 2:50:02 PM4/22/13
to
On Apr 22, 2013, at 4:55 AM, Celejar wrote:
> Yes: http://m19s28.dyndns.org/iblech/nat-traverse/#technique
>
> General discussion:
> http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
>
>
> Celejar
Rick
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages