Re: [Openvpn-devel] Re: unix - windows interop (shared secret whitespace problem)

[James Yonan]

Adam Laurie  said:

> 
> >> this was just a quick note to request that you do some whitespace foo 
> >  > (in particular CR/LF stuff) for the openvpn generated secret files as 
> >  > this seems to cause pain when setting up keys generated by one or other 
> >  > platform and then transferring them (my test platform was win2k -> 
> >  > freebsd-4.8).
> >  
> >  Not sure what the problem is.
> >  
> >  If you generate a static key on Windows, you will get CR-LF line 
> > termination.
> >   If you generate on *nix, you will get LF-only (i.e. newline) termination. 
> >  Each platform generates interoperable keys.  The only strange behaviour I
> >  noticed is if you generate a key on Linux then try to edit it with a dumb
> >  editor on windows (such as Notepad), it doesn't "get" the line termination
> >  right.  But OpenVPN will still read the key correctly, as the key reader is
> >  mostly whitespace independent.
> 
> ok, then the problem is that it's not working as expected. in trhis case 
> the key was generated on the win2k side and placed on the bsd server. 
> tls-auth failed. after editing with vi and removing ^M characters from 
> end of each line, tls-auth passed.
> 
> btw, when i tested with win-xp and a key generated on the bsd side i had 
> no problem, so i have seen it working as described as well, but on a 
> different platform.

Right, tls-auth generates the key by taking the sha1sum of the file, so it
will definitely be influenced by whitespace and newline conventions.  When you
said "openvpn generated secret files" I was thinking you were talking about
--genkey and static keys, which are not whitespace dependent.

James

[Openvpn-devel] RE: [Openvpn-users] connecting to multiple servers

[James Yonan]

Peter Sandström  said:

> I'm currently working on this, but as James says. This patch will be
> far to intrusive to be merged into 1.5 this late.
> The entire socketlayer needs to be ripped out and redone since alot
> of the current code assumes that there is always exactly one local
> and one remote address. Also there needs to be some kind of funky
> autolearning iprouting in order for it to work properly (working like
> a switch instead of a hub for those that want it in ethernet lingo).

I'm not sure that you need to rip out a lot of code to make this work.  The
socket layer does assume one local and one remote address, but this provides a
benefit in terms of making the code easy to understand and debug.

I would leave this code as it is, and do the following:

(1) Write code (which executes as a separate thread or process) which
implements a port multiplexing proxy.

(2) Write code (also as a separate thread) which implements a tun/tap sharing
proxy.

(3) Modify the socket code so that rather than doing connect(), bind(),
recvfrom(), sendto(), etc., it forwards these requests to the (1) proxy using
some kind of RPC-like mechanism.

(4) Modify the tun/tap code so that rather than
opening/reading/writing/closing the tun/tap file handle directly, it forwards
these requests to the (2) proxy.

This would give us UDP port and tun/tap multiplexing capability without
needing significant structural changes to the existing OpenVPN code.

James