"Redirecting" an incoming socket connection?

[Adam Clauss]

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[Justin Rogers]

You can act as a transparent proxy, establish the connection to your
local application on behalf of the remote, and forward all messages
between the two.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[Adam Clauss]

That would essentially be my second proposal then correct?
So you think my first proposal (which would, to the server application, make
the socket appear as it came straight from the client rather than a proxy)
is not doable?

Adam Clauss
ca*****@tamu.edu

"Justin Rogers" <Ju****@games4dotnet.com> wrote in message
news:uC*************@tk2msftngp13.phx.gbl...

You can act as a transparent proxy, establish the connection to your
local application on behalf of the remote, and forward all messages
between the two.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[Justin Rogers]

There isn't anyway to redirect the connection that I know of. Connections are
based on end-points. In your environment it takes at least 4 end-points to
define
a path through your network to the application you are targeting. That to me
sounds a heck of a lot like a proxy. (with 2 of those being the start and finish
addresses, and 2 being your proxy in the middle)

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:Of*************@TK2MSFTNGP10.phx.gbl...

That would essentially be my second proposal then correct?
So you think my first proposal (which would, to the server application, make
the socket appear as it came straight from the client rather than a proxy)
is not doable?

Adam Clauss
ca*****@tamu.edu

"Justin Rogers" <Ju****@games4dotnet.com> wrote in message
news:uC*************@tk2msftngp13.phx.gbl...

You can act as a transparent proxy, establish the connection to your
local application on behalf of the remote, and forward all messages
between the two.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[William Stacey [MVP]]

Sound like maybe fpipe type of application is what you need (and you don't
need to develop)
http://www.foundstone.com/index.htm?...assessment.htm

If that does not fit your needs, then your kinda talking about writing a NAT
router. This can be done, but not sure how easier/hard it would be in .Net.
Would need direct IP access I think. An application router would be easier,
but not sure about your needs. I would look hard at fpipe, ISA, or other
before trying to code this. hth

--
William Stacey, MVP

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[Adam Clauss]

I'll take a look at that.

Thanks for the suggestions.
And no - I'm not set on doing it in .Net. I'm also proficient in C++, so
that would be the alternative if I needed a much "lower" level access
programming.

Adam Clauss
ca*****@tamu.edu

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Ok**************@tk2msftngp13.phx.gbl...

Sound like maybe fpipe type of application is what you need (and you don't
need to develop)
http://www.foundstone.com/index.htm?...assessment.htm
If that does not fit your needs, then your kinda talking about writing a NAT router. This can be done, but not sure how easier/hard it would be in ..Net. Would need direct IP access I think. An application router would be easier, but not sure about your needs. I would look hard at fpipe, ISA, or other
before trying to code this. hth

--
William Stacey, MVP

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[Adam Clauss]

Yes - that is very similar to what I need.

The exception is the fact that I need to run two applications on the 'same
port'. I do not believe that those applications will give me the ability to
filter incoming connections (that are on the SAME port) and, depending on
their content, redirect to different places.

They WILL give me a very good place to start from however.

Adam Clauss
ca*****@tamu.edu

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:Ol*************@TK2MSFTNGP11.phx.gbl...

I'll take a look at that.

Thanks for the suggestions.
And no - I'm not set on doing it in .Net. I'm also proficient in C++, so
that would be the alternative if I needed a much "lower" level access
programming.

Adam Clauss
ca*****@tamu.edu

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Ok**************@tk2msftngp13.phx.gbl...

