Thanks for pointing me into that direction. I've tested it again and strangely, this time the DNS resolving worked via the VPN route, although I didn't change the DNS settings (still manually pointed to three different ones in the regular internet connection GUI setup).
Adding the up/down commands in the ovpn config file doesn't seem to work, however I discovered that the voxel firmware already comes with such scripts under /etc/openvpn
So added the following lines to the ovpnclient-up.sh there and this works, also after a reboot:
ip route add 0.0.0.0/0 dev tun21 table 30
ip rule add from 192.168.1.128/25 table 30
Major issues with that setup: Although clients which for instance get assigned addresses 192.168.1.129 and up through the guest wifi SSID run fine via the VPN, they could easily get assigned different ones manually of course as mentioned before. So not really safe yet to run an unencrypted guest wifi this way.
Even worse, when connected to the guest network, I still see other devices MAC addresses on a LAN scan, so it seems that although ip traffic is filtered on a transparent L3 kinda level, it still mirrors the broadcasting stuff between the networks. However, there I am not knowledgable enough yet when in comes to ebtables' functions so maybe someone can shed some light into how well the Netgear guys implemented this. At least they set the following on the LBR20 by default:
root@LBR20:/etc/openvpn# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 4, policy: ACCEPT
-p IPv6 --ip6-proto ipv6-icmp --ip6-icmp-type ! echo-request -j ACCEPT
-i ath02 -j GUEST_IN
-i ath12 -j GUEST_IN
-i ath21 -j GUEST_IN
Bridge chain: FORWARD, entries: 10, policy: ACCEPT
-i ath02 -j GUEST_FWD_IN
-o ath02 -j GUEST_FWD_OUT
-i ath12 -j GUEST_FWD_IN
-o ath12 -j GUEST_FWD_OUT
-i ath21 -j GUEST_FWD_IN
-o ath21 -j GUEST_FWD_OUT
-d BGA -i ath01 -j DROP
-d BGA -o ath01 -j DROP
-d BGA -i ath11 -j DROP
-d BGA -o ath11 -j DROP
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Bridge chain: GUEST_IN, entries: 11, policy: RETURN
-p ARP -j ACCEPT
-p 0x8035 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-sport 53 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-dport 53 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-dport 546:547 -j ACCEPT
-p IPv4 --ip-proto udp --ip-sport 53 -j ACCEPT
-p IPv4 --ip-proto udp --ip-dport 53 -j ACCEPT
-p IPv4 --ip-proto udp --ip-dport 67:68 -j ACCEPT
-p IPv4 --ip-dst 192.168.1.0/24 -j DROP
-p IPv6 --ip6-dst fe80::/ffff:ffff:ffff:ffff:: -j DROP
-p IPv6 --ip6-dst 2a02
410:6041::/ffff:ffff:ffff:ffff:: -j DROP
Bridge chain: GUEST_FWD_IN, entries: 15, policy: RETURN
-p ARP -j ACCEPT
-p 0x8035 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-sport 53 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-dport 53 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-dport 546:547 -j ACCEPT
-p IPv4 --ip-proto udp --ip-sport 53 -j ACCEPT
-p IPv4 --ip-proto udp --ip-dport 53 -j ACCEPT
-p IPv4 --ip-proto udp --ip-dport 67:68 -j ACCEPT
-p IPv4 --ip-dst 192.168.1.0/24 -j DROP
-p IPv6 --ip6-dst fe80::/ffff:ffff:ffff:ffff:: -j DROP
-p IPv6 --ip6-dst 2a02
410:6041::/ffff:ffff:ffff:ffff:: -j DROP
-p IPv4 --ip-dst 224.0.0.0/4 -j DROP
-p IPv4 --ip-dst 255.255.255.255 -j DROP
-p IPv6 --ip6-dst ff00::/ff00:: -j DROP
-d Multicast -j DROP
Bridge chain: GUEST_FWD_OUT, entries: 15, policy: RETURN
-p ARP -j ACCEPT
-p 0x8035 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-sport 53 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-dport 53 -j ACCEPT
-p IPv6 --ip6-proto udp --ip6-dport 546:547 -j ACCEPT
-p IPv4 --ip-proto udp --ip-sport 53 -j ACCEPT
-p IPv4 --ip-proto udp --ip-dport 53 -j ACCEPT
-p IPv4 --ip-proto udp --ip-dport 67:68 -j ACCEPT
-p IPv4 --ip-src 192.168.1.0/24 -j DROP
-p IPv6 --ip6-dst fe80::/ffff:ffff:ffff:ffff:: -j DROP
-p IPv6 --ip6-dst 2a02
410:6041::/ffff:ffff:ffff:ffff:: -j DROP
-p IPv4 --ip-dst 224.0.0.0/4 -j DROP
-p IPv4 --ip-dst 255.255.255.255 -j DROP
-p IPv6 --ip6-dst ff00::/ff00:: -j DROP
-d Multicast -j DROP