And what did you expect? You have the default route through 192.168.5.1. The 192.168.5.0/24 route is automatically added when the interface starts.
The vpn routes are different because for some reason you use tun interface that works a bit differently. I suggest using tap, that is a "standard" network interface (but doesnt work in Android clients).

1 members found this post helpful.

I expected that when a request comes in to the VPN box for an IP in the 192.168.5.x range, it would go to 192.168.5.1, the default route. That does not appear to be happening because of that bizarre last entry.

The main client that connects is android, so tap will not work. Can I add a route just for VPN? If so, what should it look like?

There is no rule to add other than 192.168.5.0/24 via the vpn gateway on the vpn clients.
But as i said before, use masquerade - it works better for vpn->lan access.

1 members found this post helpful.

If you don't choose to follow the NAT alternative, then, yes, there must either be a routing rule on the VPN clients, or a static route in the router that all of them share.

Traffic sent from a directly-connected VPN user will probably have a "10.8.x.x" IP address (as specified in the VPN config), and traffic passing through a gateway will instead have the address of the remote subnet.

In any case, TCP/IP routing must be round trip. The computers to whom traffic is being sent must have routing (one way or the other) that sends the replies (and connections going the other way ...) back to the appropriate OpenVPN gateway for final delivery. You must have routing for the entire Hobbit's Journey: "There And Back Again."

If you don't have that, it'll be sent to that machine's "default gateway," e.g. on the Internet, which will immediately drop any packet, such as these, which bears a "non-routable" IP address.

Of course, routing in the case of OpenVPN must concern not only the virtual connections that pass through the tunnel, but the physical routing of (encrypted) packets among the OpenVPN gateways themselves.

traceroute is your friend . . . So's a big piece of paper and a number-two pencil to draw it all out ... both "as it should be" and "as it now (incorrectly) is" ... in a big picture.

1 members found this post helpful.

Thanks. I was quite confused by the responses because I had the nat set up through the iptables command on the first page,and had a static route set in the router, which should have been enough for the round-trip. It appears that after a server reboot, I needed to re-run the iptables command, which is what was causing the grief. All good again.