Working Setup ASUS RT-AC86U as Secondary/Client VPN Router with Primary Netgear Router (Conflicts Result)

[Geoff Wiki Inquiry]

SNB FORUM MEMBERS

Hello,

Thank you for reviewing this post as it is my first one concerning setting up my Secondary Router aka Client Router using OpenVPN.

Purpose: Personal and Home Use

Windows 10 Machine: ASUS Desktop M32AD Signature Edition
OS: Microsoft Windows 10 Home
Version: 10.0.19043 Build 19043

Adapters:
Ethernet: Intel(R) Ethernet Connection I217-V
Wireless: Realtek 8821AE Wireless LAN 802.11ac PCI-E NIC
Local Area Connection: TAP-Windows Adapter V9

Current Working Setup and VPN Service - to be clear the current use of ANDROID APPS developed by Torguard work just fine.

Challenge: Would prefer a dedicated secondary router (client) configured and works properly with vpn service(s) using Asuswrt-Merlin firmware.

EQUIPMENT:

CABLE ISP: Comcast aka Xfinity
Modem connected by Coaxial Audio Video Cable directly to cable wall outlet.
Not fiber optic
Subscribed Internet Speed: ***200 Mbps

ROUTER LOCATION: UNIT Multi-family dwellings

Cable Information
Hardware Version C312T00-01
Firmware Version V1.01.14
Cable Modem Serial Number ...........
CM Certificate Installed
CM MAC .................

Startup Procedure
Procedure Status Comment
Acquire Downstream Channel 399000000 Hz Locked
Connectivity State OK Operational
Boot State OK Operational
Security Enabled BPI+
IP Provisioning Mode Honor MDD honorMdd(4)

MODEM SPECS: Netgear CM500 High Speed Cable Modem—DOCSIS 3.0
Hardware Version C312T00-01
Firmware Version V1.01.14
Cable Modem Serial Number .....
CM Certificate Installed
CM MAC ...........
Firmware Version
V1.01.14

PRIMARY ROUTER
NETGEAR WNDR4500v3 is connected directly to Netgear MODEM.
Hardware Version WNDR4500v3
Firmware Version V1.0.0.56
GUI Language Version V1.0.0.259
Operation Mode: ROUTER
LAN Port
MAC Address ..............
NETWORK IP Address: 192.168.1.1
DHCP Server On
Router Firmware Version
V1.0.0.56

Default WAN settings:
Unchecked - Disable Port Scan and DoS Protection
Unchecked - Default DMZ Server
Unchecked - Respond to Ping on Internet Port

***Checked: Disable IGMP Proxying
***NAT Filtering
***Checked - Disable SIP ALG

SECONDARY ROUTER
Secondary Router aka Client Router: ASUS RT-AC86U
Firmware: Asuswrt-Merlin 386.3_2 (SOURCEFORGE) download site
Operation Mode: ROUTER
Secondary Router is connected from WAN port by Ethernet cable directly to Primary Router (Netgear WNDR4500v3) N900 LAN Port #4.
NETWORK: 192.168.2.1

LAN - LAN IP
Host Name: RT-AC86U-6008
RT-AC86U's Domain Name [Blank}
IP Address: 192.168.2.1
Subnet Mask: 255.255.255.0

***ANALOG TELEPHONE ADAPTER
VOIP DEVICE and Third-party VOIP SERVICE connected directly to Primary Router by Ethernet cable to LAN Port #3.
DEVICE: Grandstream HT702
*** 2/4 port analog telephone adapter (ATA)
PORT RANGE ASSIGNED: 5004-65000 Set to "Auto"
This range was given by the VOIP provider.

TORGUARD
ANDROID VPN APP
Torguard Android APP(s)
Installed on both Nvidia Shield TV Console(s)
Status: works fine
Nvidia Shield TV Consoles (X2)

The Nvidia Shield TV Console(s) (X2) are connected directly by LAN cable(s) to ASUS RT-AC86U Secondary Router.

The Torguard Android APP configures and connects to appropriate settings and successful handshakes with Torguard encrypted service.

Route of travel:

