On 2011-04-20 14:52 , Mads Kiilerich wrote:
> On 04/19/2011 01:03 PM, Bengt-Arne Fjellner wrote:
>> Hi I would like to add support for tunneling over a socks connection.
>> This is a first draft to show how it could be used.
>> I have not done any work (yet) on argument passing since this needs to
>> be discussed how it should look.
>>
>> This is only tested on OSX but should work fine on any unix.
>> Might work on windows but I doubt it (how to get username there?).
>> Rest of it should work there to.
>>
>> Usage steps:
>>
>> first start ssh like this
>>
>> ssh -D 1234 relay_host
>> or in putty configure a "dynamic" ssh forwarding
>>
>> next
>> in bash:
>> RDPDEST=realdest RDPPORT=3389 xfreerdp localhost:1234
>>
>> tcsh
>> env RDPDEST=realdest RDPPORT=3389 xfreerdp rdpoptions localhost:1234
>>
>> where realdest is the rdpserver you want to reach
>> RDPPORT the port on the rdp server defaults to 3389
>> localhost where the socks4 server is, in this case localhost
>> 1234 the socks port
>>
>> Now your rdp session will go via a sshtunnel and hopefully be on right
>> side of firewall rules.
>>
>>
>> Patch attached this only affects tcp.c in libfreerdp
>>
>> Bengt-Arne Fjellner
>> Luleå University of Technology
> 
> 
> Right. SOCKS is an old, widely used, generic and quite well-defined 
> protocol, and many client tools do have built-in support for SOCKS, so 
> why shouldn't freerdp have it.
> 
> But on the other side: Why should it? And why can't those who need it 
> just use a socksifier (tsocks, dante, runsocks, ProxyChains etc) that 
> injects SOCKS into the application through dynamic linking?

Sockifier et al does not work on OSX usually.

> 
> SOCKS is however IMHO substantially different from the XP Unlicensed 
> hack. The XP hack was designed to be implemented in a wrapper around a 
> rdp client. For some reason we got some hooks to do that in a more 
> complex way. The SOCKS protocol kind of replaces and redefines 
> getaddrinfo and connect and is thus very different from the XP stuff. 
> Just like SSL support is isn't something that is suitable for 
> implementation through generic hooks.
> 
> My tentative conclusion is that I would like to see SOCKS support built in.
> 
> Some comments to the patch:
> 
> You send the local username. Why? It could in principle be used for some 
> kind of load balancing and persistent reconnect, but are you aware of 
> any products that do that? I would suggest just leaving the username 
> field blank/empty. If there is good reason to specify the username: 
> Shouldn't it use the specified username (if available) rather than the 
> local account name? Note also that it has to work on Windows as well.
> 
Local username is sent as that is what the standard says to do.
The reason is that if somone still is using identd it should be checked
if the correct user is doing it. I could send anything instead.

> The configuration also has to be swapped around so the server address 
> always is the server address and the socks server is optional. So 
> instead of
> RDPDEST=realdest RDPPORT=3389 xfreerdp localhost:1234
> it should be more like
> SOCKS_SERVER=localhost:1234 xfreerdp realdest:3389
> 
> The option should however also be available on the command line, for 
> example as
> xfreerdp --socks=localhost:1234 realdest:3389

Yes of course. This was just a first draft to see if it could be
accepted at all and was not meant for real use.

But I have some problem finding the arguments down in tcp.c
Is there a simple way to find that struct there?
And I would suggest something like
--socks4=...:... to get socks4
--socks= would give socks5
comments?
> 
> I am not aware of any widely used standards for variables and options 
> for controlling SOCKS, but you might want to take a look at curl and 
> other tools for inspiration.
> 
> I think it is very important that we use SOCKS4a (or later) and do name 
> resolution on the server side (at least unless an IP address is specified).
> 
Socks4a is unfortunately not supported by openssh (or was at least) so I
can't test it but I will try to implement it blind if someone else is
willing to do the tests .

> It is important that this feature works together with server redirects - 
> that is where it could be really useful.
> 
> We would have to use SOCKS5 to support IPv6. Is it relevant to support 
> SOCKS4 at all?
> 

Socks4 was easiest to start with and is well supported by openssh which
is what I use it for.

Socks5 is in my plans to.

> Finally: Please try to follow the coding style used in the rest of the 
> code, especially regarding white-space.
> 

Yes this to will be done before I submit a real patch.

> /Mads


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Reply via email to