AC86U OpenVPN Server - Client can not resolve hostnames/websites

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Fuze

Occasional Visitor
Hi there,

after the buggy update 384.19 I'm back on 384.18 and I'm still focusing the issue that a connected client is not able to access websites via VPN, but is able to access every machine in LAN/VPN and Ping/NSLOOKUP public machines. I'm kinda confused, because with nslookup google.com 172.16.4.1 it is possible to resolve the hostname.

Here is the generated server config
Code:
# Automatically generated configuration
daemon ovpn-server1
topology subnet
server 172.16.4.0 255.255.255.0
proto udp
port 1194
dev tun21
txqueuelen 1000
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
cipher AES-128-CBC
auth SHA256
compress lz4-v2
keepalive 15 60
verb 3
push "route 192.168.1.0 255.255.255.0 vpn_gateway 500"
duplicate-cn
push "dhcp-option DNS 192.168.1.1"
push "redirect-gateway def1"
plugin /usr/lib/openvpn-plugin-auth-pam.so openvpn
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up updown.sh
down updown.sh
status-version 2
status status 5

# Custom Configuration
client-config-dir /jffs/scripts/ccd
topology "subnet"
push "topology subnet"

This is the client config
Code:
client
dev tun
proto udp
remote 192.168.1.1 1194
float
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
cipher AES-128-CBC
auth SHA256
keepalive 15 60
auth-user-pass
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----
MIIETzC8Axgg174ORR3NQFSvMAiSJ9M7EwDQYJKoZIhvcNAQEF
BQAwcDELMAkGA1UEBhMCVFcxCz
DTALBgNVBAoTu8OQ22nTdZrBgxJHboBNG9T8Z+QjL8enmaK
rvKe
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIEijTAlRXMQswCQYDVQQIEwJUVzEPMA0GA1UEBx
VngCExfpefp6HOfZN27RyvNxq0X4Ow4u1P6ve8B9Jz5OVqTUWn4cLd
Ai34rGnILxjJQEx33mc=
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvAIBCENjxqy1YavGc8TU5IbpV
hO7iSFrARhTg0feEVViKfg==
-----END PRIVATE KEY-----
</key>
resolv-retry infinite
nobind

Do you know what's the matter? The OpenVPN Server is set to Client will use VPN to access for BOTH.

Thank you so far
 

bbunge

Part of the Furniture
Unless you modified addressesin your config files you should factory reset your router and start over. Never use the default port and never post certs!
 

eibgrad

Very Senior Member
It may be possible to "nslookup google.com 172.16.4.1" successfully, but that's NOT the DNS server your OpenVPN server is pushing! So it's irrelevant.

Code:
push "dhcp-option DNS 192.168.1.1"
 

Fuze

Occasional Visitor
Unless you modified addressesin your config files you should factory reset your router and start over. Never use the default port and never post certs!

Why should I factory reset? Will it only work with the 10.8.0.0 network? Good security advice, but first I'd like to have it work.

It may be possible to "nslookup google.com 172.16.4.1" successfully, but that's NOT the DNS server your OpenVPN server is pushing! So it's irrelevant.

Code:
push "dhcp-option DNS 192.168.1.1"

nslookup google.com 192.168.1.1 works too.
 

Centrifuge

Senior Member
the issue that a connected client is not able to access websites via VPN, but is able to access every machine in LAN/VPN
Noob advice follows: Are you trying this on the LAN or WAN side, and this helped me.
 

eibgrad

Very Senior Member
Noob advice follows: Are you trying this on the LAN or WAN side, and this helped me.

Good point. I thought the following was just the OP masking his public IP.

Code:
remote 192.168.1.1 1194

But if that's actual, and the OP is trying to access the VPN from inside the same network on which the VPN is running, that usually won't work. Unlike other services available via remote access, the VPN changes the routing tables. And trying to access the VPN from inside the same network on which it's running usually causes routing confusion. You should *always* access the VPN server from the WAN side to avoid this problem!
 

elorimer

Very Senior Member
You should *always* access the VPN server from the WAN side to avoid this problem!
Agreed. Since you will almost always be using a DDNS address for the VPN server (unless you have a fixed IP), it helps to use the local command so the server only binds to the WAN interface. Then, you can test your configuration from the LAN side using the DDNS address.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top