Opened 9 years ago
Closed 9 years ago
#504 closed Bug / Defect (duplicate)
Routing table change should either be complete, or not change at all
Reported by: | yurivict | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.2.2 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
I spotted the situation when 'openvpn xxx.ovpn' failed to add the routing rule to route to the VPN server IP through the previously default interface, therefore leaving VPN non-functional.
OpenVPN code should always keep the change "atomic", it is either complete, or rolled back.
This problem may appear as an intermittent failure to the user.
OS: FreeBSD 10.1
Change History (3)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
It failed, because it tried to add the routes
0.0.0.0/1
128.0.0.0/1
the second time.
Version 0, edited 9 years ago
by
(next)
comment:3 Changed 9 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Ah, so this is a duplicate of #544.
Will close this one, look into the other one.
Note: See
TracTickets for help on using
tickets.
Indeed. Do you have any idea why the installation of the new route failed, or happen to have a log file demonstrating the issue?