Okay, so I have no idea why I never thought to run tcpdump, but you nailed part of the diagnosis, which puts me at ease.  With route-nopull, I can see packets to-and-from my mobile device, but it doesn't use tunY.

On the other hand, with route-nopull disabled, I saw the packets trying to reach ethX, but as you said, no replies.  And I've gotta be totally honest with you, but I have no idea what that means.

Again, in all honesty, I'm not sure.  What would be the best way to check?

Miyo has clearly never ran a search containing only the string "miyo"

http://lmgtfy.com/?q=miyo

That's the idea.  It works okay from the box, and from devices connected to its hotspot.  Also, when I'm on the box's hotspot, I can connect through openvpn, and everything works as normal.

It's only when I'm outside the lan that I have any issues.  My conjecture is it has something to do with the outside VPN service changing the box's public IP -- it overrides the ISP public IP.  Yet, my client.ovpn is set to reach out to the ISP's public ip, and as I mentioned, it works okay on the LAN, just not outside of it.  That's weird to me.  (Edit: this behaviour changes when route-nopull is used; see below.)

Why wouldn't it be?  All routing information was taken off.  I'm assuming that the external VPN service I'm using pulls everything by default. 

Yeah, that's the idea.  I want the box to be a middle-man for filtering and monitoring network traffic.  Otherwise, I would connect directly to the external VPN service. 

The problem is that, anytime it's running, I lose VPN access to tunX from outside the network.  (Inside the local network, though, it's okay.)

This is the behavior when route-nopull is used.  (If you want, I can post route -n so you can see the full table.)  The issue is that when this happens, it seems like nothing at all is routed through tunY: browserleaks.com/ip reveals my ISP public IP, not the VPN service's (xx.xx.xxx.xx from my previous post). 

Interestingly, when route-nopull is used, my devices outside of the local network can connect to the box.  It's just that, as I said, when it's used, it seems like nothing at all is going over tunY.

My conjecture is that my external VPN service pulls all routes by default.  I want to use tunY to access websites.  The problem is that when it's running, I can't access the box from outside the LAN.

Thanks for the responses so far.  I've been researching routing with openvpn, to little avail.

One issue that I'm noticing is that openvpn seems to ignore routing information.  For example, based on this post, I added this line to my external client's (which creates tunY) .ovpn file:

route 192.168.0.0 255.255.0.0 net_gateway
redirect-gateway def1

According to the posts, this should exclude any devices on any 192.168.(...) networks from being routed through the vpn.  In fact, it does not.

My personal favorite so far is this one:

Seems simple enough, so I also modified the route to 192.168.0.0 255.255.0.0, in hopes to exclude that IP range.
Despite the enthusiastic accolades in the topics comments, the same results occur: all network traffic is routed over the VPN.

I'm having the exact opposite problem when using the route-nopull option, coupled with custom route or push "route options.

In this context, I'm not completely sure what this would look like.

Correct, that's been the deal since I first set up the "original" vpn (connect to box from wherever).  My iptables rules for that are as follows:

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.y.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.y.0/24 -o ethX -j MASQUERADE

No idea.  I've restarted both client and server to no avail.

I'm half sure that I understand this question, so I'll try my best...
Devuan unstable (aka Debian's sid) is called ceres.  If you want to use that, update your sources.list

If you're asking to use sid within a devuan system, try a chroot or virtual machindm

Where will you be when Microsoft starts charging for github service?

I just need to sit down and invest four brain cells into an automated way to download the logs, so I can keep up to date with the conversations.  I always seem to dip-in during dead hours

Do you know if there's a better way to prevent them from showing up?

Makes sense.  It isn't my primary system, so I'm not upset, but it is a little weird.

This seems awfully familiar...oh, right.

Archers have always had a tendency to go with the flow and whatever performs best; their culture is a nonsequitur because their goals are oriented with that mindset.  Debian users' attitudes towards systemd range between apathetic and complicit, and there's a good reason: most of the professionals have fled to other projects, including Devuan.  Debian's implementation of systemd is fine, and I recommend dropping by their community to test your beliefs about systemd, otherwise I'm going to [continue to] assume that you're just trolling ours. 

As far as this community is concerned, it's more about maintaining software choice, even if that choice means a derivative of the mothership.  Systemd is already a hard dependency in many programs, and that trend will probably continue if no one does anything about it.  If intrusive software is properly configured, it's still intrusive software.

Since we're on nonsequiturs, I'd like to announce that I baked potatoes in the oven for the first time ever.  They were delicious.

I believe you.  I'm just trying to figure out how this user pulled that off -- especially since he/she has yet to reply.