Re: [Openvpn-users] openvpn-2.0_beta4 --mode server in Bridged configuration

[sam <sa...@hg...>]

James Yonan wrote:

>Adam Pavelec <apa...@be...> said:
>
>  
>
>>On Monday, June 14, 2004 8:20 PM [GMT-5=EST], James Yonan <ji...@yo...>
>>wrote:
>>
>>    
>>
>>>>Which attributes of the certs need to be the same; and which
>>>>attributes need to be different?
>>>>
>>>>I initially created certs for both the server and client with the
>>>>exact same parameters and received an error while creating the
>>>>client cert (TXT_DB error number 2), apparently because its
>>>>attributes were identical to the server's cert.
>>>>
>>>>Then I created a server key with a commonName of something like
>>>>'OpenVPN-Server' and then used 'OpenVPN-Client' for the client's
>>>>cert.
>>>>
>>>>When I test the connection using the custom-tailored sample configs
>>>>from the release notes, the TLS handshake fails, and the server
>>>>spits out "Error: Windows resource limit WSA_MAXIMUM_WAIT_EVENTS
>>>>(64) has been exceeded" errors while the client reports "TLS Error:
>>>>Unroutable control packet received from ip.address.of.server:port
>>>>(si=3 op=P_CONTROL_V1)".
>>>>        
>>>>
>>>The WSA_MAXIMUM_WAIT_EVENTS error is a real bug in beta4 and has been
>>>fixed in beta5.
>>>      
>>>
>>Thanks for the info - I will move up to the current version.  And please
>>forgive my ignorance and inexperience, but am I creating my certs correctly?
>>It looks as though my TLS handshake issue will still be problematic on
>>beta5.
>>    
>>
>
>The "TLS handshake failed" condition is very general and could simply mean
>that there's no OpenVPN running on the other side of the connection, or
>there's a link failure.
>
>If the sample certs provided work but your own certs don't, then I would
>question whether or not your own certs were generated correctly.
>
>If the sample certs don't work, then it may just be a network connection issue.
>
>James
>
>
>  
>
I found a problem with this error was when client established connection 
with server, client only able to send initial requests to server, but 
never get packet back from the server. At client, I used tcpdump watch 
network traffic on tap device. I was never able to solve this problem, 
then I decided change the server platform to FreeBSD, because my orginal 
Redhat 9.1 server have vmware installed with bridge mode configured on 
other virtual network devices. I thought this cuased the routing problem 
with OpenVPN server. I don't meant OpenVPN does it incorrectly, but that 
may be base system caused incorrect routing. Sorry I don't have evident 
to prove what I m guessing here. Anyway, I have changed  platform to 
FreeBSD, and now everything is working like a charm.

sam