Opened 7 years ago
Closed 3 years ago
#771 closed Bug / Defect (wontfix)
Adding IPv6 routes may fail on Windows if openvpn.exe has not been shut down gracefully
| Reported by: | Samuli Seppänen | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | release 2.4.9 |
| Component: | Networking | Version: | OpenVPN git master branch (Community Ed) |
| Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | windows |
| Cc: |
Description
This problem was found when testing with openvpn-windows-test against the t_client.sh test servers. This issue also revealed the exit-event issue in openvpnserv2.
If openvpn.exe is killed forcibly, without proper cleanup, IPv6 routes are left behind, as would be expected. If openvpn.exe is then used to launch another connection with a different, but similar IPv6 route, adding the route will fail. The end result is that the old rule remains, and the new one is missing, and connectivity is partially broken.
When OpenVPN is shut down in controlled fashion, it is able to flush the old rules, and on the next connection it will be able to create IPv6 routes properly.
This problem can be reproduced easily using openvpn-windows-test and pointing it at the t_client test servers.
Change History (4)
comment:1 Changed 7 years ago by
| Milestone: | RC 2.4 → release 2.4.1 |
|---|
comment:2 Changed 4 years ago by
| Milestone: | release 2.4.1 → release 2.4.9 |
|---|
@samuli, do we want to do something about it? Except your test scripts, this seems to have not bothered anyone yet... under normal conditions, when openvpn.exe exits (even on error) it cleans up correctly...
comment:4 Changed 3 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I say we close this.
Why? Because that's the way it is, on all platforms... if you hard kill the program that is responsible for restoration of "the previous state" after shutdown, this won't happen.
So, do not hard kill things.
We discussed this in today's community meeting. The consensus was that because this is rather hard to reproduce in normal usage, and it is not a regression from 2.3, we can bump this to milestone 2.4.1.