Is It Possible To Exclude IPv6 Data For Certain LAN IP's Using VPN Director Rules?

[learning_curve]

I have an Asus RT-AC86U C1 router running Merlin v386.5_0. It's running very well indeed.

I have an IVPN account, so I can run the IVPN App if / when needed on any suitable device (desktop / laptop / smartphone) on the LAN without any issues at all e.g. I have no big connection speed penalties / No DNS Leaks etc & the IPVN App works very well indeed. It allows the choice of using either Open VPN and/or WireGuard protocol, but with many additional config options on these protocols too (including IPv6 over IPv4 with Wireguard). IF... I was only wanting to use these types of devices, I wouldn't need to ask the question in the thread title. I am asking said question, because... other other devices e.g. Samsung UHD TV etc run software & software apps but App choices are far more limited than the normal computing devices and this limitation includes, loading any VPN Apps and allowing them to function properly. Thus, Geo-Location say, can sometimes become an unnecessary annoyance on these devices. My 'solution' is to use any of these devices, on VPN that's been provided by my router via my LAN, using a suitable set of VPN Director Rules, specific for that device (fixed IP address).

However, because I use IPv6 everywhere else, all of the time, all of the test attempts of my "solution" that I have made so far on a MacBook Device, using OpenVPN Client 1, always fail. That's fail in terms of the IPv4 connection via OpenVPN Client 1 to the chosen IVPN server working fine, but... The same VPN connection also provides an IPv6 connection which is exactly the same as any Non-VPN connection via my router. Lots of tests confirm this, but ironically, I can still score 20/20 with ipv6-test.com despite the IPv4 being an IVNP server and the IPv6 being by own router! DNS4 + IP6 and DNS6 + IP4 and DNS6 + IP6 all being fully reachable...

That obviously means I do have a mis-config somewhere in my VPN OpenVPN Client (in order to exclude the IPv6 data) or, it's just not possible to do this? (Yet)
The option to simply switch of IPv6 on the router itself is there and would definitely fix this, but I do use IPv6 a lot elsewhere, so I've already discounted this option.

All of the current configuration that I use, that (I think) is relevant to this, is as follows:

• LAN -> DNS Server 1 -> Blank
• LAN -> DNS Server 2 -> Blank
• LAN -> Advertise router's IP in addition to user-specified DNS -> No
• LAN -> DHCP Server - Enhanced by YazDHCP - Manually Assigned IP Addresses -> Yes (For All)
• 
  
• WAN -> Connect to DNS Server automatically -> No
• WAN -> DNS Server 1 -> 1.1.1.1
• WAN -> DNS Server 2 -> 1.0.0.1
• WAN -> Forward local domain queries to upstream DNS -> No
• WAN -> Enable DNS Rebind protection -> Yes
• WAN -> Enable DNSSEC support -> Yes
• WAN -> Validate unsigned DNSSEC replies -> Yes
• WAN -> Prevent client auto DoH -> Yes
• WAN -> DNS Privacy Protocol -> DNS-over-TLS(DOT)
  • DNS Filter is enabled -> Global Filter Mode -> Router
• WAN -> DNS-over-TLS Profile Strict -> Strict
• WAN -> DNS-over-TLS Server List (1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001)
• 
  
• Administration - System -> Network Monitoring -> DNS Query
• Administration - System -> Resolve Hostname -> localhost
• Administration - System -> Resolved IP Addresses -> 127.0.0.1
• 
  
• IPv6 -> Auto Configuration Setting -> Stateless
• IPv6 -> Connect to DNS Server automatically -> Disable
• IPv6 -> IPv6 DNS Server 1 -> LAN IPv6 Link-Local Address
• 
  
• VPN Client -> See attached images
• VPN Director rule -> See attached image

Specific settings above have been made for performance / security and in addition, to ensure that there's no DNS leaks at all (see this excellent thread) in normal operation (The IVPN Apps all produce no DNS leaks when they are in operation and all browsers have WebRTC leaks negated to in either normal or VPN operation).

