Upgrade to OpenVPN 1.2.5 (iOS): DNS settings not applied

[cyayon]

Hi all,

another bug, unless you have redirect-gateway def1 on client side, DNS settings will not be received by client (pushed from server)...

is there any procedure to rollback from previous version please ?

Thanks.

[ordex]

Hi all,

another bug, unless you have redirect-gateway def1 on client side, DNS settings will not be received by client (pushed from server)...

Could you please send the connection log to iOS @ openvpn . net ?

is there any procedure to rollback from previous version please ?

Not really. The AppStore does not allow that.

Thanks

[cyayon]

Hi all,

another bug, unless you have redirect-gateway def1 on client side, DNS settings will not be received by client (pushed from server)...

Could you please send the connection log to iOS @ openvpn . net ?

is there any procedure to rollback from previous version please ?

Not really. The AppStore does not allow that.

Thanks

Nothing in the log about a problem with DNS. But when using another app and check my current IP params, the DNS settings has not been updated....
If i modify my opvn client config file and "add redirect-gateway def1", the DNS setting is correctly defined.

[ordex]

Nothing in the log about a problem with DNS.

yeah, I did not expect an error. But the log should allow the devs to understand what's the flow of the setup routine and what is being skipped.
You can email it to iOS @ openvpn.net and mention your problem, if possible.

Thanks

[cyayon]

Nothing in the log about a problem with DNS.

yeah, I did not expect an error. But the log should allow the devs to understand what's the flow of the setup routine and what is being skipped.
You can email it to iOS @ openvpn.net and mention your problem, if possible.

Thanks

here is the log :

