Well, ifconfig tun0 showed this:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::feaa:14ff:fece:8fa5%tun0 prefixlen 64 scopeid 0x3
inet 192.168.9.55 --> 192.168.9.49 netmask 0xfffffff0
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun
Opened by PID 40236
Routes added were this:
192.168.0.0/19 192.168.9.49 UGS tun0
192.168.9.48/28 192.168.9.55 UGS lo0
192.168.9.49 link#3 UH tun0
192.168.9.55 link#3 UHS lo0
192.168.32.0/21 192.168.9.49 UGS tun0
192.168.96.0/19 192.168.9.49 UGS tun0
192.168.128.0/22 192.168.9.49 UGS tun0
At that point pinging 192.168.8.62 which is a machine on the far end of the tunnel did not work. I'd get the sendto: can't assign request address error message.
I deleted the 192.168.0.0/19 192.168.9.49 route, and did the following route add:
route add 192.168.0.0/19 192.168.9.55 -ifp tun0
and I could access the far end of the tunnel. The fundamental difference between the 2 different 192.168.0.0/19 routes? The gateway address.
OpenVPN client log shows that the original route 192.168.0.0/16 gw 192.168.9.49 was the one clearly added, but it did not work. The server side did not change, the client config did not change, the biggest difference between working and not was change from FreeBSD 10.3 kernel to FreeBSD12-Current kernel.
I'm not really requesting help, thanks for that link, just pointing out an issue I had, what I did to correct it, in case someone else is having similar issues. Doing the old Google thing, the closest I came to "the same thing" was a few posts about topology configuration, which indicated possibly getting fixed in 2.3.14.
