[solved][TomatoUSB] DNS broken for 2nd OpenVPN client?

[guppy 10]

My setup is this;
 
Asus RT-N66U "Black knigth" running the shibby AIO version of TomatoUSB
 
I've set up the 1st OpenVPN client (tun11) and am forcing all traffic from a specific (internal) IP though this connection.
 
 
The above works really well so I wanted to setup up a wireless network were all clients that connects are added to a different subnet and all IPs in that subnet be forced through the 2nd OpenVPN client ( tun12 ).
 
To this end I setup;
 
- a new VLAN (br1)
- a new Wireless SSID ( wl0.1 ) that is using that VLAN
 
This works and clients can connect, get the correct IP and can access the net.
 
I copied every setting from tun11 to tun12
 
I can connect the 2nd OpenVPN.
 
When I start the scripts to force the subnet though the tunnel I get various DNS related errors in the client ( Android 5.1.1 with chrome browser ) unless I stick to refreshing an already loaded page, 
the page will show the correct vpn IP however ( simple php page with 

<?=$_SERVER['HTTP_X_FORWARDED_FOR'];?> 

)
 
It seems that somehow DNS isn't working for the 2nd connection, and I can't for the life of me figure out why. 
 
Trouble shooting I've done so far;
 
Shutdown both VPNs and only start Client2 - no difference
Routing br1 through Client1 works perfectly ( "ip rule add from 192.168.2.0/24 lookup 200" )
 
So I'm starting to think that there is something wrong with my settings for Client2;
 
The relevant settings ( minus the VPN ip's as they are irrelevant ) - what am I missing / where did I screw up?

Client 1



 
Client 2



 
Script -> firewall ( custom addition to the firewall rules )

 

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE


iptables -I FORWARD -i br1 -o tun12 -j ACCEPT
iptables -I FORWARD -i tun12 -o br1 -j ACCEPT
iptables -I INPUT -i tun12 -j REJECT
iptables -t nat -A POSTROUTING -o tun12 -j MASQUERADE
 

 
the up/down scripts that takes care of the routing
 

root@unknown:/tmp/home/root# cat /jffs/vpn1_up.sh 
#!/bin/sh
#iptables -D OUTPUT -s 192.168.1.203 -j DROP
ip route flush table 200
ip route flush cache
ip rule add from 192.168.1.203 lookup 200
VPN_GW=`ifconfig tun11 | awk '/inet addr/ {split ($2,A,":"); print A[2]}'`
ip route add table 200 default via $VPN_GW dev tun11

root@unknown:/tmp/home/root# cat /jffs/vpn1_down.sh 
#!/bin/sh
#below line doesn't work
#iptables -A OUTPUT -s 192.168.1.203 -j DROP
ip rule del from 192.168.1.203 lookup 200
ip route flush cache


root@unknown:/tmp/home/root# cat /jffs/vpn2_up.sh 
#!/bin/sh
ip route flush table 210
ip route flush cache
ip rule add from 192.168.2.0/24 lookup 210
VPN_GW2=`ifconfig tun12 | awk '/inet addr/ {split ($2,A,":"); print A[2]}'`
ip route add table 210 default via $VPN_GW2 dev tun12

root@unknown:/tmp/home/root# cat /jffs/vpn2_down.sh 
#!/bin/sh
ip rule del from 192.168.2.0/24 lookup 210
ip route flush cache

[go558a83nk 364]

my suggestion is to use merlin asus firmware, policy routing therein, and DNSFiltering to control which DNS is used for which client.

[guppy 10]

my suggestion is to use merlin asus firmware, policy routing therein, and DNSFiltering to control which DNS is used for which client.

 

Concidering just how bothersome the procedure was for getting the current custom firmware on I'll call that plan B, but thank you for your suggestion

[go558a83nk 364]

bothersome?  all you have to do is download a firmware file, upload it to your router, and wait about 3 minutes for the firmware to install.

[guppy 10]

bothersome?  all you have to do is download a firmware file, upload it to your router, and wait about 3 minutes for the firmware to install.

 

Seems we've had quite the different experience here ^^

 

Hitting the TFTP window (I use linux so no fancy client for me) and getting the upload to finish took on average 5 attempts per upload, after that I had to wait ~20m for the leds to ligth up correctly, clear nvram and reboot - which meant another ~30m wait.

 

I had to do this 3 times before It flashed successfully.

 

This not only had my nerves on end for a full 3 hours, but also mean that the household was without internet access for the duration - which did not go over well with the spouse and kids

 

So yeah if nobody can help me fix my current situation I'll try swapping firmware but for now I prefer it If somebody had a solution for the situation at hand 

[go558a83nk 364]

at a loss for words here.

 

TFTP window?  Are you not using the web GUI of the router?  Are you checking the hash of the downloaded firmware to confirm it's correct?

[guppy 10]

 

at a loss for words here.

 

TFTP window?  Are you not using the web GUI of the router?  Are you checking the hash of the downloaded firmware to confirm it's correct?

TFTP is a tiny FTP server that these routers keep in their pre-boot segment it's only active during emergency firmware restore mode.

 

No I am not using the webGUI to upload it - it's my understanding that this wont work if the new firmware has a different partion size than the one your flashing ( as was the case with sock vs tomato )

 

And yes I did check the hash - problem is sometimes the the router continued before the upload was done ( which you cant tell has happened )

 

At any rate there seems to be no gui for policy routing in merlin either? ( feel free to correct me if I am wrong - I just can't seem to find any screenshots or manual ) but I migth be able to adapt this to my setup;

https://github.com/RMerl/asuswrt-merlin/wiki/How-to-Direct-Traffic-over-VPN-and-Drop-connections-if-VPN-goes-down

 

Edit: upon closer reading they seem to do the exact same thing I do but with different commands - no DNS magic anywhere to be found..

[guppy 10]

Adding 192.168.2.79 as an ip alias to my desktop I cant connet to the internet  - tunnel or not, but adding 192.168.1.215 and rerouting that works fine on the second tunnel so the problem seems to be the new vlan

[guppy 10]

Solved it..

 

As it turns out the 'DNS_PROBE_FINISHED_BAD_CONFIG'

 

was caused by routing 192.168.2.1 through tun12

 

I have no idea why there are two ways around it;

 

1) enter every other adress manually

2) cut the addressable space in half and limit dhcp to 192.168.2.128-254 ie 192.168.2.128/25 in place of 192.168.2.0/24