Posted: Sat Jun 29, 2019 18:38 Post subject: TAP connection to OpenVPN on DD-WRT can't use host names
I can ping and connect with host names on all my hosts except my android device using OpenVPN Client legacy. I have DD-WRT configured for DNSmasq. Below are pictures of relevant DD-WRT settings.
I am using OpenVPN Client legacy to run a TAP connection on my android device (a Galaxy S8+). This arrangement was working fine as of early last December and then stopped working for a reason I have been unable to determine. All other hosts on my OpenVPN network connect in TAP mode with each other without problem. For clarity, if I connect my laptop to a “hotspot” from my Galaxy, thereby bypassing Wi-Fi and my home network, my laptop has no problem logging into my DD-WRT OpenVPN server. Furthermore I have no difficulty mapping to any drive on any of the machines (all Windows 10) connected to that OpenVPN server.
OpenVPN Client on my Galaxy also has no problem connecting in TAP mode to that OpenVPN server. The problem is that since early December I am unable ping or connect using host names. Connections using the OpenVPN-server-assigned IP, work without difficulty. All of this leads me to believe that there is something wrong with DNSmasq in my configuration. What it is, however, I simply cannot find, even after much time and research.
The really odd thing is that LANdrive, and only LANdrive on the Galaxy, DOES connect by hostname, even though I cannot ping either by bare hostname or by FQDN using my LAN domain name as defined in DD-DRT.
On a related note, only my laptop recognizes my LAN domain name as its DNS suffix in ipconfig but this seems to be unrelated to the ability of our Windows 10 hosts to ping to and connect to other machines on the OpenVPN network.
Below are my DNSMasq-related settings in DD-WRT. I am also attaching a sanitized version of my OpenVPN server configuration and a sanitized version of the connection log for OpenVPN Client legacy when it connects through my cellular provider’s Internet connection service (rather than through our home Wi-Fi).
I would greatly appreciate any help in correcting this problem. Incidentally, I have been assured by the developer of android OpenVPN Client that nothing has been removed from that app would affect problem.
Additional OpenVPN server config:
push "dhcp-option DNS 192.168.0.1"
push "dhcp-option DNS 126.96.36.199"
push "dhcp-option DNS 188.8.131.52"
keepalive 10 120
# Only use crl-verify if you are using the revoke list - otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl
# management parameter allows DD-WRT\s OpenVPN Status web page to access the server\s management port
# port must be 5001 for scripts embedded in firmware to work
#management localhost 5001
Posted: Wed Jul 03, 2019 15:11 Post subject: Apparent resolution
I am writing this in case anyone has the same problem. But first my thanks to both of you who responded to my rather desperate plea for help.
First, I originally had the OpenVPN pool in the same scope as the DHCP pool — but with separate IP beginning and end numbers. When all else failed, I tried using a separate scope for the reason eibgrad points out. Taking eibgrad’s advice, I went back to the way I originally had the OpenVPN IP pool in December. After much experimentation, I went back to retesting some additional configuration push commands that I had researched last December when I started having problems with my OpenVPN Client connection. Lo and behold, the very first one I tried, push "redirect-gateway autolocal def1", appears to have resolved the problem!
Posted: Thu Jul 04, 2019 14:31 Post subject: Not really a complete solution it appears
push "redirect-gateway autolocal def1"
push "redirect-gateway def1"
work when I use an Internet connection provided by my Galaxy's “hotspot” service. Neither of them work with my LAN or through someone else's Wi-Fi (tried it at my dentist's office yesterday).
All of this brings me back to my greatest frustration in trying to get to the bottom of this problem — I can't get Status/OpenVPN to work and therefore have no idea what is happening with the underlying routing tables. I spent quite a bit of time trying to find a solution to that problem but without success as well.