incoming connection port 80

[Erik]

I'm wondering how to accept connections (socket) if you are behind a
router. Skype and
uTorrent can handle this (by using port 80 or 443). How do these
programs manage to accept
connections if ports (accept port 80 and 443) are blocked?

Thanks

Erik

 

[Mark Space]

I'm wondering how to accept connections (socket) if you are behind a
router. Skype and
uTorrent can handle this (by using port 80 or 443). How do these
programs manage to accept
connections if ports (accept port 80 and 443) are blocked?

Thanks

Erik

uTorrent is just a Bit Torrent client.

Bit Torrent connects out to a server, it does not accept incoming
connections. Its incoming connections are not low number ports (80 or
443) and have to be specifically enabled on the router/firewall or it
won't work well.

I didn't look up Skype, I assume it is similar. It connects out to a
server. It probably maintains an open connect so a server can reply
back when a call comes in.

 

[Erik]

uTorrent is just a Bit Torrent client.

Bit Torrent connects out to a server, it does not accept incoming
connections. Its incoming connections are not low number ports (80 or
443) and have to be specifically enabled on the router/firewall or it
won't work well.

I didn't look up Skype, I assume it is similar. It connects out to a
server. It probably maintains an open connect so a server can reply
back when a call comes in.

I don't know if I completely understand you, but Skype indeed has an
connection
with a central server, but when someone tries to call you, he must be
able to
connect to you. In the Skype option menu you can specify a specific
port for the incoming
connection, but you can also specify to use port 80 or port 443 as
alternative. What
method is behind this?

Erik

 

[Peter Duniho]

uTorrent is just a Bit Torrent client.

Bit Torrent connects out to a server, it does not accept incoming
connections. Its incoming connections are not low number ports (80 or
443) and have to be specifically enabled on the router/firewall or it
won't work well.

If it doesn't accept incoming connections, then why do its incoming
connections "have to be specifically enabled"?

To the original poster: an application that has a listening TCP socket
does indeed require that the router _somehow_ be configured to forward
connection requests to that socket. The two most common techniques
involve manually configuring the router or using the "universal
plug-and-play" protocol (by which a network application can obtain
specific information from the router and/or configure the router to do
specific forwarding).

Many routers support "port triggering", by which the router watches
outbound traffic and if it notes a network client using some particular
port (either locally or, more commonly, in the remote address), it
automatically enables forwarding to that client temporarily on some other
specified port or ports (which may include the original outbound port).
Specifics on this vary from router to router.

You may also want to Google "nat hole punching". It's more reliable when
used with UDP than TCP (different techniques are used with each, and doing
it using TCP requires lower-level access than sockets normally give you),
and in either case it's not 100% reliable as it depends on undocumented,
arbitrary behavior on the part of the router. But depending on how
important it is to solve the problem, it's something you might consider.

Note that if the router has literally "blocked" the ports, then the answer
is "you don't". Typically, the ports are only "blocked" in that the
router doesn't know who to forward the traffic to. This is addressable as
described above. But if someone's actually configured the router to not
allow traffic on those ports to pass, then the only thing that will allow
traffic on those ports through is to reconfigure the router so that it's
no longer blocking traffic on those ports.

Finally note that a "router" is not the same as a "firewall". Sometimes
the two functions are combined into a single device, but a firewall's job
is specifically to block traffic. Either it's blocking traffic on
specific ports or it's not. If it's not, you have nothing to do, and if
it is, nothing you can do short of changing the firewall configuration is
going to unblock the ports. Obviously, changing the firewall
configuration is not something that would be done automatically by a
software client without any user intervention. Otherwise it wouldn't be
much of a firewall.

Pete

 

[Erik]

If it doesn't accept incoming connections, then why do its incoming
connections "have to be specifically enabled"?

To the original poster: an application that has a listening TCP socket
does indeed require that the router _somehow_ be configured to forward
connection requests to that socket. The two most common techniques
involve manually configuring the router or using the "universal
plug-and-play" protocol (by which a network application can obtain
specific information from the router and/or configure the router to do
specific forwarding).

Many routers support "port triggering", by which the router watches
outbound traffic and if it notes a network client using some particular
port (either locally or, more commonly, in the remote address), it
automatically enables forwarding to that client temporarily on some other
specified port or ports (which may include the original outbound port).
Specifics on this vary from router to router.

You may also want to Google "nat hole punching". It's more reliable when
used with UDP than TCP (different techniques are used with each, and doing
it using TCP requires lower-level access than sockets normally give you),
and in either case it's not 100% reliable as it depends on undocumented,
arbitrary behavior on the part of the router. But depending on how
important it is to solve the problem, it's something you might consider.

