lan-to-lan vpn problems with zeroshell server or client

Home Page Forums Network Management VPN lan-to-lan vpn problems with zeroshell server or client

This topic contains 1 reply, has 0 voices, and was last updated by  novadino 7 years, 11 months ago.

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #42911

    novadino
    Member

    i’ve been trying zeroshell and vpn in particular and i have some problem. i’ll demonstrate three examples with which i have problems. i’m a newbie so any help would be valuable

    • Firstly I’m trying to connect lan to lan vpn with zeroshell client to openvpn server in windows 2003.

    This is the client config in windows xp

    client
    dev tap
    proto tcp-client
    remote xxx.xxx.xxx.xxx 5005
    resolv-retry infinite
    nobind
    ca vpn_koilakos_ca.crt
    cert vpn_koilakos_client.crt
    key vpn_koilakos_client.key
    tls-auth vpn_koilakos_ta.key 1
    ns-cert-type server
    comp-lzo
    verb 3
    mute 20
    route-delay 10

    This is the client config in zeroshell

    remote xxx.xxx.xxx.xxx client port 5005 tcp
    parameters
    –tls-auth /Database/ets/ssl/koilakos/vpn_koilakos_ta.key 1 –ns-cert-type server –verb 3

    also imported ca.crt, koilakos key and crt

    Using the above win xp config I can connect to the Vpn server but not with zeroshell. Am I missing anything?

    The log that follows is the one from zeroshell
    10:45:07 OpenVPN 2.1.4 i586-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Dec 30 2010
    10:45:07 MANAGEMENT: TCP Socket listening on 127.0.0.1:34001
    10:45:07 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    10:45:07 Control Channel Authentication: using ‘/Database/etc/ssl/koilakos/vpn_koilakos_ta.key’ as a OpenVPN static key file
    10:45:07 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    10:45:07 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    10:45:07 LZO compression initialized
    10:45:07 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
    10:45:07 Socket Buffers: R=[87380->131072] S=[16384->131072]
    10:45:07 TUN/TAP device VPN01 opened
    10:45:07 TUN/TAP TX queue length set to 100
    10:45:07 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
    10:45:07 Local Options hash (VER=V4): ‘e39a3273’
    10:45:07 Expected Remote Options hash (VER=V4): ‘3c14feac’
    10:45:07 Attempting to establish TCP connection with 62.103.64.160:5005 [nonblock]
    10:45:07 MANAGEMENT: Client connected from 127.0.0.1:34001
    10:45:07 MANAGEMENT: CMD ‘state’
    10:45:07 MANAGEMENT: Client disconnected
    10:45:07 Interface VPN01 is DOWN
    10:45:09 MANAGEMENT: Client connected from 127.0.0.1:34001
    10:45:09 MANAGEMENT: CMD ‘state’
    10:45:09 MANAGEMENT: Client disconnected
    10:45:11 MANAGEMENT: Client connected from 127.0.0.1:34001
    10:45:11 MANAGEMENT: CMD ‘state’
    10:45:11 MANAGEMENT: Client disconnected
    10:45:12 MANAGEMENT: Client connected from 127.0.0.1:34001
    10:45:12 MANAGEMENT: CMD ‘log all’
    10:45:12 MANAGEMENT: Client disconnected
    10:45:13 MANAGEMENT: Client connected from 127.0.0.1:34001
    10:45:13 MANAGEMENT: CMD ‘state’
    10:45:13 MANAGEMENT: Client disconnected
    10:45:15 MANAGEMENT: Client connected from 127.0.0.1:34001
    10:45:15 MANAGEMENT: CMD ‘state’
    10:45:15 MANAGEMENT: Client disconnected
    I’m wondering if you have any ideas on which is the problem. I’m stating that with the windows config I can connect to the vpn server.

    • In the second scenario in trying to connect lan to lan vpn with zeroshell server to openvpn client. Here is the server config in zeroshell

    port 6005 tcp server compression and encryption checked
    parameters
    –tls-auth /Database/etc/ssl/zero/ta.key 1 –verb 4

    also imported ca.crt

    Here is the log of the vpn server :
    client = DISABLED
    17:10:07 pull = DISABLED
    17:10:07 auth_user_pass_file = ‘[UNDEF]’
    17:10:07 OpenVPN 2.1.4 i586-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Dec 30 2010
    17:10:07 MANAGEMENT: TCP Socket listening on 127.0.0.1:34000
    17:10:07 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    17:10:07 Diffie-Hellman initialized with 1024 bit key
    17:10:07 Control Channel Authentication: using ‘/Database/etc/ssl/zero/ta.key’ as a OpenVPN static key file
    17:10:07 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    17:10:07 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    17:10:07 LZO compression initialized
    17:10:07 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:0 ET:0 EL:0 ]
    17:10:07 Socket Buffers: R=[87380->131072] S=[16384->131072]
    17:10:07 TUN/TAP device VPN00 opened
    17:10:07 TUN/TAP TX queue length set to 100
    17:10:07 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
    17:10:07 Local Options String: ‘V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server’
    17:10:07 Expected Remote Options String: ‘V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client’
    17:10:07 Local Options hash (VER=V4): ‘5bf24d17’
    17:10:07 Expected Remote Options hash (VER=V4): ’43fd27a7′
    17:10:07 Listening for incoming TCP connection on [undef]:6005
    17:10:07 MANAGEMENT: Client connected from 127.0.0.1:34000
    17:10:07 MANAGEMENT: CMD ‘state’
    17:10:07 MANAGEMENT: Client disconnected
    17:10:07 Interface VPN00 is DOWN

    To summarize, shouldn’t the vpn interface be UP regardless of weather I can connect to it with a vpn client?

    • In my final scenario I’m trying to connect lan to lan vpn with zeroshell client to openvpn server in Centos 5.4.

    This is the server config file
    proto udp
    port 5005
    dev tun
    ca /etc/openvpn/keys/ca.crt
    cert /etc/openvpn/keys/server.crt
    key /etc/openvpn/keys/server.key
    tls-auth /etc/openvpn/keys/ta.key 0
    dh /etc/openvpn/keys/dh1024.pem
    server 10.231.20.0 255.255.255.0
    ifconfig-pool-persist pool.txt
    client-to-client
    client-config-dir ccd
    keepalive 10 60
    cipher AES-256-CBC
    comp-lzo
    max-clients 100
    persist-key
    persist-tun
    user nobody
    group nobody
    tls-cipher DHE-RSA-AES256-SHA
    ccd-exclusive
    verb 3
    push “route 10.0.0.0 255.255.255.0”
    management 0.0.0.0 7505
    status /etc/openvpn/status.log
    log /etc/openvpn/openvpn.log

    Below, you can see the zeroshell client config

    remote xxx.xxx.xxx.xxx client port 5005 udp checked compression and encryption

    This is the parameter string:
    –client –proto udp –keepalive 10 60 –cipher AES-256-CBC –comp-lzo –dev tun1 –nobind –ns-cert-type server –persist-key –persist-tun –verb 3 –tls-auth /Database/etc/ssl/liverios/ta.key 1

    also imported ca.crt, koilakos key and crt

    This is the log file from zeroshell
    16:22:51 VERIFY OK: depth=1, /C=GR/ST=ATH/L=Athens/O=Poleiteia/CN=Po … s@evoip.gr
    16:22:51 VERIFY OK: nsCertType=SERVER
    16:22:51 VERIFY OK: depth=0, /C=GR/ST=ATH/L=Athens/O=Poleiteia/CN=se … s@evoip.gr
    16:22:51 WARNING: ‘dev-type’ is used inconsistently, local=’dev-type tap’, remote=’dev-type tun’
    16:22:51 WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu 1590′, remote=’link-mtu 1558′
    16:22:51 WARNING: ‘tun-mtu’ is used inconsistently, local=’tun-mtu 1532′, remote=’tun-mtu 1500′
    16:22:51 Data Channel Encrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
    16:22:51 Data Channel Encrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    16:22:51 Data Channel Decrypt: Cipher ‘AES-256-CBC’ initialized with 256 bit key
    16:22:51 Data Channel Decrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
    16:22:51 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    16:22:51 [server] Peer Connection Initiated with xx.xx.xx.xx:5005
    16:22:51 MANAGEMENT: Client connected from 127.0.0.1:34000
    16:22:51 MANAGEMENT: CMD ‘state’
    16:22:51 MANAGEMENT: Client disconnected
    16:22:53 MANAGEMENT: Client connected from 127.0.0.1:34000
    16:22:53 MANAGEMENT: CMD ‘state’
    16:22:53 MANAGEMENT: Client disconnected
    16:22:55 SENT CONTROL [server]: ‘PUSH_REQUEST’ (status=1)
    16:22:55 MANAGEMENT: Client connected from 127.0.0.1:34000
    16:22:55 MANAGEMENT: CMD ‘state’
    16:22:55 MANAGEMENT: Client disconnected
    16:22:57 MANAGEMENT: Client connected from 127.0.0.1:34000
    16:22:57 MANAGEMENT: CMD ‘state’
    16:22:57 MANAGEMENT: Client disconnected
    16:22:59 MANAGEMENT: Client connected from 127.0.0.1:34000
    16:22:59 MANAGEMENT: CMD ‘state’
    16:22:59 MANAGEMENT: Client disconnected
    16:23:00 SENT CONTROL [server]: ‘PUSH_REQUEST’ (status=1)
    16:23:01 PUSH: Received control message: ‘PUSH_REPLY,route 10.0.0.0 255.255.255.0,route 10.231.20.0 255.255.255.0,ping 10,ping-restart 60,ifconfig 10.231.20.38 10.231.20.37’
    16:23:01 OPTIONS IMPORT: timers and/or timeouts modified
    16:23:01 OPTIONS IMPORT: –ifconfig/up options modified
    16:23:01 OPTIONS IMPORT: route options modified
    16:23:01 WARNING: Since you are using –dev tap, the second argument to –ifconfig must be a netmask, for example something like 255.255.255.0. (silence this warning with –ifconfig-nowarn)
    16:23:01 ROUTE default_gateway=192.168.179.1
    16:23:01 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a –route option and no default was specified by either –route-gateway or –ifconfig options
    16:23:01 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.0.0.0
    16:23:01 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a –route option and no default was specified by either –route-gateway or –ifconfig options
    16:23:01 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.231.20.0
    16:23:01 TUN/TAP device tun1 opened
    16:23:01 TUN/TAP TX queue length set to 100
    16:23:01 /sbin/ifconfig tun1 10.231.20.38 netmask 10.231.20.37 mtu 1500 broadcast 255.255.255.254
    16:23:01 Initialization Sequence Completed
    16:23:01 PUSH: Received control message: ‘PUSH_REPLY,route 10.0.0.0 255.255.255.0,route 10.231.20.0 255.255.255.0,ping 10,ping-restart 60,ifconfig 10.231.20.38 10.231.20.37’
    16:23:01 MANAGEMENT: Client connected from 127.0.0.1:34000
    16:23:01 MANAGEMENT: CMD ‘state’
    16:23:01 MANAGEMENT: Client disconnected
    16:23:01 Interface VPN00 is UP

    In this last scenario, even though, VPN00 is UP I can not ping the other end and when I check with ipconfig VPN00 hasn’t obtained any ip. TUN1 interface has indeed obtained an ip but I don’t really now if that’s what it should happen.

    Any kind of help would be of great use for me. If you want any additional information I would be glad to provide it to you. Thanks in advance.

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.