How do you make all traffic pass through the VPN?

[StygianAgenda]

PRIVATE LAN: 192.168.1.0/24
VPN LAN: 10.8.0.0/24

HOTSPOT LAN: 192.168.1.0/24

Your private LAN is conflicting with your Hotspot LAN and so routing is broken.

Change your private LAN to something else .. like 192.168.137.0/24

This is correct.
Another example would be, for instance:

Private LAN: 192.168.1.0/24
HotSpot LAN: 192.168.2.0/24

IPv4 Local Networks: 192.168.1.0/24,192.168.2.0/24

VPN LAN: 192.168.3.0/24 (IPv4 Tunnel Network)

Make sure to add route-statements for each of the internal networks. In my first example, I do not segment my Wifi traffic from my internal ethernet traffic, so they are on the same subnet.

If you're going to have a separate subnet for your HotSpot, and you want to be able to route traffic from VPN clients to that subnet, then you'll need a route statement for it, as in the example above, "IPv4 Local Networks". This statement is what tells the VPN server which subnets are to be statically routed.

"Traffic" is correct in his statement that your private LAN and HotSpot LAN are conflicting, at least if those two LANs are not physically connected via a router in between. Routers cannot generally split parts of the subnet into different physical locations, unless the router is configured to use a smaller CIDR. To get an idea of how to calculate the subnet configuration, use a tool like SolarWinds Subnet Calculator (it's great, and I use it professionally), which will allow you to carve up subnets however you see fit within the logic of the IPv4 addressing scheme.

A good example of how that could work, using 26bit subnets (as opposed to 24bit)
---
Ethernet-Client-LAN: 192.168.1.0/26 (192.168.1.1~192.168.1.62)
[network address: 192.168.1.0; mask: 255.255.255.192; broadcast: 192.168.1.63]
---
Wifi/HotSpot-Client-LAN: 192.168.1.64/26 (192.168.1.65~192.168.1.126)
[network address: 192.168.1.64; mask: 255.255.255.192; broadcast: 192.168.1.127]
---
VPN-Client-LAN: 192.168.1.128/26 (192.168.1.129~192.168.1.190)
[network address: 192.168.1.128; mask: 255.255.255.192; broadcast: 192.168.1.191]
---
Nino: As you can see by this example, the subnet mask is what shrinks the subnet down to a smaller size so that a smaller number of IP addresses can be divided in a way that creates 3 separate subnets, each with 62 usable IP addresses. The critical thing to notice here is that all traffic is segmented properly. Now, we use static route statements to bridge those subnets. Your edge-router and any internal routers may also need statements to instruct them to look on the local wire for any segments that are local to the wire, and to look to the VPN server for any routes contained only there. For instance, I can add my VPN subnet as a static route, using the Router's internal IP address as the gateway to that route, and this will allow my internal clients to connect directly to a VPN client that is already connected to the VPN server. It all comes down to proper traffic routing though.

Beyond what I've presented here, it would be hard to say what the problem is, because if your routing is configured correctly, then there shouldn't be an issue with IOS provided that the IOS client functions correctly. IOS should handle routing statements during dynamic socket negotiation no different than any other networked OS, but that's not to say that IOS conforms 100% to RFC standards for TCP/IPv4... it should, but I don't have enough information to make that assessment.

[StygianAgenda]

I appreciate what your saying but why does it work on PC/Android/OSX but not on iOS.

I don't have an answer to that question, because as I've previously stated, I don't use IOS.
But, it stands to reason that *provided there is not a malfunction otherwise*, then the IOS client should function based on whatever instructions it is fed from the 'ovpn' file. You might try inspecting that file in a text editor, side-by-side with an ovpn file made for Android to determine if there's a difference in the settings internally, but outside of that I would have to refer you to someone else for assistance beyond anything I've posted here.

[Traffic]

Perhaps the Hotspot you have selected is the cause of the problem ..

The other machines are connecting from another source network.

Basically, NEVER use 192.168.0.0 or 192.168.1.0 on your server ..

It is not hard to fix .. So Fix it !

[StygianAgenda]

Perhaps the Hotspot you have selected is the cause of the problem ..

The other machines are connecting from another source network.

Basically, NEVER use 192.168.0.0 or 192.168.1.0 on your server ..

It is not hard to fix .. So Fix it !

More so...
Before building out a VPN server, it helps to take the time to learn networking fundamentals, such as routing, CIDR structure, etc. These are necessary troubleshooting skills that will go a long way toward making things work right the first time you try.

In case Traffic's comment is not clear to you, I think what he's getting at is that it's a bad practice to ever set any system (server, workstation, device, etc) to use the 'zero-ip' within the assigned ranges. Not that it will cause any problems on large subnets, but on smaller subnets, it can cause all kinds of headaches.

[example]
CIDR-Address: 192.168.1.0/24
Network Adress: 192.168.1.0
Subnet Address: 255.255.255.0
usable IP range: 192.168.1.2 through 192.168.1.254
broadcast address: 192.168.1.255
recommended router IP: 192.168.1.1

As you can see in this example, the CIDR describes the network as a whole, including it's network and broadcast addresses. The subnet address works with the IPs to create the CIDR. The network address is used by routers to know how to reach your network. The broadcast address is used by ARP traffic and other multicast traffic to transmit to all systems within the CIDR/Subnet all at once. The usable IP range is what IPs you have left after assigning your CIDR (network address + broadcast-scope = CIDR or subnet size; use SolarWinds subnet calculator for assistance with this, if you need it) and router-IP.

[Traffic]

As you can see in this example, the CIDR describes the network as a whole, including it's network and broadcast addresses. The subnet address works with the IPs to create the CIDR. The network address is used by routers to know how to reach your network. The broadcast address is used by ARP traffic and other multicast traffic to transmit to all systems within the CIDR/Subnet all at once.

OpenVPN does NOT pass ARP packets with --dev tun .. and does NOT route broadcasts with --dev tun ... so ?

I am curios to understand what it is you are trying to explain ...

[StygianAgenda]

As you can see in this example, the CIDR describes the network as a whole, including it's network and broadcast addresses. The subnet address works with the IPs to create the CIDR. The network address is used by routers to know how to reach your network. The broadcast address is used by ARP traffic and other multicast traffic to transmit to all systems within the CIDR/Subnet all at once.

OpenVPN does NOT pass ARP packets with --dev tun .. and does NOT route broadcasts with --dev tun ... so ?

I am curios to understand what it is you are trying to explain ...

OpenVPN may not pass ARP protocol itself, but the server running it does, as does every single network resource running a TCP/IP stack.
As to what ARP has to do with a failure of an IOS client to operate properly... probably nothing. I'd have to guess that you cued in on a word that had little to do with the message as a whole. ARP protocol is simply one aspect of the network that the OpenVPN server must communicate with in order to route traffic. ARP works below DNS, and ARP is used to locate resources when DNS otherwise fails or is not used, such as direct IP communications.

I work in IT, as a network administrator, professionally. My approach to unravelling anomalous network activity, be it a client application or what have you, is to start from determining at what layer of the OSI model the traffic is failing.

My statement was really more intended for the benefit of 'Nino', who stated an improper address schema in his example (see previous posts in context of order). It seemed apparent to me that part of the problem wasn't necessarily the script itself, but the logic (or lack thereof) behind the configuration as a whole, based on a less-than-professional knowledge of networking as a whole.

I'm not sure if my example was unclear... perhaps it's simply outside of your understanding of the context in which it was stated, but regardless, I simply found methods that work for me, and whether anyone takes my advise or not is their own lookout. That said, I've tired of following this conversation, and withdraw my option to continue following it via email.