Note that if the router has literally "blocked" the ports, then the answer
is "you don't". Typically, the ports are only "blocked" in that the
router doesn't know who to forward the traffic to. This is addressable as
described above. But if someone's actually configured the router to not
allow traffic on those ports to pass, then the only thing that will allow
traffic on those ports through is to reconfigure the router so that it's
no longer blocking traffic on those ports.

Finally note that a "router" is not the same as a "firewall". Sometimes
the two functions are combined into a single device, but a firewall's job
is specifically to block traffic. Either it's blocking traffic on
specific ports or it's not. If it's not, you have nothing to do, and if
it is, nothing you can do short of changing the firewall configuration is
going to unblock the ports. Obviously, changing the firewall
configuration is not something that would be done automatically by a
software client without any user intervention. Otherwise it wouldn't be
much of a firewall.

Pete

Thanks for your answer .

What I'm trying to do is to create a Java applet which can receive an
incoming
connection, so a connection is enstablished between a program and the
applet (which
must be able to accept the connection). Is this possible (to bypass
the router (not the firewall!)) and if it's possible, how?

Thanks

Erik

 

[Mark Space]

If it doesn't accept incoming connections, then why do its incoming
connections "have to be specifically enabled"?

BitTorrent first connects out to a central server, and starts the
download. After this, it has some parts of the file and it will start
accepting requests for parts of the file, but it has to be downloading
first. It doesn't accept connections if it isn't connected to a server yet.

This two step process is, frankly, stupid in my opinion.

 

[Peter Duniho]

Thanks for your answer .

You're welcome.

What I'm trying to do is to create a Java applet which can receive an
incoming
connection, so a connection is enstablished between a program and the
applet (which
must be able to accept the connection).

Assuming that your use of the word "connection" here implies TCP, and
assuming that an applet is allowed to create a TCP socket that listens,
then this should be possible. Note that I don't know enough about the
limitations of an applet to answer that particular question. If Java
blocks that sort of operation for applets, then you can't do it.

Is this possible (to bypass
the router (not the firewall!)) and if it's possible, how?

Assuming applets are allowed to do that sort of thing, it's possible, and
my previous post explained how, at least to the extent that I think might
be appropriate in a Java programming newsgroup. There's plenty of
information in there that should allow you to find the specific details
via Google and/or in a newsgroup that more specifically deals with network
programming.

Pete

 

[Christian]

Thanks for your answer .

What I'm trying to do is to create a Java applet which can receive an
incoming
connection, so a connection is enstablished between a program and the
applet (which
must be able to accept the connection). Is this possible (to bypass
the router (not the firewall!)) and if it's possible, how?

Thanks

Erik

A standard way would be to use UPnP protocol to open up a port.

Everything else is more sophisticated.. like tricking the router into
believing a connection was created .. probably not what you want (hole
punching like told above)

As a sidenode port 80 and alike are often used to trick admins/isps that
don't work with level-7 filters but just block unwanted traffic by port.

 

[Peter Duniho]

BitTorrent first connects out to a central server, and starts the
download. After this, it has some parts of the file and it will start
accepting requests for parts of the file, but it has to be downloading
first.

That's not true. You can seed a file that you've already downloaded,
without downloading anything more.

It doesn't accept connections if it isn't connected to a server yet.

Well, downloaders need a way to find you. If you don't contact the
central server, how will they know you're seeding? So yes, the client
does need to make an outbound connection to some server before it can
receiving inbound connection requestions.

In any case, I think you missed the joke, which had nothing to do with any
of the above.

Pete

 

[Erik]

That's not true.  You can seed a file that you've already downloaded,  
without downloading anything more.


Well, downloaders need a way to find you.  If you don't contact the  
central server, how will they know you're seeding?  So yes, the client  
does need to make an outbound connection to some server before it can  
receiving inbound connection requestions.

In any case, I think you missed the joke, which had nothing to do with any  
of the above.

Pete

But is it posible to create an applet which can accept an incoming
connection if it's behind a router? And if it's posible, how is
this done?
Also I still don't realy get how Skype does this. When I'm running
Skype
(and I'm behind a router) I have the "use port 80 and 443 as
alternatives
for incoming connections" enabled and Skype can receive incoming
connections (calls).
How does Skype do this?

Erik

 

[Peter Duniho]

But is it posible to create an applet which can accept an incoming
connection if it's behind a router?

If it's possible to create an applet that can accept an incoming
connection generally, then it's possible to do when it's behind a router.

And if it's posible, how is this done?

I already wrote a post telling you how. I also already wrote a post
telling you that I already wrote a post telling you how. Now I am writing
a post telling you that I already wrote a post telling you that I already
wrote a post telling you how.

I think this is getting a little out of hand.

Pete