AC86U OpenVPN Server - Client can not resolve hostnames/websites

[Fuze]

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

# 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

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]

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]

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.

push "dhcp-option DNS 192.168.1.1"

 

[Fuze]

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.

push "dhcp-option DNS 192.168.1.1"

nslookup google.com 192.168.1.1 works too.

 

[Centrifuge]

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]

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.

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]

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.