[lug] traceroute on forwarded ports plus socks vs port forward

Dan Ferris dan at usrsbin.com
Wed Jul 6 14:48:23 MDT 2011


So why can't you just run OpenVPN on the remote server instead of SSH?  
I don't see why your local VPN server has anything to do with this.

I've done exactly what you are trying to do and SSH tunneling is slow, 
nasty, and dies a lot.  Especially if you get even the smallest amount 
of packet loss.

Dan

On 7/6/2011 1:49 PM, karl horlen wrote:
>
> unfortunately the VPN server we use uses a global config for all 
> clients and they don't want internet traffic being routed through it
>
> --- On *Wed, 7/6/11, Dan Ferris /<dan at usrsbin.com>/* wrote:
>
>
>     From: Dan Ferris <dan at usrsbin.com>
>     Subject: Re: [lug] traceroute on forwarded ports plus socks vs
>     port forward
>     To: "Boulder (Colorado) Linux Users Group -- General Mailing List"
>     <lug at lug.boulder.co.us>
>     Date: Wednesday, July 6, 2011, 12:42 PM
>
>     OpenVPN is your friend in these types of situations.  You can use
>     an OpenVPN server to push routes for things around.  It's also a
>     lot more reliable that using things like SSH tunnels.
>
>     Dan
>
>     On 7/6/2011 10:48 AM, karl horlen wrote:
>>     i'm trying to route local port 80 / 443 locally to an external
>>     server so i can browse through it.
>>
>>     is there a way to confirm that i am indeed using those ports? 
>>     when i run a tracert (the client is windows and i'm running
>>     tracert from cmd aka dos prompt), the hops still route through my
>>     dsl provider.  i presume that is the correct behavior since
>>     traceroute probably works on a different port other than 80 or 443.
>>
>>     so other than using a packet sniffer, is there a command i can
>>     run to prove when i load an url in a browser that i'm actually
>>     routing through my remote server via ssh tunnel and not through
>>     the hops associated with my dsl provider.
>>
>>     finally, i'm forwarding two local ports, 80 and 443 and am
>>     assuming that on a windows box the browser should just find and
>>     use these ports.  i've seen recommendations for using a socks
>>     proxy to achieve the same result.  i'm trying to understand the
>>     difference.  from what i gather, a socks proxy will do the same
>>     thing but you only have to set one forwarding which is the socks
>>     ip address instead of two (80 and 443) in port forwarding
>>     method.  but you also have to configure the app, in this case the
>>     browser to use the proxy, an additional step.  then the browser /
>>     app simply forwards all requests on any and all ports fed to it
>>     to the socks proxy port. is this correct?
>>
>>     i guess i'm not sure what the benefits are to using one method vs
>>     the other.  since ssh (windows putty) allows you to configure
>>     multiple port forwards in one definition, once you set it up, you
>>     just have to kick off the connection so it saves you the hassle
>>     of enabling disabling socks proxy in your browser config.
>>
>>     so why would i want to use a socks proxy?  i can't think of any
>>
>>     thanks
>>
>>
>>     _______________________________________________
>>     Web Page:http://lug.boulder.co.us
>>     Mailing List:http://lists.lug.boulder.co.us/mailman/listinfo/lug
>>     Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
>     -----Inline Attachment Follows-----
>
>     _______________________________________________
>     Web Page: http://lug.boulder.co.us
>     Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>     Join us on IRC: irc.hackingsociety.org port=6667
>     channel=#hackingsociety
>
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20110706/2ae8cb16/attachment.html>


More information about the LUG mailing list