Android VPN App activated on Nvidia Shield TV Console travels via LAN cable directly to Secondary Router on NETWORK 192.168.2.1 and then travels by LAN to Primary Netgear Router on NETWORK 192.168.1 through to Netgear Modem to Xfinity servers via coaxial cable and successfully connects to Torugard VPN service.

***Please note: When testing the new configuration on the ASUS secondary router, on-board Android Torguard APP's are turned off on Nvidia Shield TV console(s).

*** This is what puzzles me...the Torguard VPN Android APP installed on each ANDROID Nvidia Shield TV console works perfectly.

REPEATED FAILURE TO CONFIGURE ASUS RT-AC86U AS VPN ROUTER

However when several attempts to use turn the ASUS Secondary Router into a VPN Router all attempts at configuration fail.

Have generated three separate Torguard ovpn config files to see if any other one of them might correct the conflict(s) to no avail.

I have not flashed the ASUS RT-AC86U router in between config file uploads.

Methods and Approaches:

While the Netgear Primary Router is connected to the Comcast/Xfinity servers via coaxial cable I will activate and login to ASUS RT-AC86U by wireless means and follow Torguard VPN instructions utilizing their ovpn config generator.

This is as far as I get.

Below most recent syslog information as of today at 13:35 PM EST:

Service State "ON" Connected "Local: 10.35.0.166 - Internet not redirected"

System Log - Port Forwarding
Virtual Servers
No active port forwards.

UPNP, NAT-PMP and PCP forwards
No active UPNP forward.

Observations and concerns by a layperson

the current --script-security setting may allow this configuration to call user-defined scripts
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 12:35:40 ovpn-client1[31556]: TLS Error: TLS handshake failed
Oct 18 12:35:41 ovpn-client1[31556]: SIGUSR1[soft,tls-error] received, process restarting
"Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6" ???

Example: Can't connect with Windows to OVPN server
Fri Apr 30, 2021 8:11 pm

Can't connect with Windows to OVPN server - OpenVPN Support Forum

----------------------------------
Custom Configuration [BOX]
remote-cert-tls server
setenv CLIENT_CERT 0
resolv-retry infinite
cipher AES-128-CBC
ncp-disable
tun-mtu-extra 32

----------------------------------

Oct 18 12:26:52 wlceventd: wlceventd_proc_event(527): eth6: Auth 28: C2D:8B:16:A3, status: Successful (0), rssi:0 ***Smiley face = D
Oct 18 12:26:52 wlceventd: wlceventd_proc_event(556): eth6: Assoc 28 :C2D:8B:16:A3, status: Successful (0), rssi:0 ***Smiley face = D
Oct 18 12:26:52 dnsmasq-dhcp[2144]: DHCPREQUEST(br0) 192.168.2.6 28:c2:dd:8b:16:a3
Oct 18 12:26:52 dnsmasq-dhcp[2144]: DHCPACK(br0) 192.168.2.6 28:c2:dd:8b:16:a3 DESKTOP-97bJbA
Oct 18 12:32:29 openvpn: Resetting VPN client 1 to default settings
Oct 18 12:34:40 rc_service: httpd 1080:notify_rc start_vpnclient1
Oct 18 12:34:40 kernel: tun: Universal TUN/TAP device driver, 1.6
Oct 18 12:34:40 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Oct 18 12:34:40 ovpn-client1[31555]: DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
Oct 18 12:34:40 ovpn-client1[31555]: OpenVPN 2.5.3 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 6 2021
Oct 18 12:34:40 ovpn-client1[31555]: library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.08
Oct 18 12:34:40 ovpn-client1[31556]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 12:34:40 ovpn-client1[31556]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 12:34:40 ovpn-client1[31556]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 12:34:40 ovpn-client1[31556]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.24:1912
Oct 18 12:34:40 ovpn-client1[31556]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 12:34:40 ovpn-client1[31556]: UDP link local: (not bound)
Oct 18 12:34:40 ovpn-client1[31556]: UDP link remote: [AF_INET]67.213.221.24:1912
Oct 18 12:35:40 ovpn-client1[31556]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 12:35:40 ovpn-client1[31556]: TLS Error: TLS handshake failed
Oct 18 12:35:41 ovpn-client1[31556]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 12:35:41 ovpn-client1[31556]: Restart pause, 5 second(s)
Oct 18 12:35:46 ovpn-client1[31556]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 12:35:46 ovpn-client1[31556]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 12:35:46 ovpn-client1[31556]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 12:35:46 ovpn-client1[31556]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.25:1912
Oct 18 12:35:46 ovpn-client1[31556]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 12:35:46 ovpn-client1[31556]: UDP link local: (not bound)
Oct 18 12:35:46 ovpn-client1[31556]: UDP link remote: [AF_INET]67.213.221.25:1912

