[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Unexpected WARNINGS


  • Subject: Re: [Openvpn-users] Unexpected WARNINGS
  • From: Jan Just Keijser <janjust@xxxxxxxxx>
  • Date: Wed, 12 Dec 2007 14:23:53 +0000

I am fast running out of suggestions here...
can you try playing with the
  --cipher
  --tls-cipher
options? I think the busybox is screwing up something in the encryption 
phase.
For example, try adding
  cipher none
  tls-cipher RC4-MD5
to both client and server. You can see the list of supported SSL and TLS 
ciphers by typing
  openvpn --show-ciphers
  openvpn --show-tls

cheers,

JJK

Tiger Big wrote:
> I've tried to use tun device, still get same warning. I'm sure the tun
> device is enabled,cause there is a server message saying a
> point-to-point tunnel sucessfully established.
>
> The linux server is a busybox router runing on a MIPS CPU. I don't
> know the command to disable iptables on that system. I'm still looking
> for that.
>
> On Dec 12, 2007 1:34 AM, Jan Just Keijser <janjust@xxxxxxxxx> wrote:
>   
>> Tiger Big wrote:
>>     
>>> Hi, Jan
>>> I've followed your guide, here is the output of client:
>>> ----------------------------------------------------------------------------
>>> [...]
>>> Tue Dec 11 22:15:13 2007 us=719961 NOTE: Options consistency check may
>>> be skewed by version differences
>>> Tue Dec 11 22:15:13 2007 us=720072 WARNING: 'version' is used
>>> inconsistently, local='version V4', remote='version V0 UNDEF'
>>> [...]
>>> -------------------------------------------------------------------------------------------------------------
>>> Warring message still there. Also, I've tried "proto udp", same
>>> result. I havn't tried "dev tun", cause I don't know what other option
>>> should be modified, or should I just leave others untouched?
>>>
>>>       
>> you can change it to 'tun' on both client and server side without harm.
>>
>>     
>>> And I noticed another strange thing: in client's warning message,
>>> there's a line saying "'proto' is present in local config but missing
>>> in remote config, local='proto TCPv4_SERVER'", but as you can see,
>>> what I put in client's config is "proto tcp-client" instead of "proto
>>> tcp-server".
>>>
>>>       
>> this is to be expected: the warning messages states what the client is
>> expecting to come from the server and it matches this against what it
>> actually receives from the server. So it *expects* the server to send
>> TCPv4_SERVER.
>>
>> Try disabling your iptables just to satisfy our curiousity....
>>
>> cheers,
>>
>> JJK
>>
>>     
>>> BTW, there is not any hardware firewall between client and server,
>>> I've disabled client's windows firewall. For server, I think iptables
>>> is the firewall? should I post my iptables output ? this mail is too
>>> long :)
>>>
>>>
>>> On Dec 10, 2007 8:52 PM, Jan Just Keijser <janjust@xxxxxxxxx> wrote:
>>>
>>>       
>>>> the line
>>>>
>>>>
>>>> Mon Dec 10 19:37:13 2007 us=649638 Notified TAP-Win32 driver to set a
>>>> DHCP IP/netmask of 192.168.10.22/255.255.255.0
>>>> <http://192.168.10.22/255.255.255.0> on interface
>>>>
>>>> {49F4CC5A-D115-4353-BDAE-16A232DE9E7A} [DHCP-serv: 192.168.10.0
>>>> <http://192.168.10.0>, lease-time: 31536000]
>>>>
>>>> suggests that the DHCP server is at 192.168.10.0 ... that does not make
>>>> sense. Can you try this in your server config file:
>>>>
>>>>
>>>> server 192.168.10.0 255.255.255.0
>>>> passtos
>>>> proto tcp
>>>> local xx.xx.org
>>>> port 8080
>>>>
>>>> dev tap0
>>>> cert X509/Server/server.crt
>>>> key X509/Server/server.key
>>>> dh X509/Server/dh1024.pem
>>>> ca X509/CA/ca.crt
>>>> keepalive 10 120
>>>> user nobody
>>>> group nobody
>>>> persist-key
>>>> persist-tun
>>>> comp-lzo
>>>> verb 4
>>>> mute 10
>>>>
>>>>
>>>> other than that , I am pretty much at a loss: during the negotiation
>>>> phase there seems to be some data corruption:
>>>> it's doing the certificate verify, it's doing other connection settings
>>>> and Boom, all of a sudden the client receives a completely wrong remote
>>>> config packet. Are there any firewalls in place on your LAN?
>>>>
>>>> Also, try
>>>> dev tun
>>>> instead of
>>>> dev tap
>>>> this will give you a slightly different type of network (TCP/IP only)
>>>> but if this one works then we're one step further.
>>>>
>>>>
>>>>
>>>>         
>>     

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users