1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Tomato as OpenVPN Client, unable to start - Raspberry Pi (pivpn) as OpenVPN Server

Discussion in 'Tomato Firmware' started by AggieChris07, Apr 14, 2017.

  1. AggieChris07

    AggieChris07 New Member Member

    Hi Folks,

    I am trying to configure my router as an open VPN client to connect to my Raspberry Pi OpenVPN server (pivpn),but I haven't had any luck.
    I am able to connect to my vpn server with my windows and my android client correctly, but I am unable to get my tomato router to connect.
    I apologize in advance for my noobness on Linux and tomato in advance. I am new to both but trying hard to learn.
    After two weeks of forum reading and digging through OpenVPN and tomato forums, trying different client configuration options in the tomato GUI vpn, and generally banging my head against the wall i havn't made any progress.
    I am coming to the conclusion that most of what I am looking at is above my current Linux/tomato reading level.

    Perhaps someone with a better understanding can spot my error? :)

    here is my server conf:
    Code:
    dev tun
    proto udp
    port ####(my port number)
    ca /etc/openvpn/easy-rsa/pki/ca.crt
    cert /etc/openvpn/easy-rsa/pki/issued/server.crt
    key /etc/openvpn/easy-rsa/pki/private/server.key
    dh /etc/openvpn/easy-rsa/pki/dh2048.pem
    topology subnet
    server 10.8.0.0 255.255.255.0
    # server and remote endpoints
    ifconfig 10.8.0.1 10.8.0.2
    # Add route to Client routing table for the OpenVPN Server
    push "route 10.8.0.1 255.255.255.255"
    # Add route to Client routing table for the OPenVPN Subnet
    push "route 10.8.0.0 255.255.255.0"
    # your local subnet
    push "route 192.168.1.0 255.255.255.0"
    # Set your primary domain name server address for clients
    push "dhcp-option DNS 8.8.8.8"
    push "dhcp-option DNS 8.8.4.4"
    # Override the Client default gateway by using 0.0.0.0/1 and
    # 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
    # overriding but not wiping out the original default gateway.
    push "redirect-gateway def1"
    client-to-client
    duplicate-cn
    keepalive 10 120
    tls-version-min 1.2
    tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
    cipher AES-256-CBC
    auth SHA256
    comp-lzo
    user nobody
    group nogroup
    persist-key
    persist-tun
    #crl-verify /etc/openvpn/crl.pem
    status /var/log/openvpn-status.log 20
    status-version 3
    log /var/log/openvpn.log
    verb 1
    And this is the client config that works with windows and android:
    Code:
    client
    
    dev tun
    proto udp
    remote mydynamicdnsaddress ####(portnumber)
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    key-direction 1
    remote-cert-tls server
    tls-version-min 1.2
    verify-x509-name server name
    cipher AES-256-CBC
    auth SHA256
    comp-lzo
    verb 1
    <ca>
    -----BEGIN CERTIFICATE-----
    *********certificate is here ******
    -----END CERTIFICATE-----
    </ca>
    <cert>
    -----BEGIN CERTIFICATE-----
    *******second certificate here*****
    -----END CERTIFICATE-----
    </cert>
    <key>
    -----BEGIN ENCRYPTED PRIVATE KEY-----
    ********privatekeyhere*****
    -----END ENCRYPTED PRIVATE KEY-----
    </key>
    <tls-auth>
    #
    # 2048 bit OpenVPN static key
    #
    -----BEGIN OpenVPN Static key V1-----
    ***STATIC KEY IS HERE***
    -----END OpenVPN Static key V1-----
    </tls-auth>
    and here are my current configuration options in Tomato:
    Code:
    Start with WAN: disabled
    
    Interface Type: TUN
    Protocol: UDP
    Server Address/port: mydynamicdnsaddress ####(portnumber)
    Username/Password Authentication: enabled
    Username: client name from my openvpn configuration(same as name of .ovpn file)
    Password: password I use to connect on windows
    Username Authen. Only: disabled
    Extra HMAC authorization: outgoing(1)
    Create NAT on tunnel: enabled
    Poll Interval:0
    Redirect Internet Traffic: enabled
    Accept DNS Configuration: Relaxed
    Encryption cipher: AES-256-CBC
    Compression: None
    TLS Renegotiation Time: -1
    Connection retry: -1
    Verify server certificate (tls-remote): disabled
    Custom configuration:
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    remote-cert-tls server
    tls-version-min 1.2
    verify-x509-name server name
    auth SHA256
    verb 1
    
    Keys: copied from .ovpn file
    Redirect through VPN: disabled
    When I enable the VPN with the above settings I get:
    Code:
    Apr 13 22:30:24 unknown daemon.notice openvpn[3088]: OpenVPN 2.3.11 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Aug  1 2016
    Apr 13 22:30:24 unknown daemon.notice openvpn[3088]: library versions: OpenSSL 1.0.2h  3 May 2016, LZO 2.09
    Apr 13 22:30:24 unknown daemon.warn openvpn[3090]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    Apr 13 22:30:24 unknown daemon.err openvpn[3090]: neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'.  If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.
    Apr 13 22:30:24 unknown daemon.notice openvpn[3090]: Exiting due to fatal error
    Apr 13 22:30:24 unknown user.notice root: vpnrouting: clean-up
    I have done some googleing on the error, and most of the results indicated that I needed add the askpass option on the server, but it is confusing to me that this would be needed when windows and android OpenVPN connect just fine.

    Any help is appreciated.
    Sorry for the long post.

    Thanks in advance,

    Chris
     
  2. AggieChris07

    AggieChris07 New Member Member

    So I attempted another fix, changing the server.conf to include:
    askpass /tmp/password.ovpn
    auth-nocache

    I then added to the startup script of my router:
    echo **mypasswordhere** > /tmp/password.ovpn
    chmod 600 /tmp/password.ovpn

    and added in the custom configuration box:
    askpass /tmp/password.ovpn
    auth-nocache

    and disabled the user/pass auth in the client settings.

    unfortunately, still no dice.

    the router acts like I am connected except then I get a tls handshake problem:
    Apr 15 02:04:16 unknown daemon.err openvpn[1752]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Apr 15 02:04:16 unknown daemon.err openvpn[1752]: TLS Error: TLS handshake failed

    So I guess back to googling.
     
  3. eibgrad

    eibgrad Network Guru Member

    There are a lot of potential problems here, depending on how all this is configured. I'm not even sure if perhaps this tomato router (acting as the OpenVPN client) might not be on the same local IP network as the PI and OpenVPN server, which can lead to ambiguous routing problems.

    As far as username/password, just to remove that as a possible problem, disable that feature, at least until you get it working.

    And btw, unlike the OpenVPN client running on your Windows or Mac, you can't use askpass on the router since the router doesn't provide a UI for this purpose. You need to use the Username/Password Authentication field for these purposes. The router will then pass the username/password directly to the OpenVPN server using the auth-user-pass directive (under the covers).

    And one more thing about username/password. If you're using certs and key files already, that's normally sufficient. All username/password does is add another layer of security, but in most cases, it's more trouble than it's worth because you now have to manage those usernames/passwords on the server. And if you're just having everyone use the same username/password, then it's even more pointless.

    Username/password is more useful if every OpenVPN client is sharing the same certs and key files and you need some way to differentiate users. This is more commonly the case w/ commercial OpenVPN providers because it's just too much hassle for them to be managing certs and key files for each and every user. So they in effect reduce their security to username/password as a convenience to them. But for SOHO users, you're usually better off to generate unique certs and key files and leave it at that. It's more secure. Just forget about username/password completely, esp. if everyone ends up using the same username/password.

    When it comes to OpenVPN configuration, esp. when you're having problems, the less you add the better. This issue of username/password is a classic example. You end up bogged down on something that has nothing to do w/ the basic connectivity. All you care about at the moment is getting the OpenVPN client connected to the OpenVPN server. The less obstacles you create, the more likely it will work. You can always go back later and add stuff to optimize the connection, improve security, etc. But for now, keep it simple! Don't even push routes on the OpenVPN server (since that can create routing ambiguity if the OpenVPN client and server are on the same local IP network). Just get connected and make sure you can ping each side of the VPN tunnel. Then work from there.
     
    Last edited: Apr 16, 2017
    AggieChris07 likes this.
  4. AggieChris07

    AggieChris07 New Member Member

    Thanks for the response eibgrad, I appreciate your advice.

    I totally agree with you that it should be enough security.
    As long as I keep this client certificate secure, I should be safe enough.
    I went back to my server and generated a new client without a password, updated my tomato config with the new and voila it connects!
    I will keep this one only for the router, so I totally agree that this should be plenty secure.

    I also took your advice to examine the possible IP address conflicts.

    I did a couple of things, I updated this line in the server config:
    Code:
    # your local subnet
    push "route 192.168.1.0 255.255.255.0"
    to:
    Code:
    # your local subnet
    push "route 192.168.0.0 255.255.255.0"
    I had initially configured the raspberry pi (pivpn) server on my test network, the ip address of gate was 192.168.1.1, but when I moved it to the final home, I forgot to change it to that local subnet.
    I think you were right that this meant that the routing would get confused, especially when connecting to my test network that had a IP address in the 192.168.1.0 family.

    Also, just to make sure I didn't have any conflicts I changed the test client router IP address to another ip address.

    And success!

    Thank you very much for your help!
     

Share This Page