Something must be different in your configuration then is the AC56U doesn't have that problem, as the code is totally identical for all models, and also I've been unable to reproduce the issue here. For me, all my tunnels are started sequentially, one after the other when I set two of them to start at boot time. I could always introduce an additional delay before launching each instance, maybe one of your instances is taking a long time to complete its connection, but no guarantee that would help.
This is my Firewall-start script:
#!/bin/sh
# Run Win10_Tracking_Blocker
/jffs/scripts/windows-10-tracking-blocker.sh
# Run block Tor and Countries
/jffs/scripts/block-tor-and-countries.sh
# Load IPSET filter rules
/jffs/scripts/malware-filter.sh
/jffs/scripts/privacy-filter.sh
/jffs/scripts/ipset_block.sh init nolog
and this is my service-start script:
#!/bin/sh
# Set Cron jobs
/usr/sbin/cru a StrongDNS "*/10 * * * * /jffs/scripts/StrongDNS.sh" # Updates public IP address with smart DNS provider
/usr/sbin/cru a malware-filter "0 */12 * * * /jffs/scripts/malware-filter.sh"
/usr/sbin/cru a privacy-filter "0 */12 * * * /jffs/scripts/privacy-filter"
/usr/sbin/cru a IPSET_SAVE "0 * * * * /jffs/scripts/ipset_block.sh save" #Every hour
/usr/sbin/cru a IPSET_BACKUP "0 5 * * * /jffs/scripts/ipset_block.sh backup" #05:00 every day
Then that would mean that provider fails to push a default gateway, and rely entirely on that blanker route to handle traffic. From a network point of view it's not exactly a good idea, but not much you could do about it if that's the case.
Both VPN servers push their own DNS servers:
May 2 19:24:06 openvpn[1218]: PUSH: Received control message: 'PUSH_REPLY,route xxx.xxx.xxx.xxx 255.255.255.0,redirect-gateway def1 bypass-dhcp,dhcp-option DNS xxx.xxx.xxx.xxx,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.10 10.8.0.9,peer-id 0,cipher AES-256-GCM'
( I do manage this VPN server remotely)
May 2 19:25:05 openvpn[12744]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS xxx.xxx.xxx.xxx,dhcp-option DNS xxx.xxx.xxx.xxx,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 30,ifconfig 10.4.0.166 255.255.255.0'
(This is a VPN service provider)
Strict mode shouldn't affect performance, in fact if there is any difference it should be a few microseconds faster, as there are fewer routes to process than in regular mode.
Sorry, I take my previous comment back, further testing showed similar throughput as with regular mode.
Will run some more tests this coming weekend and try to ping-point what is causing the VPN clients routing conflicts.