-----------------2018-01-09 15:29:20 EVENT: RESOLVE
2018-01-09 15:29:20 Contacting [xxxx]:443/TCP via TCP
2018-01-09 15:29:20 EVENT: WAIT
2018-01-09 15:29:20 Connecting to [xxxx:443 (xxxx) via TCPv4
2018-01-09 15:29:20 EVENT: CONNECTING
2018-01-09 15:29:20 Tunnel Options:V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client
2018-01-09 15:29:20 Creds: UsernameEmpty/PasswordEmpty
2018-01-09 15:29:20 Peer Info:
IV_GUI_VER=net.openvpn.connect.ios 1.2.5-1
IV_VER=3.1.2
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO=1
IV_AUTO_SESS=1
IV_BS64DL=1

2018-01-09 15:29:20 VERIFY OK : depth=0
cert. version : 3
serial number : 01
issuer name : C=FR, L=Paris, O=xxxx, CN=xxxx, emailAddress=xxxx
subject name : C=FR, L=Paris, O=xxxx, CN=xxxx, emailAddress=xxxx
issued on : 2014-09-16 08:36:10
expires on : 2024-09-13 08:36:10
signed using : RSA with SHA1
RSA key size : 1024 bits
basic constraints : CA=false
cert. type : SSL Server
key usage : Digital Signature, Key Encipherment
ext key usage : TLS Web Server Authentication

2018-01-09 15:29:21 SSL Handshake: TLSv1.2/TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
2018-01-09 15:29:21 Session is ACTIVE
2018-01-09 15:29:21 EVENT: GET_CONFIG
2018-01-09 15:29:21 Sending PUSH_REQUEST to server...
2018-01-09 15:29:21 OPTIONS:
0 [route] [192.168.1.0] [255.255.255.0]
1 [route] [192.168.2.0] [255.255.255.0]
2 [route] [192.168.3.0] [255.255.255.0]
3 [route] [192.168.4.0] [255.255.255.0]
4 [route] [192.168.40.0] [255.255.255.0]
5 [route] [192.168.42.0] [255.255.255.0]
6 [route] [192.168.43.0] [255.255.255.0]
7 [route] [192.168.44.0] [255.255.255.0]
8 [route] [192.168.250.0] [255.255.255.0]
9 [dhcp-option] [DOMAIN] [xxxx] [xxxx]
10 [dhcp-option] [DNS] [192.168.43.1]
11 [dhcp-option] [NTP] [192.168.42.254]
12 [route-gateway] [192.168.43.1]
13 [topology] [subnet]
14 [ping] [10]
15 [ping-restart] [60]
16 [socket-flags] [TCP_NODELAY]
17 [ifconfig] [192.168.43.2] [255.255.255.0]
18 [peer-id] [0]
19 [cipher] [AES-256-GCM]

2018-01-09 15:29:21 PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: SHA1
compress: LZO
peer ID: 0
2018-01-09 15:29:21 EVENT: ASSIGN_IP
2018-01-09 15:29:21 NIP: preparing TUN network settings
2018-01-09 15:29:21 NIP: init TUN network settings with endpoint: xxxx
2018-01-09 15:29:21 NIP: adding IPv4 address to network settings 192.168.43.2/255.255.255.0
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.1.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.2.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.3.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.4.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.40.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.42.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.43.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.44.0/24
2018-01-09 15:29:21 NIP: adding (included) IPv4 route 192.168.250.0/24
2018-01-09 15:29:21 NIP: adding search domain xxxx
2018-01-09 15:29:21 NIP: adding search domain xxxx
2018-01-09 15:29:21 NIP: adding DNS 192.168.43.1
2018-01-09 15:29:21 Connected via NetworkExtensionTUN
2018-01-09 15:29:21 LZO-ASYM init swap=0 asym=0
2018-01-09 15:29:21 EVENT: CONNECTED @xxxx:443 (xxxx) via /TCPv4 on NetworkExtensionTUN/192.168.43.2/ gw=[/]

[ordex]

2018-01-09 15:29:21 NIP: adding DNS 192.168.43.1

I see the DNS IP is being pushed down to the Apple API, therefore it should have been applied.
Have you tried to verify on the server if any DNS traffic is coming from this device?

Note that in this case the DNS is going to be private to the tunnel interface and not system-wide. Are you sure your app is able to see interface specific DNS settings?

[risyer]

With the latest 1.2.5 version, we can also confirm that custom DNS settings are not propagating to our users. How can we help to get this resolved as fast as possible?

[ordex]

With the latest 1.2.5 version, we can also confirm that custom DNS settings are not propagating to our users. How can we help to get this resolved as fast as possible?

Can you confirm that also in your case you are not pushing the default route to your clients?
How are you verifying that the DNS settings are not applied? can you see actual traffic going to the wrong DNS?

Thanks

[risyer]

>Can you confirm that also in your case you are not pushing the default route to your clients?
What's the easiest way to confirm that? We don't pass through traffic. Can I email you a stripped down version of our logs?

>How are you verifying that the DNS settings are not applied? can you see actual traffic going to the wrong DNS?
On iOS, v1.1.1 we were able to access our intranet through apps, safari etc (I used it yesterday). Today on 1.2.5 we cannot, ontop of that our desktop clients work fine and android as well.

[ordex]

>Can you confirm that also in your case you are not pushing the default route to your clients?
What's the easiest way to confirm that? We don't pass through traffic. Can I email you a stripped down version of our logs?

yes, please. The log of the connection setup, from the start to the CONNECTED event would be appreciated.
You can paste it here if you can, in a code box.

>How are you verifying that the DNS settings are not applied? can you see actual traffic going to the wrong DNS?
On iOS, v1.1.1 we were able to access our intranet through apps, safari etc (I used it yesterday). Today on 1.2.5 we cannot, ontop of that our desktop clients work fine and android as well.

ok, this sounds suspicious. It might be related to this problem

[risyer]

Code: Select all

----- OpenVPN Start -----
OpenVPN core 3.1.2 ios arm64 64-bit built on Jan  5 2018 23:09:59
2018-01-09 09:43:11 Frame=512/2048/512 mssfix-ctrl=1250
2018-01-09 09:43:11 UNUSED OPTIONS
3 [nobind]
16 [sndbuf] [100000]
17 [rcvbuf] [100000]
20 [verb] [3]
30 [CLI_PREF_ALLOW_WEB_IMPORT] [True]
31 [CLI_PREF_BASIC_CLIENT] [False]
32 [CLI_PREF_ENABLE_CONNECT] [True]
33 [CLI_PREF_ENABLE_XD_PROXY] [True]
34 [WSHOST] [xxxxxxxxxxxxx:443]
35 [WEB_CA_BUNDLE] [-----BEGIN CERTIFICATE----- ............]
36 [IS_OPENVPN_WEB_CA] [0]
37 [ORGANIZATION] [OpenVPN Technologies, Inc.]

2018-01-09 09:43:11 EVENT: RESOLVE
2018-01-09 09:43:12 Contacting [xx.xx.xx.xx]:1194/UDP via UDP
2018-01-09 09:43:12 EVENT: WAIT
2018-01-09 09:43:12 Connecting to [xxxxxxxxxxxxx]:1194 (xx.xx.xx.xx) via UDPv4
2018-01-09 09:43:12 EVENT: CONNECTING
2018-01-09 09:43:12 Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-128-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client
2018-01-09 09:43:12 Creds: Username/Password
2018-01-09 09:43:12 Peer Info:
IV_GUI_VER=net.openvpn.connect.ios 1.2.5-1
IV_VER=3.1.2
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO=1
IV_LZO_SWAP=1
IV_LZ4=1
IV_LZ4v2=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1

2018-01-09 09:43:13 VERIFY OK : depth=1
cert. version    : 3
serial number    : 58:C9:0C:03
issuer name      : CN=OpenVPN CA
subject name      : CN=OpenVPN CA
issued  on        : 2017-03-08 09:40:19
expires on        : 2027-03-13 09:40:19
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=true

2018-01-09 09:43:13 VERIFY OK : depth=0
cert. version    : 3
serial number    : 01
issuer name      : CN=OpenVPN CA
subject name      : CN=OpenVPN Server
issued  on        : 2017-03-08 09:40:19
expires on        : 2027-03-13 09:40:19
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=false
cert. type        : SSL Server

2018-01-09 09:43:13 SSL Handshake: TLSv1.0/TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA
2018-01-09 09:43:13 Session is ACTIVE
2018-01-09 09:43:13 EVENT: GET_CONFIG
2018-01-09 09:43:13 Sending PUSH_REQUEST to server...
2018-01-09 09:43:14 Sending PUSH_REQUEST to server...
2018-01-09 09:43:14 OPTIONS:
0 [explicit-exit-notify]
1 [topology] [subnet]
2 [route-delay] [5] [30]
3 [dhcp-pre-release]
4 [dhcp-renew]
5 [dhcp-release]
6 [route-metric] [101]
7 [ping] [12]
8 [ping-restart] [50]
9 [auth-token] ...
10 [comp-lzo] [yes]
11 [redirect-private] [def1]
12 [redirect-private] [bypass-dhcp]
13 [redirect-private] [autolocal]
14 [route-gateway] [172.27.232.1]
15 [route] [172.27.224.0] [255.255.240.0]
16 [route] [10.30.0.0] [255.255.0.0]
17 [dhcp-option] [DNS] [10.30.0.2]
18 [dhcp-option] [DNS] [10.30.0.2]
19 [register-dns]
20 [block-ipv6]
21 [ifconfig] [172.27.233.249] [255.255.248.0]

2018-01-09 09:43:14 Session token: [redacted]
2018-01-09 09:43:14 PROTOCOL OPTIONS:
  cipher: AES-128-CBC
  digest: SHA1
  compress: LZO
  peer ID: -1
2018-01-09 09:43:14 EVENT: ASSIGN_IP
2018-01-09 09:43:14 NIP: preparing TUN network settings
2018-01-09 09:43:14 NIP: init TUN network settings with endpoint: xx.xx.xx.xx
2018-01-09 09:43:14 NIP: adding IPv4 address to network settings 172.27.233.249/255.255.248.0
2018-01-09 09:43:14 NIP: adding (included) IPv4 route 172.27.224.0/20
2018-01-09 09:43:14 NIP: adding (included) IPv4 route 10.30.0.0/16
2018-01-09 09:43:14 NIP: adding DNS 10.30.0.2
2018-01-09 09:43:14 NIP: adding DNS 10.30.0.2
2018-01-09 09:43:14 NIP: adding search domain
2018-01-09 09:43:14 Connected via NetworkExtensionTUN
2018-01-09 09:43:14 LZO-ASYM init swap=0 asym=0
2018-01-09 09:43:14 EVENT: CONNECTED xxxxxxx@xxxxxxxxxxxxx:1194 (xx.xx.xx.xx) via /UDPv4 on NetworkExtensionTUN/172.27.233.249/ gw=[/]

[Keet70x]

I can confirm that this is a new bug on new iOS client. Had several reports today from users and confirmed it myself. All the conditional DNS logic when using a “split tunnel” type vpn now seems broken. Tested while connected to an official enterprise OpenVPN access server, and also on the community server running on a pfsense box. Since last iOS OpenVPN-client update, DNS requests aren’t being routed to the private dns server when using a split tunnel config. Only “redirect all” results in dns hitting the private dns server, even though the dhcp option “DOMAIN” with private domain name has been pushed. Logfile on client looks fine, and the options are being acknowledged, but the actual requests are just going to the existing configured dns server address instead if the private one through the tunnel.

All config was done as per the iOS faq. It was working as expected up until the last iOS update.

Happy to provide diagnostic info if necessary.

[pallago]

I can confirm the same problem with split tunneling. With the update to 1.2.5. the DNS servers are not pushed (nor the domain) but according to the log file it is pushed. Using another PC (Windows Client) everything is fine -> so I think it is due to the update on iOS.

Code: Select all

NIP adding DNS 192.168.0.x
NIP: adding search DOMAIN xxx

[Emergence]

Noticed the same problem here; DNS queries never hit the pushed server (tested by watching tcpdump for the incoming queries). Works on 1.1.1, but is busted on 1.2.5. This can be replicated on ios 11.0.x and 11.2.x.

[senorloco]

I'm glad I'm not the only one having this issue with 1.2.5...I thought I was going crazy for a little bit. I really wish there was a way to downgrade, but hopefully a fix will be pushed out soon.

[mivo]

Hi,

I can confirm problem with DNS after update to 1.2.5 iOS client. After update on iPad (iOS 11.2.2), DNS resolving via pushed DNS servers with search domain stop working. IP connections to numeric IPv4 addresses behind VPN tunnel works. iPhone not yet updated (client version 1.1.1) works OK with same VPN server and profile.

[ordex]

We have identified the problem. Thanks for your support. A fix will be available in the next release.

[CameronD2]

just in case it makes any difference I can confirm the DNA failure in latest ios 11 as well as an iphone 5 with the latest ios 10 (not in my hand at the moment, so I can't state exact version)

[ordex]

As a temporary workaround while we push out the new release, it is possible to redirect all the traffic over the VPN tunnel. That should make the DNS work for now. I know it may not be desirable, but it's just for the time being.

Traffic redirection can be enabled by adding on the client:

redirect-gateway def1

or on the server:

push "redirect-gateway def1"

[risyer]

Do you have any ETA as for when a new release will be out? It would be quite cost prohibitive to push all traffic through...