I don't use any plug-ins, except those shown in my forum signature and I don't have anything on a USB that's also used for the router's operation. I have IPv4 DDNS with Asus and IPv4 & IPv6 DDNS with No IP, but full, effective DDNS IPv6 functionality is still a TBA from Asus (then Merlin in due course). The router on this firmware is the best it's ever been and I have no other issues or problems with anything else, anywhere. #GoodTimes! I haven't - yet - seen that is a simple setting with IPv6 Data - ON or OFF, but I didn't expect to either in fairness. I'd really like to resolve this one (if I can) so if somebody can spot the "obvious" that I have missed, great!

 

[eibgrad]

I'm NOT sure I fully understand the issue, but I *think* the problem you're stating is that the OpenVPN client is bound to *both* IPv4 and IPv6, when you only want IPv4. And if that's the case, adding the following directive to the OpenVPN client custom config field will limit it to IPv4.

proto udp4

 

[learning_curve]

I'm NOT sure I fully understand the issue, but I *think* the problem you're stating is that the OpenVPN client is bound to *both* IPv4 and IPv6, when you only want IPv4. And if that's the case, adding the following directive to the OpenVPN client custom config field will limit it to IPv4.

proto udp4

That's a much easier read @eibgrad & thank you, you're exactly right.

Using VPN Client & the VPN Director rule I've shown (for just one specific IP) I did think that I should be able to ensure that it's IPv4 only within the OpenVPN Client tunnel if coded correctly.

The third party proof of that (I think) is that when using the IPVN App on any any suitable device (desktop / laptop / smartphone) on the LAN, it does exactly that, without any issues, every time.

However... having added that protocol instruction to the custom config (image), the result is still the same, meaning that it still connects to my local ISP for IPv6 despite the IPv4 being via VPN. The first of the two additional images show this clearly. The second image, shows the same test but using the IPVN App & using IPv6 over IPv4 with Wireguard and the App's Firewall and Anti-Tracker both enabled. That's on the same device / same LAN IP address as the first image.

If I use OpenVPN or WireGuard (but without IPv6 over IPv4) on the IVPN App, there's no IPv6 connection at all, which is what I'm trying to achieve when using my router's OpenVPN Client!

Without using VPN at all, on the same device / same LAN IP address the test result is the same as the first image, but my local ISP is shown in both IPv4 and IPv6 areas - as you would expect.

 

[eibgrad]

I think I have a better understanding of the issue.

So what you're saying is your WAN is NOT dual stack (IPv4 + IPv6), but simply IPv6. And when the OpenVPN client binds to the WAN, it's then obviously bound to IPv6. But you want it bound to IPv4.

The problem w/ the default configuration is that it uses the nobind option, which let's OpenVPN choose whatever network interface(s) it wants.

Enable jffs scripts in Administration > System, ssh to the router, and copy/paste the following script into the terminal window. What it will do is create a postconf script for OpenVPN client #1 that forces it to bind *only* to the router's LAN network interface, which we know is IPv4.

#!/bin/sh

SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/openvpnclient1.postconf"

mkdir -p $SCRIPTS_DIR

