I can speak to WG or OpenVPN (road warrior/remote-access/inbound type configs). The same applies for a guest wifi network on a dumb AP (link). I think that this would apply to ZT, but I don't have experience with it, so please take my statements with a grain of salt in the event that this isn't applicable to ZT.
A dumb AP can be viewed in the context of 'just another device on the lan' since it has an address on the lan and doesn't do any routing. When you add a routed protocol such as WG or OpenVPN onto a dumb AP, there are two ways to ensure that the traffic is routed properly:
- Setup a static route on the router so that the router knows what gateway to use to route traffic that should go back to the tunnel's subnet (this can actually be done at the host level, but that is typically not the best option; depends on the situation).
- enable masquerading on the lan firewall zone (as described earlier) so that the traffic appears to originate from (and should be returned to) the dumb AP device that is actually running the VPN.
Let's say that we have a lan of 192.168.1.0/24, a dumb AP on say 192.168.1.2, and a WG or OpenVPN subnet of 192.168.9.0/24 (setup on the dumb AP). We'll also assume (in the case of WG/OpenVPN) that the main router is port-forwarding the listen port to the dumb AP at 192.168.1.2.
We can make a connection to the VPN server from outside, and our remote device/peer/client will have an address on the tunnel subnet (192.168.9.0/24). Now, the dumb AP has traffic with source address 192.168.9.x that is destined for hosts on the lan (192.168.1.0/24) and/or the internet.
The traffic can egress the dumb AP and then there will be packets with the source address in the .9.0/24 subnet. A host on the lan may get that packet, but now it doesn't know how to send a reply -- yes, it'll set a destination address matching earlier the source address, but then it is sent to the main router because the host doesn't know what gateway to use for the 9.0/24 subnet.
The main router also doesn't know where to send the traffic, so option 1 is that we set up a static route that is
192.168.9.0/24 via 192.168.1.2 (i.e. 192.168.1.2 exists on the network you know about -- send all traffic that is destined for the .9.0/24 network to that .1.2 and it will take care of the rest.
Or, alternatively, we enable masquerading on the lan firewall zone of the dumb AP. When masquerading is enabled, all traffic is routed and the source address upon egress form the dumb AP (towards the lan/main router) is modified to be itself (192.168.1.2). At this point, all of the hosts and the main router itself on the upstream network (lan) are unaware of the .9.0/24 network, but they see a source address of 192.168.1.2, so they know to send all replies back to that same address (it's on the same network so it's just L2, no gateways/routing involved). When the traffic returns to the dumb AP, it routes back to the VPN tunnel as appropriate based on the principle of NAT masquerading.
Does that help explain it?