OpenVPN Client on GL-SFT1200 4.3.25 Not Connecting

TECHNICAL DETAILS:
MODEL: GL-SFT1200
FIRMWARE VERSION: 4.3.25 release 2 2025-03-17 11:19:12(UTC+08:00)

SUMMARY: OpenVPN Client module in 4.3.25 will not connect, but does so just fine in 3.216.

ATTENTION: In the logs, there is a warning that appears to be something I can't do anything about.

DETAILS: Awhile back, I bought a GL-SFT1200 (not the one in question) to test an idea for a client (the idea worked). I kept it on the shelf for awhile, but found occasion to use it as a test model in a specific scenario for another client, namely setting up a custom OpenVPN client so that their satellite office's MFP could scan and save files to the file server at the home office. It worked on my test bench and I was very happy! I had my client purchase the same (the unit now in question) and went to the site to set things up. When I did, the unit kept freezing and not connecting. I've found that I'm not even able to use the reset button the same as I did before and I have to perform a factory reset to be able to stop the unit from trying to connect to the VPN again! As a "bandage solution," I swapped units with them (good thing I carry it as part of my toolkit!). That worked. Hooray.

TASK: Resolve whatever bug is causing OpenVPN Client to not connect in version 4.3.25.

WHAT I'VE TRIED:

  1. Default settings
  2. Change, "Global Proxy," to, "Auto Detect"
  3. Turn off IP Masquerading
  4. Reading carefully the log. "WARNING" found. See Exhibit B and compare to Exhibit A. The configuration is set up to use a tap device both in the client and server configurations.

EXHIBIT A: REDACTED CONFIGURATION FILE (OVPN)

dev tap
auth-nocache
remote vpn.[REDACTED].com 1194 udp
connect-retry 5 5
keepalive 10 60
resolv-retry infinite
mute-replay-warnings
remote-cert-tls server
verb 3
;redirect-gateway def1
cipher AES-256-GCM
auth SHA512
client
tls-client
persist-key
persist-tun
pull

<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
</key>

key-direction 1

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----
</tls-auth>

EXHIBIT B: REDACTED OPENVPN LOG FROM DEVICE

Thu Apr 17 13:24:35 2025 daemon.notice ovpnclient[6479]: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
Thu Apr 17 13:24:35 2025 daemon.notice ovpnclient[6479]: [RFG-VPN] Peer Connection Initiated with [AF_INET][REDACTED]:1194
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: SENT CONTROL [RFG-VPN]: 'PUSH_REQUEST' (status=1)
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 172.16.218.48,ping 10,ping-restart 120,ifconfig 172.16.218.210 255.255.254.0,peer-id 1,cipher AES-256-GCM'
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: OPTIONS IMPORT: route-related options modified
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: OPTIONS IMPORT: peer-id set
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: OPTIONS IMPORT: adjusting link_mtu to 1624
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: OPTIONS IMPORT: data channel crypto options modified
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Apr 17 13:24:37 2025 daemon.warn ovpnclient[6479]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address.  You are using something (255.255.254.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: TUN/TAP device ovpnclient opened
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: net_iface_mtu_set: mtu 1500 for ovpnclient
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: net_iface_up: set ovpnclient up
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: net_addr_ptp_v4_add: 172.16.218.210 peer 255.255.254.0 dev ovpnclient
Thu Apr 17 13:24:37 2025 daemon.notice ovpnclient[6479]: /etc/openvpn/scripts/ovpnclient-up ovpnclient 0 ovpnclient 1500 1624 172.16.218.210 255.255.254.0 init
Thu Apr 17 13:24:37 2025 user.notice ovpnclient-up: env value:daemon_log_redirect=0 X509_1_emailAddress=[REDACTED] script_type=up proto_1=udp daemon=0 SHLVL=1 dev_type=tun remote_1=vpn.[REDACTED].com dev=ovpnclient X509_0_CN=RFG-VPN remote_port_1=1194 X509_1_CN=RFG-VBOX X509_1_C=[REDACTED] tls_digest_sha256_0=[REDACTED] daemon_start_time=1744921474 script_context=init ifconfig_local=172.16.218.210 common_name=RFG-VPN tls_digest_sha256_1=[REDACTED] verb=3 local_port_1=1194 X509_1_L=[REDACTED] link_mtu=1624 trusted_ip=[REDACTED] tls_serial_hex_0=[REDACTED] X509_1_O=[REDACTED] tun_mtu=1500 tls_serial_hex_1=[REDACTED] trusted_port=1194 tls_id_0=CN=RFG-VPN tls_id_1=C=[REDACTED], ST=[REDACTED], L=[REDACTED], O=[REDACTED], OU=Certificate Authority, CN=RFG-VBOX, emailAddress=[REDACTED]
Thu Apr 17 13:24:37 2025 daemon.notice netifd: ovpnclient (6479): sh: 1: unknown operand

UPDATE (as I'm not able to edit the original post anymore):

WHAT I'VE TRIED:
5. Downgrade to 3.216 and manually upgrade, version by version, to the current.

OBSERVATION: The upgrade from 3.216 to 4.3.7 (the first version that fails) includes an upgrade from OpenVPN 2.5.0-1 to OpenVPN 2.5.7-3 (which stays the same through the current firmware version 4.3.25).

I'm not sure what has broken (or been broken) between the two versions of OpenVPN, but even if everyone hates bridging and tap devices, some of us still use them. Of course, I suppose (per usual story of my life), I could be the odd man out and just have to eat a raspberry pi, and that would be fine and educational.

But for what it's worth, it's probably some screw loose in OpenVPN that's causing tap to not work.

SOLUTION: This appears to be a coding error with OpenVPN (or GL-iNet's implementation of OpenVPN? Has it been modified for the firmware?). As such, no further action is possible on my end. Thank you all who read. I hope this will help future versions of both projects.