I used two pools with two DHCP servers before and they could communicate by default, so I had to drop connections with a firewall rule, but here I can’t get the devices from the 192.168.87.0/24 to communicate with the devices from the 192.168.88.0/24 subnet.
It depends on what is in LAN and WAN interface lists…
You also made some changes (like changing !LAN into WAN) that could have effect.
You also need to check if the routing table is OK on your client devices (is there a route that sends 192.168.88.0/24 traffic to the VPN).
Aren’t traffic, which is coming from the VPN clients, picked by these rules? Technically, connections are coming from WAN interfaces.
/ip firewall filter add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=WAN
/ip firewall filter add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
Not sure about OpenVPN, but for IPSEC one must exclude such traffic from fasttrack in order to avoid issues. Same applies to main NAT rule.
First thing to try would be to add simple filter that allows from to networks and vice versa above all other rules.
With limited info available, it seems you are confusing VPN server between “Routed” and “Bridged”
As a start, for routed, remove below and test: /ppp profile
add bridge=bridge local-address=192.168.87.1 name=OpenVPN remote-address=OpenVPN-Pool use-encryption=required
I have disabled all of the rules and I devices still can’t communicate. Anyway, like I said, if I use the default pool in the VPN profile, everything works fine, so it can’t be a WAN > LAN issue.
If I remove bridge=bridge from the profile, I lose communication between devices even while using the same pool (local devices and devices connected through the VPN).