-------------------------
TORUGARD CONFIG GENERATOR BASIC INFORMATION
VPN Tunnel type: OpenVPN
VPN Server Hostname/IP: USA-... ....
VPN Protocol: udp
VPN Port: 1912|SHA256
VPN Cipher: AES-128-CBC
OpenVPN Version: 2.4 and above
Require TLS 1.2: [UNCHECKED] Select your TLS Minimum Version - Do not select on OpenVPN versions older than 2.3.11.

 

[eibgrad]

Based on your syslog, it appears you've specified a domain name that resolves to several IPs, and it tries each of them in turn, looking to get connected. Nothing unusual there, just so long as eventually a connection is established w/ one of them. And based on the following …

Service State "ON" Connected "Local: 10.35.0.166 - Internet not redirected"

… that would seem to be the case. But you've apparently failed to select either "Yes(all)" or "VPN Director" for the "Redirect Internet traffic through tunnel" option on the OpenVPN client of the GUI. Without one or the other, nothing is ever routed over the VPN. It just sits there doing nothing.

 

[Geoff Wiki Inquiry]

Based on your syslog, it appears you've specified a domain name that resolves to several IPs, and it tries each of them in turn, looking to get connected. Nothing unusual there, just so long as eventually a connection is established w/ one of them. And based on the following …

Service State "ON" Connected "Local: 10.35.0.166 - Internet not redirected"

… that would seem to be the case. But you've apparently failed to select either "Yes(all)" or "VPN Director" for the "Redirect Internet traffic through tunnel" option on the OpenVPN client of the GUI. Without one or the other, nothing is ever routed over the VPN. It just sits there doing nothing.

Thank you for responding I ran out of room again please don't assume I have a good working knowledge of routers however I am fascinated with them.

RE-ACTIVATED SERVICE STATE
Moved from BLACK to GREEN to turn on: "Service state"
"Service state: = "Error - check configuration!" -error message in yellow color

Authentication Settings
"Warning: You must define a Certificate Authority."

Crypto Settings
Keys and Certificates
Static Key Box
(Illustration 6 - unable to upload this message due to maximum already uploaded)
-----BEGIN OpenVPN Static key V1-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx etc provided by TorGuard
-----END OpenVPN Static key V1-----

Certificate Authority
-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx etc provided by TorGuard
-----END CERTIFICATE-----

*** All other boxes are vacant.

OpenVPN Client Settings
Advanced Settings
Log verbosity 3 (Between 0 and 6. Default: 3)
Compression = None
TLS Renegotiation Time -1 (in seconds, -1 for default)
Connection Retry attempts 15 (0 for infinite)
Firewall setting: I had forgotten to change "Accept DNS Configuration" from "Relaxed" to "Strict" according to TorGuard instructions, so I just did so.
Torguard Website location: https://torguard.net/blog/how-to-setup-openvpn-with-asus-merlin-firmware-torguard/
Pressed the apply tab once again.
RE: Firewall settings, I could not find an up-to-date illustration of what the "Firewall" should be on the most recent version of ASUSwrt-Merlin Firmware 385.3_2
All Internet examples show "automatic"
Below syslog reflects activity before and after change from 'relaxed' to 'strict' for firewall.

GUI Showing: "connecting..." under "Service state"
Result = "Error - check configuration!"

Is there guidance on firmware's "select All" and "redirect all traffic..?"

