Well, it's no Wireshark log, but the E1 cameras do not respond to ping or tracert from the main LAN (192.168.1.0/24):

C:Usersfrank>ping 192.168.10.139

Pinging 192.168.10.139 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.10.139:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:Usersfrank>tracert 192.168.10.139

Tracing route to 192.168.10.139 over a maximum of 30 hops

  1     1 ms    <1 ms     2 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.

Other devices on the IoT VLAN reponds as expected.

Thickening of the plot:
Another problem I experience and may play into this as a separate or combined issue, is basic router/DHCP connectivity at times. Sometimes, the E1 cameras have persistent ARP and DNS timeouts, which I can solve be powercycling them (unplug, wait 10 seconds and replug the power cable). I have given the E1s fixed IPs, in order to reduce/eliminate DHCP issues, due to this, which seems to have alleviated some of the problem - some of the time. Unfortunately, not entirely, and this might be another candidate as contributing culprit in the cause of no connectivity across subnets, as only the E1 cameras keep getting DHCPOFFER every 6 minutes, with a a DHCPDISCOVER thrown in every now and then, too (see screen shot).

When the E1s show this behavior, I cannot externally connect to them either. At this stage, it is both across subnets and from the internet side, as well, that the connectivity is nonexistent. But joining the same subnet still gives access to the cameras (Android app), even under these circumstances. No other ARP/DNS timeouts reported for other devices on the IoT VLAN, although some TCP latency every now and then. So, I can't really see it should be a router issue from the Unifi Dream Machine Pro. Something fishy is going on, indeed, but it is across E1s, so I can't see how it should be a malfunctioning camera I have, as the batch of E1s show the same (unwanted) and identical behavior.
DHCP-Reolink-E1.jpeg

I made a firewall rule to log any and all traffic (including ICMP) to the E1 cameras (see screen shot), which is then logged to Papertrail. Then I started pinging the E1s. Nothing in the logs. So even though they seems online in the router, they might be "off" the network, in some way that is beyond me. See screen shot.

The IPs for the E1s are done on the router side by MAC addresses. The E1s do not have a onption for setting a fixed IP, at least to my knowledge and experience with them.
IoT-devices-router-status.jpeg
logging-E1s-console-and-papertrail.jpeg

I am unsure of that, too. Anyway, I decided to bite the bullet and crawled into the low-height attic to connect an E1 by wire, to eliminate potential issues. I can cross VLANs when the camera has hardwired IP (by RJ45). So, it seems the connectivity issue is with E1s and wifi. When the same E1 is connected to the same IoT VLAN by cable, it acts as any other IoT device I have (although, they are all connected by wifi). That rules out the Unifi Dream Machine Pro, at least. And leaves the AC Lite and the E1s as the potential troublemakers, it seems.
attic-crawl-back-pain-legs-burning.jpg

I am unsure of that, too. Anyway, I decided to bite the bullet and crawled into the low-height attic to connect an E1 by wire, to eliminate potential issues. I can cross VLANs when the camera has hardwired IP (by RJ45). So, it seems the connectivity issue is with E1s and wifi. When the same E1 is connected to the same IoT VLAN by cable, it acts as any other IoT device I have (although, they are all connected by wifi). That rules out the Unifi Dream Machine Pro, at least. And leaves the AC Lite and the E1s as the potential troublemakers, it seems.
attic-crawl-back-pain-legs-burning.jpg

I made a firewall rule to log any and all traffic (including ICMP) to the E1 cameras (see screen shot), which is then logged to Papertrail. Then I started pinging the E1s. Nothing in the logs. So even though they seems online in the router, they might be "off" the network, in some way that is beyond me. See screen shot.

The IPs for the E1s are done on the router side by MAC addresses. The E1s do not have a onption for setting a fixed IP, at least to my knowledge and experience with them.
IoT-devices-router-status.jpeg
logging-E1s-console-and-papertrail.jpeg

Well, it's no Wireshark log, but the E1 cameras do not respond to ping or tracert from the main LAN (192.168.1.0/24):

C:Usersfrank>ping 192.168.10.139

Pinging 192.168.10.139 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.10.139:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:Usersfrank>tracert 192.168.10.139

Tracing route to 192.168.10.139 over a maximum of 30 hops

  1     1 ms    <1 ms     2 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.

Other devices on the IoT VLAN reponds as expected.

Thickening of the plot:
Another problem I experience and may play into this as a separate or combined issue, is basic router/DHCP connectivity at times. Sometimes, the E1 cameras have persistent ARP and DNS timeouts, which I can solve be powercycling them (unplug, wait 10 seconds and replug the power cable). I have given the E1s fixed IPs, in order to reduce/eliminate DHCP issues, due to this, which seems to have alleviated some of the problem - some of the time. Unfortunately, not entirely, and this might be another candidate as contributing culprit in the cause of no connectivity across subnets, as only the E1 cameras keep getting DHCPOFFER every 6 minutes, with a a DHCPDISCOVER thrown in every now and then, too (see screen shot).

When the E1s show this behavior, I cannot externally connect to them either. At this stage, it is both across subnets and from the internet side, as well, that the connectivity is nonexistent. But joining the same subnet still gives access to the cameras (Android app), even under these circumstances. No other ARP/DNS timeouts reported for other devices on the IoT VLAN, although some TCP latency every now and then. So, I can't really see it should be a router issue from the Unifi Dream Machine Pro. Something fishy is going on, indeed, but it is across E1s, so I can't see how it should be a malfunctioning camera I have, as the batch of E1s show the same (unwanted) and identical behavior.
DHCP-Reolink-E1.jpeg

Also, here is the tracert:

C:Usersfrank>tracert 192.168.10.80

Tracing route to Chromecast.iot [192.168.10.80]
over a maximum of 30 hops:

  1     1 ms     2 ms     1 ms  unifi.localdomain [192.168.1.1]
  2     2 ms     1 ms     1 ms  Chromecast.iot [192.168.10.80]

Trace complete.

tracert-LAN-to-VLAN.jpeg

That is exactly right. I have attached a screenshot of my PC (192.168.1.18) pinging the Chromecast (192.168.10.80) with connectivity and success.
inter-vlan-ping.jpeg

Sure. Examples are Chromecast and Chromecast audio devices, which are on the same VLAN (192.168.10.0/24) as the Reolink E1 cameras. When I try to connect from the main LAN (192.168.1.0/24), there is no issue with the Chromecasts or other devices on the IoT VLAN. Multicast has not been enabled, by the way. Another examples would be Android TV boxes, which also reside in the IoT LAN. Again, the firewall rules are factory reset.

Same here. I have six E1 cameras (non-pro) and they can't traverse VLANs/subnets and hence can't be put on a restricted subnet to be accessed from my trusted devices on a different subnet.

Really looking forward to a firmware upgrade as this is unusable in my scenario and quite peculiar and unexpected for an IoT manufacturer to push out such a "feature".

All other IoT devices are easily accessible on the same subnet as the E1s, but even setting an explicit allow firewall rule on my unify dream machine for accessing the E1s fails in delivering successful connections from other subnets or even pings to the E1s. It works when on the same subnet, of course, and from the internet/cloud side on Android app. But not from another subnet.

Strange, unexpected and undesired behavior, in my case.

Which had me factory reset my router several times, as I thought it was a router or firewall issue, initially. Only to discover it is an issue with the Reolink cameras I bought.