The easiest solution is to physically link the two DDWRT switches into one network.
Your diagram implies the two routers go into the same switching fabric? If the direct connection is in the realm of possibility do it, get a straight Ethernet link plumbed the same way between the two routers. Otherwise you may be able to get a VLAN setup on the external switches and two ports for your connection.
Another way is to create a wireless repeating bridge between your two routers if a WAN connection is possible and bandwidth requirements allow it.
These 3 bridge options will give you one big network, and you'll need to do extra work with your clients or DHCP server to meet your requirement of keeping internet traffic on the local router.
If you can't create the physical connection between the two networks you will need to use an IP tunnel to either bridge the networks or route the data. You could create the built in OpenVPN tunnel between the DDWRT boxes via the external interfaces:
INTERNET--------
|
|
[Gigabit Switch]
| |
[DD-WRT A]-- tun --[DD-WRT B]
| |
[LAN A] [LAN B]
[192.168.11.0/24] [192.168.12.0/24]
DDWRT doesn't come with GUI options to push LAN traffic out the OpenVPN/PPTP tunnels so will need some manual tinkering (tomato does have the option via the GUI). If you can manually add the tun0 interface's on each DDWRT to the devices bridge, then broadcast data will be pushed over the tunnel to either side of the network.
Failing the bridge, you could try using pimd to route the data via the VPN tunnel. This has the benefit of not bridging the networks.
Another way might be using mrouted on the two dd-wrt boxes via the unicast static routing you setup, although it seems a bit dead development wise. If it does compile/work on linux still, it will allow you to route multicast data from each network via a TCP tunnel to the other network and vice versa which should work via the static routing without a tunnerl.
In any case, I think bridging is the only one I would attempt (unless you want to learn a lot about upnp and multicast). There's probably more than a couple of gotcha's with a protocol designed for a single home network.
For ASUS routers your safest approach is to use ASUSwrt-merlin. Your device appears to be supported. The official site of Asus-merlin is here.
For your ASUS model some information can be found @Karim Elatov's github page (note: the information is from 2014) - the page is here
The general information on DD-WRT:
You can find out your newest already compiled version via google doing search:
RT-AC68U site:https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/
Which would lead you to (as of 19.3.2018):
https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2017/12-04-2017-r33986/asus-rt-ac68u/
To quote the firmware wiki
DO NOT USE THE ROUTER DATABASE (router database): unless directed
in a device wiki.
It does NOT have Recommended Builds, and the firmware build dates are not correct.
What I'm suggesting next is rather difficult so you need to have some reasonable technical skills.
1) First an easier approach - firmware-mod-kit
You can deconstruct (decompile) your old firmware which you know it is working and see what has changed in the new firmware. The firmware-mod-kit wiki is rather informative about it. I would try to compare everything step-by-step. If you find out what has changed then you can repack it too.
2) When firmware-mod-kit fails you need to some reverse-engineering yourself
Please see this guide or this guide for firmware unpacking and packing. Both are rather long so I'm not copying the information here. If you would like to tell me in comment.
3) Build the DD-WRT yourself from source, which is rather hard to do. Which even the developers admit it is hard:
To quote development wiki:
Building DD-WRT from source is difficult and according to the text
here definitly not working on first try. You will see lots of strange
errors and many confusing install-scripts. The forum is full of people
who were not able to make this install-procedure running through. The
infos in the forum is much newer than these here, but also very
confusing and mixed up.
Brainslayer does not have the time to do everything. Until the day
comes that DD-WRT will build without any extra steps, I've written
some scripts that will set up a build environment for DD-WRT. Newer
builds of DD-WRT may break compatibility with these scripts. If this
happens and I don't update them, please take the time to update them
if you are sure your changes are appropriate.
So be sure to follow the directions here and if you are in luck then you will get your own version of DD-WRT.
To answer your question:
There is no definitive source of information for DD-WRT. You have to search for the pieces and glue them together. The worst part is that some information is invalid or incorrect, which you have to filter out.
If you are stuck the best way forward is to ask at the DD-WRT forum.
Best Answer
Yes, I have an identical problem, and for exactly the same reason, lol. It would be much easier to use two routers, but alas, here we go.
Create a virtual interface of type macvlan on eth0, the gateway to the internet of your router.
Configure your OpenVPN client configuration to use the route-noexec option in the client.conf. According to the manual,
Setup a table for routing, which you will configure just like your OpenVPN would have configured it, except that you use the macvlan interface instead of eth0.
Configure the default routing table just like you would if there were no OpenVPN.
Setup the rules for choosing the routing table so that some pcs with fixed IPs use the routing table with OpenVPN, while the unspecified pc uses the default routing table.
You will have to use a macvlan virtual interface which is nothing but another address for your WAN interface, except it is endowed with a (fake) MAC address so that all traffic, including ARP, can be separated between eth0 and macvlan.
You can find a good intro to macvlans here, while in this OpenVPN forum post, which deals with a problem identical to yours, they suggest a good link, here, explaining source based routing.