Curiously it does show I am "connected" but when checking ***ipleak.net the VPN configuration still does not work and I am exposed.

Oct 18 15:21:56 ovpn-client1[6178]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 15:21:56 ovpn-client1[6178]: TLS Error: TLS handshake failed
Oct 18 15:21:56 ovpn-client1[6178]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 15:21:56 ovpn-client1[6178]: Restart pause, 5 second(s)
Oct 18 15:22:01 ovpn-client1[6178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 15:22:01 ovpn-client1[6178]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:22:01 ovpn-client1[6178]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:22:01 ovpn-client1[6178]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.22:1912
Oct 18 15:22:01 ovpn-client1[6178]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 15:22:01 ovpn-client1[6178]: UDP link local: (not bound)
Oct 18 15:22:01 ovpn-client1[6178]: UDP link remote: [AF_INET]67.213.221.22:1912
Oct 18 15:23:02 ovpn-client1[6178]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 15:23:02 ovpn-client1[6178]: TLS Error: TLS handshake failed
Oct 18 15:23:02 ovpn-client1[6178]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 15:23:02 ovpn-client1[6178]: Restart pause, 5 second(s)
Oct 18 15:23:07 ovpn-client1[6178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 15:23:07 ovpn-client1[6178]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:23:07 ovpn-client1[6178]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:23:07 ovpn-client1[6178]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.23:1912
Oct 18 15:23:07 ovpn-client1[6178]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 15:23:07 ovpn-client1[6178]: UDP link local: (not bound)
Oct 18 15:23:07 ovpn-client1[6178]: UDP link remote: [AF_INET]67.213.221.23:1912
Oct 18 15:24:07 ovpn-client1[6178]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 15:24:07 ovpn-client1[6178]: TLS Error: TLS handshake failed
Oct 18 15:24:07 ovpn-client1[6178]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 15:24:07 ovpn-client1[6178]: Restart pause, 5 second(s)
Oct 18 15:24:12 ovpn-client1[6178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 15:24:12 ovpn-client1[6178]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:24:12 ovpn-client1[6178]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:24:12 ovpn-client1[6178]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.24:1912
Oct 18 15:24:12 ovpn-client1[6178]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 15:24:12 ovpn-client1[6178]: UDP link local: (not bound)
Oct 18 15:24:12 ovpn-client1[6178]: UDP link remote: [AF_INET]67.213.221.24:1912
Oct 18 15:25:12 ovpn-client1[6178]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 15:25:12 ovpn-client1[6178]: TLS Error: TLS handshake failed
Oct 18 15:25:12 ovpn-client1[6178]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 15:25:12 ovpn-client1[6178]: Restart pause, 5 second(s)
Oct 18 15:25:17 ovpn-client1[6178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 15:25:17 ovpn-client1[6178]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:25:17 ovpn-client1[6178]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:25:17 ovpn-client1[6178]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.25:1912
Oct 18 15:25:17 ovpn-client1[6178]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 15:25:17 ovpn-client1[6178]: UDP link local: (not bound)
Oct 18 15:25:17 ovpn-client1[6178]: UDP link remote: [AF_INET]67.213.221.25:1912
Oct 18 15:26:17 ovpn-client1[6178]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 15:26:17 ovpn-client1[6178]: TLS Error: TLS handshake failed
Oct 18 15:26:17 ovpn-client1[6178]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 15:26:17 ovpn-client1[6178]: Restart pause, 5 second(s)
Oct 18 15:26:22 ovpn-client1[6178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 15:26:22 ovpn-client1[6178]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:26:22 ovpn-client1[6178]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:26:22 ovpn-client1[6178]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.26:1912
Oct 18 15:26:22 ovpn-client1[6178]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 15:26:22 ovpn-client1[6178]: UDP link local: (not bound)
Oct 18 15:26:22 ovpn-client1[6178]: UDP link remote: [AF_INET]67.213.221.26:1912
Oct 18 15:27:22 ovpn-client1[6178]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Oct 18 15:27:22 ovpn-client1[6178]: TLS Error: TLS handshake failed
Oct 18 15:27:22 ovpn-client1[6178]: SIGUSR1[soft,tls-error] received, process restarting
Oct 18 15:27:22 ovpn-client1[6178]: Restart pause, 5 second(s)
Oct 18 15:27:27 ovpn-client1[6178]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 18 15:27:27 ovpn-client1[6178]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:27:27 ovpn-client1[6178]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 18 15:27:27 ovpn-client1[6178]: TCP/UDP: Preserving recently used remote address: [AF_INET]67.213.221.27:1912
Oct 18 15:27:27 ovpn-client1[6178]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Oct 18 15:27:27 ovpn-client1[6178]: UDP link local: (not bound)
Oct 18 15:27:27 ovpn-client1[6178]: UDP link remote: [AF_INET]67.213.221.27:1912

 

[eibgrad]

I'm seeing contradictory information. You keep showing me syslogs that show no connection. Just endless retries after failed connection attempts. Then you indicate errors about missing certs and alike. But then you show me snapshots of the GUI showing you connected! The only problem being (apparently) that you haven't selected either "Yes(all)" or "VPN Director" for the routing option. As I said before, it has to be one or the other, or NOTHING will get routed over the VPN. As the name suggests, "Yes(all)" means ALL your traffic will be routed over the VPN. Using the "VPN Director" means only those policy rules you've established for the VPN will be routed over the VPN.

Even if you don't know the first thing about using the VPN Director, using "Yes(all)" at least confirms the router is working correctly. If you then decide you want *selective* routing, you can switch to the VPN Director.

 

[Geoff Wiki Inquiry]

I'm seeing contradictory information. You keep showing me syslogs that show no connection. Just endless retries after failed connection attempts. Then you indicate errors about missing certs and alike. But then you show me snapshots of the GUI showing you connected! The only problem being (apparently) that you haven't selected either "Yes(all)" or "VPN Director" for the routing option. As I said before, it has to be one or the other, or NOTHING will get routed over the VPN. As the name suggests, "Yes(all)" means ALL your traffic will be routed over the VPN. Using the "VPN Director" means only those policy rules you've established for the VPN will be routed over the VPN.

Even if you don't know the first thing about using the VPN Director, using "Yes(all)" at least confirms the router is working correctly. If you then decide you want *selective* routing, you can switch to the VPN Director.

 

[Geoff Wiki Inquiry]

I'm seeing contradictory information. You keep showing me syslogs that show no connection. Just endless retries after failed connection attempts. Then you indicate errors about missing certs and alike. But then you show me snapshots of the GUI showing you connected! The only problem being (apparently) that you haven't selected either "Yes(all)" or "VPN Director" for the routing option. As I said before, it has to be one or the other, or NOTHING will get routed over the VPN. As the name suggests, "Yes(all)" means ALL your traffic will be routed over the VPN. Using the "VPN Director" means only those policy rules you've established for the VPN will be routed over the VPN.

Even if you don't know the first thing about using the VPN Director, using "Yes(all)" at least confirms the router is working correctly. If you then decide you want *selective* routing, you can switch to the VPN Director.

 

[Geoff Wiki Inquiry]

Hello;

I have tried to post an update related to success however SNB forums keeps posting:

"Oops! We ran into some problems."
"Oops! We ran into some problems. Please try again later. More error details may be in the browser console."

I will just place some information below without the syslog and see if I can upload some illustrations to explain what I did to solve the problem.

TITLE: Changed VPN unique address from words to common IP address format

Greetings'

'Initialization Sequence Completed'

Server Address and Port Issue Corrected

'Redirect Internet Traffic Through Tunnel - Yes (all)' Setting adopted

*** Suggestions failed until the letters were changed to numbers in unique IP address format.

Secondary VPN Router (ASUS RT-AC86U) Connected Devices' were tested for dns leaks and passed.

Asuswrt-Merlin GUI contradiction CA warning remains.

No explanation as this is presumed a function of the vpn service ovpn config generator or other unknown outlier with the GUI.

*** Best regards and thank you again for an apparent successful end result!