OpenVPN Connect ignoring local ifconfig

[cmeller]

Hi all,

I am trying to setup a config for OpenVPN Connect on iOS. The used config works fine on Windows and Linux:

>>>>
tls-client
dev tun
ifconfig 100.65.0.5 100.65.0.6
route 100.65.0.0 255.255.255.248
route 192.168.177.0 255.255.255.0
proto tcp
pull
remote X.X.X.X YY
verify-x509-name "L=GW, O=XXX"
remote-cert-tls server
cipher AES-256-GCM
auth SHA384
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
reneg-sec 3600
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
>>>>

When starting the connection, the app directly logs that the ifconfig is ignored (UNUSED OPTIONS)

[Aug 31, 2023, 13:37:36] START CONNECTION
[Aug 31, 2023, 13:37:36] ----- OpenVPN Start ----- OpenVPN core 3.git::081bfebe ios arm64 64-bit
[Aug 31, 2023, 13:37:36] OpenVPN core 3.git::081bfebe ios arm64 64-bit
[Aug 31, 2023, 13:37:36] Frame=512/2048/512 mssfix-ctrl=1250
[Aug 31, 2023, 13:37:36] UNUSED OPTIONS
0 [tls-client]
2 [ifconfig] [100.65.0.5] [100.65.0.6]
6 [pull]

After authenticating and negotiating the setup of the interface fails because of missing ip parameters:
>>>
[Aug 31, 2023, 13:37:37] EVENT: ASSIGN_IP

[Aug 31, 2023, 13:37:37] NIP: preparing TUN network settings

[Aug 31, 2023, 13:37:37] NIP: init TUN network settings with endpoint: X.X.X.X

[Aug 31, 2023, 13:37:37] Client exception in transport_recv: tun_prop_error: one of ifconfig or ifconfig-ipv6 must be specified

[Aug 31, 2023, 13:37:37] Client terminated, restarting in 2000 ms...
>>>

The server has a matching ifconfig directive configured as well (ifconfig 100.65.0.6 100.65.0.5).

Can anyone give me a hint what is going wrong ?

Thanks in advance and best regards,

Chris

[openvpn_inc]

Hello,

I am sorry to say that you're in a bit of a strange case where you do have the client configured to get instructions from the server, and normally that includes the IP configuration, but in your particular case you put this config in the local config file, where it gets ignored on modern clients. It does accept it when pushed. Which is something that normally happens when you use the 'server' directive wtih a subnet reserved for the clients. So I would recommend doing that instead and removing this from the client side.

Kind regards,
Johan