|
|
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 |