Sound like maybe fpipe type of application is what you need (and you don't need to develop)

http://www.foundstone.com/index.htm?...assessment.htm

If that does not fit your needs, then your kinda talking about writing a

NAT

router. This can be done, but not sure how easier/hard it would be in

.Net.

Would need direct IP access I think. An application router would be

easier,

but not sure about your needs. I would look hard at fpipe, ISA, or other before trying to code this. hth

--
William Stacey, MVP

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...

I am trying to work-around a firewall which limits me to only being
able to accept inbound connections on port 80. Unfortunately, I need
to two different applications to be able to accept connections. I
know of no "standard" way to make this work (and, its quite possible
that I am on the totally wrong track here and there just isn't a way
to do this).

I am trying to determine if it would be possible to write a 'gateway'
program that would actually be listening on port 80 and accept any
incoming connections. Upon accepting the connection, it would then
await the first packet of incoming data from the client (in both
applications, the first communication is done by the client). Once
this packet has been received, I should be able to look at the packet
and identify which application it is supposed to be for.

Here's where I am thinking this idea might not work. Upon figuring
out which application the connection was intended for, is there anyway
to ... "redirect" the socket connection to the appropriate
application, which might be listening on say ports 3000 and 3001.
Unfortunately, I cannot modify the other applications, so this would
need to all be transparent to them - the connection would just need to
appear as a 'brand new' connection to be Accepted. Preferably also,
that initial packet would still be in the network buffer (maybe a way
to "peek" at it from the gateway program rather than an actual read?).

If this 'redirection' cannot be done, I am also considering having the
gateway actually maintain the connection and forward data back and
forth. AKA: When an incoming connection is received, the gateway app
(which would be running physically on the same machine as the other
applications) would then open its own connection to the appropriate
application. Upon receiving data from the client, it would re-send
that data to the server. Likewise, upon receiving data from the
server, it would re-send that data to the client. However, while
possibly the easier (and maybe the only doable one) of the two
solutions, this one seems like the lesser of the two. First, the
server would actually be aware that the gateway was there - it would
see a local IP address rather than the clients. Second, I worry about
performance. In possibly high-traffic times, could all this
forwarding be costly?

Ideas? Thoughts? Suggestions?

Thanks!

[William Stacey [MVP]]

Cool. In that case, I would think using .Net would be ~easy and should give
you everything you need (having not thought about all issues in your app.)

--
William Stacey, MVP

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl...

Yes - that is very similar to what I need.

The exception is the fact that I need to run two applications on the 'same
port'. I do not believe that those applications will give me the ability to filter incoming connections (that are on the SAME port) and, depending on
their content, redirect to different places.

They WILL give me a very good place to start from however.

Adam Clauss
ca*****@tamu.edu

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:Ol*************@TK2MSFTNGP11.phx.gbl...

I'll take a look at that.

Thanks for the suggestions.
And no - I'm not set on doing it in .Net. I'm also proficient in C++, so

that would be the alternative if I needed a much "lower" level access
programming.

Adam Clauss
ca*****@tamu.edu

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:Ok**************@tk2msftngp13.phx.gbl...

Sound like maybe fpipe type of application is what you need (and you don't need to develop)

http://www.foundstone.com/index.htm?...assessment.htm

If that does not fit your needs, then your kinda talking about writing a NAT

router. This can be done, but not sure how easier/hard it would be in

.Net.

Would need direct IP access I think. An application router would be

easier,

but not sure about your needs. I would look hard at fpipe, ISA, or other before trying to code this. hth

--
William Stacey, MVP

"Adam Clauss" <ca*****@tamu.edu> wrote in message
news:7c**************************@posting.google.c om...
> I am trying to work-around a firewall which limits me to only being
> able to accept inbound connections on port 80. Unfortunately, I

need > to two different applications to be able to accept connections. I
> know of no "standard" way to make this work (and, its quite possible
> that I am on the totally wrong track here and there just isn't a way
> to do this).
>
> I am trying to determine if it would be possible to write a 'gateway' > program that would actually be listening on port 80 and accept any
> incoming connections. Upon accepting the connection, it would then
> await the first packet of incoming data from the client (in both
> applications, the first communication is done by the client). Once
> this packet has been received, I should be able to look at the packet > and identify which application it is supposed to be for.
>
> Here's where I am thinking this idea might not work. Upon figuring
> out which application the connection was intended for, is there anyway > to ... "redirect" the socket connection to the appropriate
> application, which might be listening on say ports 3000 and 3001.
> Unfortunately, I cannot modify the other applications, so this would
> need to all be transparent to them - the connection would just need to > appear as a 'brand new' connection to be Accepted. Preferably also,
> that initial packet would still be in the network buffer (maybe a way > to "peek" at it from the gateway program rather than an actual read?). >
> If this 'redirection' cannot be done, I am also considering having the > gateway actually maintain the connection and forward data back and
> forth. AKA: When an incoming connection is received, the gateway app > (which would be running physically on the same machine as the other
> applications) would then open its own connection to the appropriate
> application. Upon receiving data from the client, it would re-send
> that data to the server. Likewise, upon receiving data from the
> server, it would re-send that data to the client. However, while
> possibly the easier (and maybe the only doable one) of the two
> solutions, this one seems like the lesser of the two. First, the
> server would actually be aware that the gateway was there - it would
> see a local IP address rather than the clients. Second, I worry about > performance. In possibly high-traffic times, could all this
> forwarding be costly?
>
> Ideas? Thoughts? Suggestions?
>
> Thanks!