Bug 966281

Summary: openvpn 2.3.1 reconnect fails with DNS error, when network is switched
Product: [Fedora] Fedora Reporter: Deian <dchepishev>
Component: openvpnAssignee: Steven Pritchard <steve>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 19CC: bjoern, dapospis, davids, gwync, huzaifas, mihai, rhbugzilla, samuel-rhbugs, steve
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-23 14:58:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Deian 2013-05-22 22:31:28 UTC
Description of problem:

Since I updated openvpn 
from
    openvpn-2.2.2-9.fc18.i686
to
    openvpn-2.3.1-2.fc18.i686

I get the following behavior:

I am connected somewhere, for example wired network. 
If I disconnect and connect to another network, which has different DNS settings I start getting the following errors in the log:

May 22 21:16:47 XXXX openvpn[13230]: RESOLVE: Cannot resolve host address: xxx.yyy.zzz: Temporary failure in name resolution

I sniffed the network traffic and came to the following:
For some reason openvpn remembers the DNS servers from resolv.conf which were valid during process creation. 
Later when the DNS servers change, because I switch to different network, it does not reload them, but keeps trying to question the old DNS-es, which usually refuse recursive queries, because I am already not in their network.

If I downgrade back to openvpn-2.2.2-9.fc18.i686, all goes back to normal, without touching anything else.

My client config:

----------
client                                                                          dev tun
proto tcp
remote xxx.yyy.zzz  443
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher BF-CBC
keysize 512
script-security 1
comp-lzo
verb 3
keepalive 10 60
<cert>
CERT HERE
</cert>
<key>
KEY HERE
</key>
<ca>
CA HERE
</ca>
---------------


Version-Release number of selected component (if applicable):

openvpn-2.3.1-2.fc18.i686

How reproducible:

always

Steps to Reproduce:
1. Establish VPN tunnel
2. Connect to different network with different DNS servers
3. The IPs of the old DNS servers MUST be inaccessible or not be valid DNS resolvers in the new network. 

Actual results:

Start getting the following errors:

Cannot resolve host address: xxx.yyy.zzz: Temporary failure in name resolution


Expected results:

To reconnect with no issues. 


Additional info:

Comment 1 Samuel Sieb 2013-05-24 17:45:44 UTC
I'm seeing this too.  It's getting rather annoying...

Comment 2 Mihai Lazarescu 2013-06-08 18:05:27 UTC
I confirm, same here.

Comment 3 Björn Ruberg 2013-12-19 11:15:53 UTC
Confirmed here. Verry annoying. 
I use a dnynds adresse for my clients to connect to. But that does simply not work in Fedora because of this bug.

Comment 4 Fedora End Of Life 2013-12-21 13:40:57 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Samuel Sieb 2013-12-21 22:21:08 UTC
This still happens in Fedora 19.

Comment 6 Björn Ruberg 2013-12-22 10:08:24 UTC
And in Fedora 20 of course. I helped myself by configuring the openvpn connection in NetworkManager and adding a dispatch script that starts the vpn connection as soon as any network interface gets up. That is a workaround.

Comment 7 David Sommerseth 2013-12-23 14:58:29 UTC
This seems to be tracked now by the upstream tracker too.

https://community.openvpn.net/openvpn/ticket/303 (pointing back to this bz)

As this seems to primarily be an upstream OpenVPN issue, and not a Fedora issue - I'll close this one as CLOSED:UPSTREAM.  OpenVPN bugs in this bugzilla mostly tackles packaging and Fedora only related issues.

Please consider to try to help out testing and debugging in cooperation with upstream directly.

Comment 8 David Sommerseth 2018-02-16 11:02:50 UTC
*** Bug 985415 has been marked as a duplicate of this bug. ***