create_script() {
cat << 'EOF' > $SCRIPT
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

pc_delete "nobind" "$CONFIG"
pc_append "local $(nvram get lan_ipaddr)" "$CONFIG"

exit 0
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi
:

Let's see if that fixes it.

 

[learning_curve]

Close, but no cigar My WAN is actually Dual Stack AFAIK (from memory... before I changed the ISP provided modem//router over to bridge onto my Asus Router, where it's been ever since.

Regardless of that / just in case, I followed those instructions, exactly as written and created: /jffs/scripts/openvpnclient1.postconf - However, when testing OpenVPN client #1 and invoking this config change, the client won't run (see image) & the error log is only brief / these two lines:

Mar 10 12:27:25 ovpn-client1[19122]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:33: remote-cert-tls (2.5.5)
Mar 10 12:27:25 ovpn-client1[19122]: Use --help for more information.

Having seen this error, I've removed the script & everything is back how it was at post #3 again.

NB I didn't remove proto udp4 from within custom config before doing this. Should I have done?

 

[eibgrad]

That error makes no sense. All the script does is delete the nobind directive, and add a local directive. It has nothing to do w/ remote-cert-tls.

You should dump the config file.

cat /tmp/etc/openvpn/client1/config.ovpn

P.S. Do you perhaps have remote-cert-tls specified in the custom config field?

 

[eibgrad]

This is just a guess, but it might be that you do NOT have a carriage return after the remote-cert-tls directive in the custom config field. And then when the script is adding the local directive, it's being appended to that remote-cert-tls line rather than being placed after it, causing a syntax error.

 

[learning_curve]

Thanks again @eibgrad I didn't need to ask you anything on this other excellent thread of yours, in order to get things operating perfectly, but this VPN "challenge" appears to be a little different!

I don't have this file: /tmp/etc/openvpn/client1/config.ovpn In fact, I don't have any sub-directories at all, beyond: /tmp/etc/openvpn/ so I'm not sure where all of the Client1 related data is actually being stored?

P.S. Do you perhaps have remote-cert-tls specified in the custom config field?

The entry that I have, in the custom config field, is in fact, just the VPN Client1 (template) default entry of: remote-cert-tls server which can easily be removed if this a suspect linked to this issue, but, other then the main issue (IPv6) this doesn't cause any issues without the script, see below.

I've added the missing carriage return that you mentioned and after then re-adding the script again and running VPN Client1, that has changed the error message. It's now a AUTH_FAILED message - See below for 2 log entries for VPNClient1 & the /jffs/scripts/openvpnclient1.postconf

Spoiler: VPN Client1 Without The Additional Script

Mar 10 16:30:31 ovpn-client1[17370]: OpenVPN 2.5.5 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 2 2022
Mar 10 16:30:31 ovpn-client1[17370]: library versions: OpenSSL 1.1.1m 14 Dec 2021, LZO 2.08
Mar 10 16:30:31 ovpn-client1[17371]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 10 16:30:31 ovpn-client1[17371]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 10 16:30:31 ovpn-client1[17371]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 10 16:30:31 ovpn-client1[17371]: TCP/UDP: Preserving recently used remote address: [AF_INET]***removed***:2049
Mar 10 16:30:31 ovpn-client1[17371]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Mar 10 16:30:31 ovpn-client1[17371]: UDPv4 link local: (not bound)
Mar 10 16:30:31 ovpn-client1[17371]: UDPv4 link remote: [AF_INET]***removed***:2049
Mar 10 16:30:33 ovpn-client1[17371]: TLS: Initial packet from [AF_INET]***removed***:2049, sid=82a5eb8e 19777022
Mar 10 16:30:33 ovpn-client1[17371]: VERIFY OK: depth=1, C=CH, ST=Zurich, L=Zurich, O=IVPN.net, OU=IVPN, CN=IVPN Root CA v2, emailAddress=***removed***@ivpn.net
Mar 10 16:30:33 ovpn-client1[17371]: VERIFY KU OK
Mar 10 16:30:33 ovpn-client1[17371]: Validating certificate extended key usage
Mar 10 16:30:33 ovpn-client1[17371]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mar 10 16:30:33 ovpn-client1[17371]: VERIFY EKU OK
Mar 10 16:30:33 ovpn-client1[17371]: VERIFY X509NAME OK: C=CH, ST=Zurich, L=Zurich, O=IVPN.net, OU=IVPN, CN=***removed***.ivpn.net, emailAddress=***removed***@ivpn.net
Mar 10 16:30:33 ovpn-client1[17371]: VERIFY OK: depth=0, C=CH, ST=Zurich, L=Zurich, O=IVPN.net, OU=IVPN, CN=sg1.gw.ivpn.net, emailAddress=***removed***@ivpn.net
Mar 10 16:30:34 ovpn-client1[17371]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
Mar 10 16:30:34 ovpn-client1[17371]: [***removed***.ivpn.net] Peer Connection Initiated with [AF_INET]***removed***:2049
Mar 10 16:30:35 ovpn-client1[17371]: SENT CONTROL [***removed***.ivpn.net]: 'PUSH_REQUEST' (status=1)
Mar 10 16:30:36 ovpn-client1[17371]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,explicit-exit-notify 3,comp-lzo no,route-gateway ***removed***,topology subnet,ping 10,ping-restart 60,dhcp-option DNS ***removed***,ifconfig ***removed*** 255.255.252.0,peer-id 51,cipher CHACHA20-POLY1305'
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: timers and/or timeouts modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: explicit notify parm(s) modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: compression parms modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: --ifconfig/up options modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: route options modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: route-related options modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: peer-id set
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: adjusting link_mtu to 1625
Mar 10 16:30:36 ovpn-client1[17371]: OPTIONS IMPORT: data channel crypto options modified
Mar 10 16:30:36 ovpn-client1[17371]: Data Channel: using negotiated cipher 'CHACHA20-POLY1305'
Mar 10 16:30:36 ovpn-client1[17371]: Outgoing Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
Mar 10 16:30:36 ovpn-client1[17371]: Incoming Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
Mar 10 16:30:36 ovpn-client1[17371]: TUN/TAP device tun11 opened
Mar 10 16:30:36 ovpn-client1[17371]: TUN/TAP TX queue length set to 1000
Mar 10 16:30:36 ovpn-client1[17371]: /usr/sbin/ip link set dev tun11 up mtu 1500
Mar 10 16:30:36 ovpn-client1[17371]: /usr/sbin/ip link set dev tun11 up
Mar 10 16:30:36 ovpn-client1[17371]: /usr/sbin/ip addr add dev tun11 1***removed***/22
Mar 10 16:30:36 ovpn-client1[17371]: ovpn-up 1 client tun11 1500 1538 ***removed*** 255.255.252.0 init
Mar 10 16:30:38 ovpn-client1[17371]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mar 10 16:30:38 ovpn-client1[17371]: Initialization Sequence Completed

All of the above, is the Open process

All of the below, is the Close process

Mar 10 16:30:56 ovpn-client1[17371]: event_wait : Interrupted system call (code=4)
Mar 10 16:30:56 ovpn-client1[17371]: SIGTERM received, sending exit notification to peer
Mar 10 16:30:59 ovpn-client1[17371]: ovpn-route-pre-down tun11 1500 1538 ***removed*** 255.255.252.0 init
Mar 10 16:30:59 ovpn-client1[17371]: Closing TUN/TAP interface
Mar 10 16:30:59 ovpn-client1[17371]: /usr/sbin/ip addr del dev tun11 ***removed***/22
Mar 10 16:30:59 ovpn-client1[17371]: ovpn-down 1 client tun11 1500 1538 ***removed*** 255.255.252.0 init
Mar 10 16:30:59 ovpn-client1[17371]: SIGTERM[soft,exit-with-notification] received, process exiting
Mar 10 16:31:00 kernel: Interface tap11 doesn't exist
Mar 10 16:31:00 kernel: Interface tun11 doesn't exist

Spoiler: VPN Client1 WITH The Additional Script / New Error Message

Mar 10 16:34:01 ovpn-client1[18498]: OpenVPN 2.5.5 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Mar 2 2022
Mar 10 16:34:01 ovpn-client1[18498]: library versions: OpenSSL 1.1.1m 14 Dec 2021, LZO 2.08
Mar 10 16:34:01 ovpn-client1[18499]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 10 16:34:01 ovpn-client1[18499]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 10 16:34:01 ovpn-client1[18499]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 10 16:34:01 ovpn-client1[18499]: TCP/UDP: Preserving recently used remote address: [AF_INET]***removed***:2049
Mar 10 16:34:01 ovpn-client1[18499]: Socket Buffers: R=[122880->122880] S=[122880->122880]
Mar 10 16:34:01 ovpn-client1[18499]: UDPv4 link local (bound): [AF_INET]192.168.1.1:1194
Mar 10 16:34:01 ovpn-client1[18499]: UDPv4 link remote: [AF_INET]***removed***:2049
Mar 10 16:34:01 ovpn-client1[18499]: TLS: Initial packet from [AF_INET]***removed***:2049, sid=7e508d78 8445446c
Mar 10 16:34:01 ovpn-client1[18499]: VERIFY OK: depth=1, C=CH, ST=Zurich, L=Zurich, O=IVPN.net, OU=IVPN, CN=IVPN Root CA v2, emailAddress=***removed***@ivpn.net
Mar 10 16:34:01 ovpn-client1[18499]: VERIFY KU OK
Mar 10 16:34:01 ovpn-client1[18499]: Validating certificate extended key usage
Mar 10 16:34:01 ovpn-client1[18499]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mar 10 16:34:01 ovpn-client1[18499]: VERIFY EKU OK
Mar 10 16:34:01 ovpn-client1[18499]: VERIFY X509NAME OK: C=CH, ST=Zurich, L=Zurich, O=IVPN.net, OU=IVPN, CN=***removed***.ivpn.net, emailAddress=***removed***@ivpn.net
Mar 10 16:34:01 ovpn-client1[18499]: VERIFY OK: depth=0, C=CH, ST=Zurich, L=Zurich, O=IVPN.net, OU=IVPN, CN=***removed***.ivpn.net, emailAddress=***removed***@ivpn.net
Mar 10 16:34:01 ovpn-client1[18499]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
Mar 10 16:34:01 ovpn-client1[18499]: [***removed***.ivpn.net] Peer Connection Initiated with [AF_INET]***removed***:2049
Mar 10 16:34:02 ovpn-client1[18499]: SENT CONTROL [***removed***.ivpn.net]: 'PUSH_REQUEST' (status=1)
Mar 10 16:34:02 ovpn-client1[18499]: AUTH: Received control message: AUTH_FAILED
Mar 10 16:34:02 ovpn-client1[18499]: SIGTERM[soft,auth-failure] received, process exiting

 

[eibgrad]

An AUTH FAILED message means the username/password is wrong, and is considered a fatal error. And any fatal error kills the OpenVPN client process completely. And when that happens, the underlying config file (/tmp/etc/openvpn/client1/config.ovpn) is deleted, along with everything else under /tmp/etc/opencpn/client1/). IOW, it behaves the same as if you had manually turned OFF the OpenVPN client.

Assuming you did NOT accidentally change the username/password, less reputable OpenVPN providers will *force* an AUTH FAILED event to either prevent access to a server (perhaps it's currently overloaded or down for maintenance), or even kick active users OFF a given server. I've seen this time and again w/ OpenVPN providers like KeepSolid (aka VPNUnlimited), FastestVPN, etc. It can get so bad at times that the only solution is to implement a watchdog process to notice when this happens and automatically restart the OpenVPN client process.

merlin-ovpn-client-watchdog.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

All that said, it's these other side issues that are missing the point.

Based on your dump of the syslog prior to my script changes (which is the first time I've seen it), I was under the impression OpenVPN was binding to the IPv6 address of your WAN. But according to that syslog, I don't see it. All I see are IPv4 references, thus making my script moot.

So once again, maybe I'm still NOT understanding the problem correctly.

 

[learning_curve]

An AUTH FAILED message means the username/password is wrong, and is considered a fatal error. And any fatal error kills the OpenVPN client process completely. And when that happens, the underlying config file (/tmp/etc/openvpn/client1/config.ovpn) is deleted, along with everything else under /tmp/etc/opencpn/client/). IOW, it behaves the same as if you had manually turned OFF the OpenVPN client.

Assuming you did NOT accidentally change the username/password, less reputable OpenVPN providers will *force* an AUTH FAILED event to either prevent access to a server (perhaps it's currently overloaded or down for maintenance), or even kick active users OFF a given server. I've seen this time and again w/ OpenVPN providers like KeepSolid (aka VPNUnlimited), FastestVPN, etc. It can get so bad at times that the only solution is to implement a watchdog process to notice when this happens and automatically restart the OpenVPN client process.

merlin-ovpn-client-watchdog.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

All that said, it's these other side issues that are missing the point.

Based on your dump of the syslog prior to my script changes (which is the first time I've seen it), I was under the impression OpenVPN was binding to the IPv6 address of your WAN. But according to that syslog, I don't see it. All I see are IPv4 references, thus making my script moot.

So once again, maybe I'm still NOT understanding the problem correctly.

Another great, detailed response. Noted re: the AUTH FAILED message and probable causes and yes, I didn't change the account name / password in OpenVPN VPN Client1. The irony is; That that error message, has never been received, either when using a no-script version of the router's OpenVPN VPN Client1 itself or, any of the off-router/on-device, IVPN App VPN Connections.

Anyway, back to just the "issue" and a concise summary of it (the long version of it, is in the OP):

By adding proto udp4 within the Custom Config of OpenVPN Client1 - as per your helpful earlier post, which should invoke, just an IPv4 VPN connection, one which negates any IPv6 VPN connectivity from the OpenVPN Client1 at the same time, for a specified device, on a specified LAN IP address (VPN Director Rule) and then connecting that specific device to the chosen IVPN VPN server, works perfectly (with no script...) every single time - Perfectly for IPv4 VPN that is.

However... The same OpenVPN Client1 connection (or perhaps my router itself, due to my own misconfiguration) also, simultaneously provides a normal, Non-VPN IPv6 connection with exactly the same connection details, as any normal Non-VPN IPv6 connection that's made via my router.
You can see this clearly in the images and text in post #3 in this thread (and in text in the OP too).

More accurately, OpenVPN Client1, doesn't actually prevent a normal Non-VPN IPv6 connection occurring at the same time, as its active IPv4 OpenVPN Client1 VPN connection << Issue!

See OP for confirmation that this does NOT happen when using any IVPN App VPN Connections.

 

[eibgrad]

To be honest, I have no access to IPv6 at the moment, so that limits my usefulness when dealing w/ IPv6 issues.

I took a look again at those images in post #3. Is all this about the fact that the DNS section is reporting DNS6 + IP4 and DNS6 + IP6 as reachable when using the OpenVPN client on the router, but NOT when using the IVPN app on the same client device?

Because if it is, like many online testing tools, I don't know how much these can be trusted as to their accuracy. Or whether you're correctly interpreting the results. I see the same thing w/ DNS leak testing tools. The fact the router is effectively acting as a "proxy" between the WLAN/LAN client and the remote service can sometimes produce misleading results.

FWIW, I ran the same test and got the following results.

And I don't even have IPv6 support anywhere on my network. Not the router, nor the clients. I've explicitly disabled it everywhere. Given that, I don't quite understand those results.

I'm just wondering if *this* is what this issue is all about for you. And why is it an issue? What problem is it causing? Again, w/ a lot of these online tools, I don't trust them anyway. If I wanted to know what connections were being made by my router, whether IPv4 or IPv6, I'd be dumping connections tracking, not worrying about what some remote tool is reporting. That why I built the DNS monitoring utility. It too only concerns itself w/ local connections, NOT what some remote online reporting tool is telling you.

 

[learning_curve]

To be honest, I have no access to IPv6 at the moment, so that limits my usefulness when dealing w/ IPv6 issues.

To be fair, you did say that some time ago (see this excellent thread) although that's not stopped me using everything that's been posted in that very helpful thread and managing to achieve no IPv4 and/or IPv6 DNS leaks at all, under all of the normal (Non-VPN) operations of my router.

I took a look again at those images in post #3. Is all this about the fact that the DNS section is reporting DNS6 + IP4 and DNS6 + IP6 as reachable when using the OpenVPN client on the router, but NOT when using the IVPN app on the same client device?

In a nutshell, yes! There's an active, 'normal' IPv6 connection at the same time as the active IPv4 OpenVPN Client1 VPN Connection, when this is limited to one device on one LAN IP address via a VPN Director rule, yet.... The IVPN App, when used on the same device, on the same LAN IP address (but with OpenVPN Client1 disabled - obviously), doesn't suffer the same "issue" at all.

Because if it is, like many online testing tools, I don't know how much these can be trusted as to their accuracy. Or whether you're correctly interpreting the results. I see the same thing w/ DNS leak testing tools. The fact the router is effectively acting as a "proxy" between the WLAN/LAN client and the remote service can sometimes produce misleading results.

FWIW, I ran the same test and got the following results.

View attachment 40122

And I don't even have IPv6 support anywhere on my network. Not the router, nor the clients. I've explicitly disabled it everywhere. Given that, I don't quite understand those results.

Agreed, some online test results are very questionable! There are several other sites and tests that can be used to test this particular case though and all do provide the same result i.e. two active contradictory connections. I chose https://ipv6-test.com to illustrate this, only because it's regularly used in posts in this forum, so there would be some advance familiarity with this.

The fact that as per the image ^^ you have no IPv6 service at all (by choice and by config), yet you still have a reachable value for DNS6 + IP4 might be... just due to the presence of Teredo somewhere within all of the connection data itself... That's only my own pure first guess.

I'm just wondering if *this* is what this issue is all about for you. And why is it an issue?

It's an issue because IF I wanted to run an OpenVPN Client1 VPN Connection as mentioned above, on a device that will not run the IVPN App itself, the IPv6 connection completely negates the altered geo-location that's been achieved via the IPv4 VPN connection. That's the #1 issue.

What problem is it causing?

See above. The contradiction and therefore, negation of one connection's data by the other.

Again, w/ a lot of these online tools, I don't trust them anyway. If I wanted to know what connections were being made by my router, whether IPv4 or IPv6, I'd be dumping connections tracking, not worrying about what some remote tool is reporting. That why I built the DNS monitoring utility. It too only concerns itself w/ local connections, NOT what some remote online reporting tool is telling you.

Yep, I am a happy user of that ^^ Though as you've stated elsewhere, it's not (yet) fully functional for complete IPv6 DNS live monitoring (although I have no IPv4 and/or IPv6 DNS leaks at all, shown when using the script you've provided and/or all of the other various external DNS Leak tests, dnscheck.tools and https://dnscheck.tools/#advanced and https://dnscheck.tools/#more being very useful for checking IPv4 / IPv6 / DNSSEC all at the same time etc even with a "live" view via https://dnscheck.tools/watch/cuq9ly which is again IPv4 and IPv6, which is very useful!

 

[learning_curve]

Update.... I did make a post in https://www.snbforums.com/forums/asuswrt-merlin-addons.60/ just in case, but FWIW it just refers back to this one. More importantly, in the interest of testing & then hopefully 'removing by exclusion', here's what's been tested / updated since last time.

On WAN -> DNS Privacy Protocol -> DNS-over-TLS(DOT), I added: DNS Filter is enabled -> Global Filter Mode -> Router which I didn't really expect to make any difference and it didn't, but I've retained this setting anyway and updated the settings data shown in the opening post of this thread by adding this in.

I've tried both settings: Yes and VPN Director that are clearly explained in THIS related forum post. It made no difference, so I've returned this back to how it was: VPN Director and the existing rule that's there.

I've tried & tested every different, relevant OpenVPN lines of additional config that I could find, with the aim of removing the local IPv6 DNS leak from the OpenVPN Client IPv4 VPN connection, but none of them have actually made any difference at all. I've read quite a few articles, including this detailed article (which appeared promising at first...) but again all of these/the actions in them, have failed to make any difference.

Have read up a bit more, it seems... that all of the later releases of OpenVPN including the version that is on my router, are by default, all looking to connect over IPV6 first (if it exists...) plus dual stack IPv4 / IPv6 Clients & Servers have no issues communicating with each other. That alone, explains the issue I'm having!

To underline that it IS possible to do what is being envisaged in the OP, I have had success as follows:

As well as the existing IVPN Apps which overcome this problem (see OP), I have since, downloaded the WireGuard App (VPN Client) for macOS device and created a brand new WireGuard tunnel, then used this device on the LAN. Unsurprisingly, this works perfectly, just like all the IVPN Apps do, as stated in the OP.

A bit more brutal, but very effective, I then temporarily switched off IPv6 service on the same macOS device, which I then re-tested after re-enabling the OpenVPN Client, on my Router. Again, unsurprisingly, this works perfectly, just like all of the IVPN Apps do and all the WireGuard Apps do i.e. There is NO IPv6 service at all (unless it's provided by IVPN themselves using their IPv6 over IPv4 with Wireguard) This can be seen clearly in the attached image (and via the other test sites mentioned, plus THIS one too) It's exactly the same result - which is what's required too, if, the IVPN App settings are changed to OpenVPN - IPv4 Only or WireGuard - IPv4 Only and the IVPN IPv6 over IPv4 with Wireguard service is not used.

After re-reading more of IVPN's own docs, I updated the Custom Config from the one that's shown in an image in post #1 (OP) so the current (and row correct) Custom Config is this:

proto udp4
mssfix
auth SHA1
auth-nocache
persist-remote-ip
cipher AES-256-CBC
remote-cert-tls server
key-direction 1

This ^ continues to work perfectly for IPv4 BUT that IPv6 connection / leak IS still present!

It seems odd that both IVPN and WireGuard can achieve the desired type of connection VPN, effortlessly, on any device, that's on the same LAN, so it really must be doable but, those are VPN connections that are exclusive form my router, so I'm now wondering IF... with an OpenVPN Client that's inside running my router's environment, can the required fix, only be achieved, by making some suitable entries in ip6tables?

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

EDIT: I updated a couple of things in the posts in this thread / removed some typos etc.

The final, correct version of the "missing" file aka /tmp/etc/openvpn/client1/config.ovpn which was first mentioned in post #6 and includes the Custom Config that's being applied is here:

Spoiler: config.ovpn

connect-retry-max 15
nobind
persist-key
persist-tun
compress
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
route-noexec
tls-auth static.key 1
ca ca.crt
verify-x509-name "*removed*" name-prefix
auth-user-pass auth
up 'ovpn-up 1 client'
down 'ovpn-down 1 client'
route-up 'ovpn-route-up'
route-pre-down 'ovpn-route-pre-down'
script-security 2
route-delay 2
verb 3
status-version 2
status status 5

# Custom Configuration
proto udp4
mssfix
auth SHA1
auth-nocache
persist-remote-ip
cipher AES-256-CBC
remote-cert-tls server
key-direction 1

Meanwhile - FYI @eibgrad I thought that there was some valid progress, but subsequently, I've found that I was wrong...

It 1st came to my attention in THIS POST by RMerlin but then, in the "preview" of 386_6.* there is a line in the change-log that will make all the difference (& which is effectively what the IPVN App & the WireGuard App are already doing, outside of the Router when used on devices on the LAN!

- NEW: Added NAT support for OpenVPN servers in IPv6 mode.
This allows to redirect IPv6 Internet traffic
through your OpenVPN server.

However, since then ^ RMerlin has advised in another thread, that this ^ is for servers only NOT clients (I had assumed - in error - that it would apply to both)