My impression is you do not seem to have followed the dnsmasq part of the instruction to which you linked to the letter, and you could have a possible routing issue too.
What happens if you remove the google dns hardcoding from everywhere except in your ovpn server config? Here is some additional reasoning around dns as per your description and the link you gave:
I recall using resolv.conf with dnsmasq, as I was always on static public addresses with no dynamically assigned dns:es. The instruction in the link seems however to be based on a workaround for picking up dhcp assigned dns addresses. As you are aligning towards the google dns addresses rather than dynamically assigned ones, I would pay particular attention to that part. Make double sure resolution through dnsmasq works before chaining clients through yet another backend dns proxy. If you follow that guide, make sure you understand what each step does, as you may need to change the dnsmasq config procedure a little to get it simple and swinging.
Also, as the solution is explicitly designed around the dnsmasq picking up all dns queries and forwarding them, your hard coding the google dns addresses as primary and secondary resolvers with the dnsmasq address as tertiary resolver in the ovpn server config (I assume you are doing the same everywhere possible as you are writing that you have hard coded even at the clients), a double dns timeout could be expected before resolution is done through dnsmasq when you connect through the vpn.
This is of course not optimal, you should remove references to google dns except as specified for external resolver config in the dnsmasq guide for the ovpn server. When you have it working you could add the google dns addresses in your dns clients of your client machines again. They should then be temporarily replaced with the ones from openvpn as you connect.
Further, consider the possibility that the dlink router does not accept three dns server addresses in its dynamic dns client, consider as well the possibility of conflict between hard coding the addresses and having them dynamically assigned to the dlink at the same time. Perhaps it doesn't handle such a config well? I do not have access to your dlink model and don't really wish to read its documentation, but just indicate some possible error sources.
So I really get the impression you need to simplify the dns part:
- Make sure the ovpn server dnsmasq resolves to google dns and google dns alone.
- Remove references to google dns everywhere except in your dnsmasq server resolv.conf or in its interfaces file as indicated in the guide to which you refer.
- Use your dnsmasq address as dns server address in your dlink dns client, first try hard coding it and if that works try pushing it dynamically from the ovpn server.
- When the above works, at the client try using the dlink or the dnsmasq address depending on your dns proxy toggle in the dlink.
If you have additional networks at your ovpn server beside the path indicated by the default route, and which you depend upon to make the final leg to the internet, you need to push those routes tho the dlink using the 'push "route x.x.x.0 255.255.255.0"' directive. Just to rule that out.
In order for clients on the vpn network to reach each other, use the 'client-to-client' directive in your ovpn server config.
Furthermore, your dlink routers routing table does look a bit odd to me. I could be wrong about this, as the dlink may present its routing table in an unfamiliar way (to me). The way it looks, as I compare it to a working ovpn client which I have access to, is that you have placed both the internal network connecting the dlink AND the vpn tunnel network on subnet 10.8.0.0/24, whilst having configured a routed rather than a bridged vpn. That would make for trouble in the routing department.
As said, I'm not sure how the dlink presents itself routing table wise, so additional details about your network (in particular how the internal ip subnets are planned and the key server ip addresses such as the ovpn server address, dnsmasq address, internal vpn network space, internal client subnets as-is without vpn) would make it easier to help you with that part. Obfuscate as you feel necessary, but make it representative and consistent.
I hope this is of some help.
Best Answer
To block all outbound traffic for clients on the normal WAN, you can use the nvram variable
get wan_iface
You'll want to define your specific IPv4 subnet, be careful not to block your entire LAN range!
This will block any outbound traffic going beyond your router, when not on the VPN interface, you can confirm by doing a
traceroute
to any external IPv4 address, you'll find after the first hop the traffic will drop.For your specific IPv4 client, I'm a little confused. Can't you create a IPv4 subnet for the clients you want going to the VPN and then based on the range make sure that
192.168.1.50
client is not within it? Then just add anACCEPT
rule to allow it to use the WAN as normal?