pfSense 2.5.2 OpenVPN Server - problems getting DNS working

A Former User

Because this only points to the WAN interfaces. Sorry, your configuration is very confusing. If you could simply explain to me what you want to achieve, I will help you with pleasure.

JEWilson

@silence

Diags - DNS Lookup of pfsense-1.localdomain

A Former User

@jewilson

Test Port PLEASE!

JEWilson

@silence

Test Port results

JEWilson

@jewilson

Results for test port for the DNS Server address 192.168.2.1 in OpenVPN Server config

A Former User

here is the problem in my case if it answers

Gertjan

@jewilson said in pfSense 2.5.2 OpenVPN Server - problems getting DNS working:

On pfSense, I have set up DNS Resolver as a forwarder to cloudfare servers and have configured DNS over TLS to work for all DNS requests to the cloudflare servers. For all local DNS traffic this goes to DNS resolver as port 53 traffic. This all appears to work ok and

and you also specified that you changed the resolvers setting :

which means : only listen to LAN.
( I can't check if you checked other interface )

Then :

The problem I am having is that with Chrome on Android, whenever I use a FQDN to connect
to pfSense via the OpenVPN Connect client, the browser reverts to using Google servers

because there is no DNS server available at the OpenVPN server port.
The client can't try out "something else", and will default to known DNS servers. No surprise that a chrome or Android device goes to "8.8.8.8".

This test confirms it :

an OpenVPN can't connect to "192.168.2.1" (the base OpenVPN network) as the unbound, the resolver, isn't listing on that interface / address.

I propose the default value :

as it works soooooooooo good.
or, at least, include the local networks :

(my case ) :

and now you can remove the "DNS is here 192.168.1.1" in the OpenVPN server settings page.

Firewall :

LAN traffic enter the firewall on the LAN interface using LAN firewall rules.
Right ? Right !

WAN traffic enter the firewall on the WAN interface using WAN firewall rules.
Right of course. Normally, none or very few rules are present on the WAN interface. You have probably a OpenVPN rule there. It permits openvpn clients from the 'outside' to connect to the OpenVPN server.

And there is a OpenVPN interface :
OpenVPN (server) traffic enter the firewall on the OpenVPN (server) interface using OpenVPN (server) firewall rules.
You checked ? Is there a firewall rule ? Normally, there is as the OpenVPN wizard creates one.
It should pass, amongst others, UDP traffic., so DNS traffic can come in.

JEWilson

@gertjan

Thanks for responding.
Y, there is a WAN rule for OpenVPN and there is a rule under the setting for OpenVPN.

I have set the DNS server to 192.168.2.1 as advised in VPN server settings.
When I try to connect with Chrome for Android with the FQDN pfsense-1.localdomain,
the webpage reports the site cannot be reached and is unable to resolve.

As shown below, I did a packet capture as per the supplied settings and then did an
analysis with Wireshark.

As can be seen, google is trying to resolve the DNS request despite the DNS
server setting being sent to 192.168.2.1 in the OpenVPN server config.
This is something that I think Chrome for Android is doing and it is not
the settings specified for the OpenVPN Connect client on Android that I
am using.

I tried setting off Secure DNS in Chrome for Android as well as disabling
the server dns.google which uses DNS over TLS.
This made no difference with the same packet capture settings as prior to and
an analysis in Wireshark as below.

Again, a number of external DNS servers are being queried in order to resolve
the FQDN.

The DNS server specified at 192.168.2.1 is not listening on port 53 but it is listening
on port 80 and port 443.

JEWilson

@jewilson

Changed the DNS Server in the OpenVPN Server config back to 192.168.1.1.
Having checked with Diags -> Test Port on pfSense, I know this address is listening on
port 53, port 80 and port 443.

Downloaded Opera For Android and browsed to https://pfsense-1.localdomain as FQDN.
Unlike with Chrome For Android and other chromium based browsers such as Microsoft
Edge, Opera will, it appears resolve the FQDN but warns, the connection is untrusted.
That would be correct as I have not installed the SSL/TLS certificate for the https connection to
the pfsense WebGUI into Opera for Android.

Having checked settings for Opera, there does not appear to be a means to install the
relevant certificate into the bowser.
The CA chain is installed in the Android Certificate Store and whereas, chromium based
browsers look to this certficate store on Android, Opera for Android does not appear to.

Will try next with Firefox with the DNS server set to 192.168.1.1.

JEWilson

@jewilson

Firefox for Android will not resolve the FQDN even over http on port 80 with the DNS Server
setting for the OpenVPN Server config set to 192.168.1.1.
Reports cannot find the site.

Appears this problem may be browser related issues on Android and how DNS is resolved.

JEWilson

@jewilson

Further investigation with Opera for Android, finds that as above the FQDN will
resolve to port 80 only with the Android OS settings for Private DNS set to off.
I'm using Android 9.
Appears Opera for Android does not have the means to install certificates but
that the desktop version for Linux or Windows does.

As part of further testing, will dl OpenVPN Connect for Windows 7 on my notebook
and test with Chrome and Firefox. I will set up my Android mobile as a hotspot and
connect via WiFi on my notebook to see what results I get with DNS.

JEWilson

@jewilson

As below, I did a packet capture on the DNS resolution of the FQDN in the Opera for
Android browser and analysed with Wireshark.
The query and response are highlighted in the Wireshark screen capture.

JEWilson

@jewilson

Did some further testing with a IBM Thinkpad T60 notebook running Windows
7 Pro SP1.

Note, my DNS server in the pfsense OpenVPN server config is set to 192.168.1.1.

I updated Chrome for Windows, dl'd the relevant OpenVPN connect client for the OS.
Exported the certificate chain from the Windows 10 desktop certficate store and
imported these into the certificate store on Win7 Pro SP1.
Exported the OpenVPN profile from OpenVPN Server for Windows 7.
Installed OpenVPN Connect on the laptop and imported the profile.
Configured my Android 9 mobile handset as a WiFi hotspot and connected
the WiFi on my notepad to this for the purposes of making an inbound VPN
connection to my pfSense appliance via mobile 4G broadband.

This all worked ok and the OpenVPN Connect client connected ok.
I used Chrome browser for Windows to load https://pfsense-1.localdomain
and the name was resolved and the SSL/TLS certificate supported the
https port 443 connection to the pfSense webGUI.

It would appear given this finding with the chrome desktop browser version
for Windows, being it works with DNS as expected with no apparent issues,
the problems I was experiencing with Android and a number of Android
browsers were/are the root cause of my issues.

Hopefully, forum members can use these findings as a basis for their own
work and testing on mobile VPN clients as is relevant to the manner of the OpenVPN
server config I have set up.

Gertjan

@jewilson

Like you, I launched a packet capture on the OpenVPN server interface :

Important settings :
My OpenVPN network : 192.168.3.0/24 and the port : 53.
I should see mostly DNS traffic.

And I did :

08:19:42.573451 IP 192.168.3.2.56732 > 192.168.3.1.53: UDP, length 37
08:19:42.573506 IP 192.168.3.2.50036 > 192.168.3.1.53: UDP, length 37
08:19:42.573550 IP 192.168.3.2.57791 > 192.168.3.1.53: UDP, length 53
08:19:42.573577 IP 192.168.3.2.54751 > 192.168.3.1.53: UDP, length 53
08:19:42.573602 IP 192.168.3.2.55796 > 192.168.3.1.53: UDP, length 27
08:19:42.573626 IP 192.168.3.2.59088 > 192.168.3.1.53: UDP, length 27
08:19:42.575260 IP 192.168.3.1.53 > 192.168.3.2.55796: UDP, length 27
08:19:42.601370 IP 192.168.3.1.53 > 192.168.3.2.59088: UDP, length 43
08:19:42.603502 IP 192.168.3.1.53 > 192.168.3.2.54751: UDP, length 128
08:19:42.629427 IP 192.168.3.1.53 > 192.168.3.2.57791: UDP, length 128
08:19:42.660713 IP 192.168.3.1.53 > 192.168.3.2.50036: UDP, length 133
08:19:42.687205 IP 192.168.3.1.53 > 192.168.3.2.56732: UDP, length 149

Only 2 IP's are listed :
192.168.3.1 = The OpenVPN interface - unbound is instructed to listen on port 53.

192.168.3.2 = my device, an iPhone.
You can clearly see that there are only 2 IP's implicated in the DNS traffic.

For some reason, your logs show 192.168.2.0 as a source or destination IP.
That's impossible. "dot zero" can't be a source or destination, except when broadcasting.

The device you use as an OpenVPN client really obtains 192.168.2.0 as an IP ?

JEWilson

@gertjan

Hi,

Thnaks for responding.
Y, you are right on the matter of 192.168.2.0. This is the broadcast network number used for, e.g. with a DHCP allocated scope such as mine where my VPN network is 192.168.2.0/24.
OpenVPN connect does in fact in use 192.168.2.0 for the client as this is what it gives me!
The VPN gateway is 192.168.2.1.
I think this is what OpenVPN does do albeit it seems at heads with using IP address routing
and network practice - very odd.

You appear to be using Apple iOS, my problems came from Android and using Android browsers.

Gertjan

@jewilson said in pfSense 2.5.2 OpenVPN Server - problems getting DNS working:

OpenVPN connect does in fact in use 192.168.2.0 for the client as this is what it gives me!
The VPN gateway is 192.168.2.1.

Exact.
I use 192.168.3.1 as the VPN gateway. (192.168.3.0/24 is the network setting)
When I connect my VPN client device, it receives the first one available : 192.168.3.2

Does your device receive 192.168.2.0 ?

@jewilson said in pfSense 2.5.2 OpenVPN Server - problems getting DNS working:

Apple iOS, my problems came from Android and using Android browser

We all use the OpenVppN Connect app, right ?
The OS doesn't matter.
192.168.2.0 is not a usable IP DHCP server or the OpenVPN server can hand out to a device - IMHO.

JEWilson

@gertjan

Y, device gets 192.168.2.0
Like I said strange

Gertjan

@jewilson

I re checked your images / settings :

These https://forum.netgate.com/assets/uploads/files/1640291609199-img016.png are normally not needed : See here VPN > OpenVPN > Client Specific Overrides.

Remove it/them.
Re generate a opvn config file for your client.

JEWilson

@gertjan

I am using client specific overrides in order to specify IPv4 LAN clients on pfsense
as 192.168.1.0/24 as you cannot specify these on the actual OpenVPN server config.
On my version of pfsense v2.5.2, it only allows you to specify IPv6 networks.

I take the point, specifying 192.168.2.0/24 on the client specific override for the IPv4
tunnel network is unncessary as this is already specified on the OpenVPN server config settings. I will remove this on the client specific override and see if changes behaviour
on the VPN client being allocated 192.168.2.0.

Additionally, if you look at the exported client OpenVPN Connect OVPN file, this only
provides server settings such as tun settings, the certificates et al. For example, my OVPN
file contains;

persist-tun
persist-key
data-ciphers AES-256-CBC:AES-256-GCM
data-ciphers-fallback AES-256-CBC
auth SHA512
tls-client
client
remote 'public IP address for WAN' 1194 udp4
setenv opt block-outside-dns
verify-x509-name "OpenVPN-server" name
auth-user-pass
remote-cert-tls server
explicit-exit-notify

Of course for the above, I have replaced the actual IP address for my WAN with the stated
text string and the certs are omitted for clarity.

This is all that is exported at least, that is, with my settings. This means in practice you can change the settings for the OpenVPN server below these settings in the OVPN file without requiring a new, export for the OpenVPN Connect client to your mobile handset or notebook etc.
Ditto the case for client specific overrides.

In use, the OpenVPN Connect will connect to the server on pfsense, get the settings set out
in the client export, configure these and use the certificates to configure the VPN connection.
Additionally, the OpenVPN Connect client will obtain the relevant settings from the OpenVPN
server settings which are not specified in the OVPN export and enforce these as it builds
the VPN connection. This includes client specific overrides.

If you look at the log on your OpenVPN Connect client once the connection has been
established, you can see this to be the case. The settings which are not specified in the
OVPN client export, are stated as OPTIONS in the OpenVPN Connect client log. You can
change these (at least in my case) without, as asserted, the need for a fresh OpenVPN
connect client export.

Upon reflection, you may be able to use the advanced configuration custom settings on
the OpenVPN server config in order to specify the LAN network 192.168.1.0/24. I'm not
sure of this or don't know, rather, how to do this.
That being so, using the client specific override to specify the LAN network would be not
necessary and in my case, would preclude from having to specify this in that way.

Thanks for your observations.

JEWilson

@jewilson

I made that change to the client specific override and now OpenVPN Connect is allocating 192.168.2.2 to the client and not 192.168.2.0.

Thanks for the help.