Opened 7 years ago

Closed 7 years ago

#834 closed Bug / Defect (fixed)

remote-random-hostname changes http-proxy url

Reported by: victor.rds Owned by: Antonio Quartulli
Priority: minor Milestone: release 2.4.1
Component: Configuration Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

The remote-random-hostname option is prepending the address from http-proxy option, therefore is impossible to use both at same time.

Tested on OpenVPN 2.4 on Windows 10 x64

Mon Jan 30 09:33:29 2017 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Mon Jan 30 09:33:29 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jan 30 09:33:29 2017 library versions: OpenSSL 1.0.2i  22 Sep 2016, LZO 2.09
Enter Management Password:
Mon Jan 30 09:33:29 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Jan 30 09:33:29 2017 Need hold release from management interface, waiting...
Mon Jan 30 09:33:29 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'state on'
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'log all on'
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'hold off'
Mon Jan 30 09:33:29 2017 MANAGEMENT: CMD 'hold release'
Mon Jan 30 09:33:31 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 30 09:33:31 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 30 09:33:31 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 30 09:33:31 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 30 09:33:31 2017 MANAGEMENT: >STATE:1485776011,RESOLVE,,,,,,
Mon Jan 30 09:33:31 2017 RESOLVE: Cannot resolve host address: 17dcf03d8978.10.236.68.10:3128 (No such host is known. )
Mon Jan 30 09:33:31 2017 MANAGEMENT: >STATE:1485776011,RESOLVE,,,,,,
Mon Jan 30 09:33:31 2017 RESOLVE: Cannot resolve host address: 5628fefd7756.10.236.68.10:3128 (No such host is known. )
Mon Jan 30 09:34:00 2017 RESOLVE: signal received during DNS resolution attempt
Mon Jan 30 09:34:00 2017 Could not determine IPv4/IPv6 protocol
Mon Jan 30 09:34:00 2017 SIGHUP[hard,close_context usr1 to hup] received, process restarting
Mon Jan 30 09:34:00 2017 MANAGEMENT: >STATE:1485776040,RECONNECTING,close_context usr1 to hup,,,,,
Mon Jan 30 09:34:00 2017 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Mon Jan 30 09:34:00 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jan 30 09:34:00 2017 library versions: OpenSSL 1.0.2i  22 Sep 2016, LZO 2.09
Mon Jan 30 09:34:00 2017 MANAGEMENT: Client disconnected
Mon Jan 30 09:34:00 2017 ERROR: Exit Event ('98400002a70') is signaled
Mon Jan 30 09:34:00 2017 Exiting due to fatal error

Change History (4)

comment:1 Changed 7 years ago by Antonio Quartulli

Victor, OpenVPN is randomizing the hostname of the endpoint it is trying to connect to.

Since you have specified a http proxy, then it is trying to randomize that (because this is the hostname that it will try to locally resolve). The hostname of the remote (aka the OpenVPN server) is no resolved locally and therefore it is passed as it is to the http proxy. Does it make sense?

Note: in your case there is another problem. The http proxy is an IP, not a hostname, therefore the randomization should just be ignored (I sent a patch to the mailing list for this).

comment:2 in reply to:  1 Changed 7 years ago by victor.rds

Yeah get it, is kinda of obvious now, I was unsure if was a bug or correct behavior by design, in any case I think it should be documented.

About the second error, that was lucky, normally I use our production proxy with full name.

Thanks for the answer!

Replying to ordex:

Victor, OpenVPN is randomizing the hostname of the endpoint it is trying to connect to.

Since you have specified a http proxy, then it is trying to randomize that (because this is the hostname that it will try to locally resolve). The hostname of the remote (aka the OpenVPN server) is no resolved locally and therefore it is passed as it is to the http proxy. Does it make sense?

Note: in your case there is another problem. The http proxy is an IP, not a hostname, therefore the randomization should just be ignored (I sent a patch to the mailing list for this).

Last edited 7 years ago by victor.rds (previous) (diff)

comment:3 Changed 7 years ago by Antonio Quartulli

Owner: set to Antonio Quartulli
Status: newaccepted

A patch fixing the mistaken randomization of an IP address has been sent to the ml and has subject:
"[PATCH] ignore remote-random-hostname if a numeric host is provided"

comment:4 Changed 7 years ago by Gert Döring

Milestone: release 2.4.1
Resolution: fixed
Status: acceptedclosed

commit 3c748aeb5e4b82c449e7de28846a3915ab45aeec (master)
commit 0dc790818876dac6e1cf1a82eda8ea15a538a333 (master)

Author: Antonio Quartulli
Date: Mon Jan 30 23:26:58 2017 +0800

ignore remote-random-hostname if a numeric host is provided

Signed-off-by: Antonio Quartulli <a@…>
Acked-by: Gert Doering <gert@…>
Message-Id: <20170130152658.15786-1-a@…>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13993.html

will be in 2.4.1, which is expected to be released today.

Note: See TracTickets for help on using tickets.