Opened 8 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 follow-up: 2 Changed 8 years ago by
comment:2 Changed 8 years ago by
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).
comment:3 Changed 8 years ago by
Owner: | set to Antonio Quartulli |
---|---|
Status: | new → accepted |
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
Milestone: | → release 2.4.1 |
---|---|
Resolution: | → fixed |
Status: | accepted → closed |
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.
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).