Feature #3515
closedWindows OpenVPN clients require register-dns to properly use a DNS server set by Pfsense
100%
Description
How to reproduce:
1) Setup an OpenVPN server within pfsense that pushes a DNS server ("Provide a DNS server list to clients") and uses a default domain (not sure if that part is required)
2) From a windows client: While not connected, ping a host that is reachable only via VPN. this will put a negative DNS cache entry into your windows machine, you can verify this using ipconfig /displaydns
3) Connect to the VPN
4) Try to ping or telnet to the same host. Despite the correct connection, it will not be reachable. nslookup will work, ping -4 will work (i was really puzzled about this)
5) Clear the DNS cache using ipconfig /flushdns
6) The ping and telnet should now work
Now add the line
push "register-dns";
to the server's "Advanced configuration". This will flush the DNS on connection.
The main problem about this issue is that it just feel to the naive user as "the vpn is not working".
It is unlikely that they will analyze the problem deeply enough to find out a dns cache flush is required.
I am not sure how pfsense should fix this.
Option 1: Make another checkbox [ ]Force Flush DNS-Cache on windows clients
Option 2: Always send register-dns to clients. It will fix Windows clients and it should not affect Linux clients according to our tests, they just ignore the directive.
Option 3: Include it into the default client configuration generated by pfsense
Either way I believe pfsense should help the user understand and mitigate this problem, otherwise people will see the OpenVPN implementation as unstable or broken.
Updated by Chris Buechler almost 11 years ago
- Tracker changed from Bug to Feature
- Affected Version deleted (
2.1)
Feature since it works as it should. Probably a good idea to add as a checkbox so people realize it exists without digging.
Updated by Anonymous over 10 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset c38764dc0494463b06f70c7ef8e249629a922134.
Updated by Chris Buechler about 10 years ago
- Status changed from Feedback to Resolved