OpenVPN needs a gateway parameter fo a --route option

I've got an OpenVPN client that isn't connecting to the vpn server. I've pasted the full log below, but in particular, I'm getting these issues with the route:

OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options

OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.0.1

There are many clients with the same client config that are connecting just fine. This client (and a few others) was connected, lost its connection due to the system time becoming too far out of sync (I believe), has since synced the system time, but is now still unable to connect. Usually, restarting the system fixes the issue. So it doesn't appear to be an issue with the VPN configuration but something with the client system.

I don't really know enough to understand the route issues or fix them. I do need to deal with recovering from the time sync issue, but for now, why can't I manually start a VPN connection from this client? What would cause OpenVPN to now need a gateway parameter?

log

$ openvpn gatewaymaster.conf
Fri Sep 30 12:03:07 2016 OpenVPN 2.2.1 arm-linux-gnueabihf [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec  1 2014
Fri Sep 30 12:03:07 2016 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Sep 30 12:03:07 2016 LZO compression initialized
Fri Sep 30 12:03:07 2016 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 30 12:03:07 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Fri Sep 30 12:03:07 2016 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 30 12:03:07 2016 Local Options hash (VER=V4): '41690919'
Fri Sep 30 12:03:07 2016 Expected Remote Options hash (VER=V4): '530fdded'
Fri Sep 30 12:03:07 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Sep 30 12:03:07 2016 UDPv4 link local: [undef]
Fri Sep 30 12:03:07 2016 UDPv4 link remote: [AF_INET]NNN.NNN.NNN.NNN:NNNN
Fri Sep 30 12:03:07 2016 TLS: Initial packet from [AF_INET]NNN.NNN.NNN.NNN:NNNN, sid=679c9108 60cb4eaf
Fri Sep 30 12:03:07 2016 VERIFY OK: depth=1, <redacted>
Fri Sep 30 12:03:07 2016 VERIFY OK: nsCertType=SERVER
Fri Sep 30 12:03:07 2016 VERIFY OK: depth=0, <redacted>
Fri Sep 30 12:03:08 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 30 12:03:08 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 30 12:03:08 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 30 12:03:08 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 30 12:03:08 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Fri Sep 30 12:03:08 2016 [server] Peer Connection Initiated with [AF_INET]NNN.NNN.NNN.NNN:NNNN
Fri Sep 30 12:03:10 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Sep 30 12:03:10 2016 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120'
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: route options modified
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 30 12:03:10 2016 ROUTE default_gateway=10.1.10.1
Fri Sep 30 12:03:10 2016 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Fri Sep 30 12:03:10 2016 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.0.1
Fri Sep 30 12:03:10 2016 TUN/TAP device tun1 opened
Fri Sep 30 12:03:10 2016 TUN/TAP TX queue length set to 100
Fri Sep 30 12:03:10 2016 GID set to nogroup
Fri Sep 30 12:03:10 2016 UID set to nobody
Fri Sep 30 12:03:10 2016 Initialization Sequence Completed

server

port NNNN
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS NNN.NN.NNN.NNN"
push "dhcp-option DNS NNN.NN.NNN.NNN"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
hand-window 120

client

client
dev tun
proto udp
remote XXXXX.XXXXX.xxx NNNN
resolve-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3

It shouldn't be required, but I suggest adding topology subnet on the server.

The subnet topology is generally a better option for newer clients. When you use the topology subnet it will automatically perform a push "route-gateway 10.8.0.1" to send a correct gateway to the client.

There are currently 62 connected clients. That alone sounds promising. Can you point me to options that increase the max number of hosts?

Ah there is your explanation. Your server 10.8.0.0 255.255.255.0 option with the default net30 topology allocates a /30 network from that pool 10.8.0.0/24 per system. So 10.8.0.0/30 goes to the server, 10.8.0.4/30 goes to the first client, 10.8.0.8/30 goes to the second client, and so on up to 10.8.0.252/30 to the last client.

You have two options to fix this, you can change your subnet size in the server statement, and make your subnet larger. This may mean you need to update any routing tables on other devices in your network, and change firewall rules.

Or the probably easier solution is to switch to the topology subnet. This makes your not use this psuedo point-to-point topology and makes it basically act like an ethernet switch. Each host in a subnet topology uses one, and only one of the ~253 connected clients instead of the (256/4-1) connected clients. The only reason should stick with the older topology is if you have really old clients connecting.