Bug #2712
closed
Openvpn and Quagga cause route collision and race condition
100%
Description
Configuring Quagga for route redistribution over redundant Openvpn site to site links, can cause OpenVPN to fail to bring up one of the tunnels. OSPF installs a route for the point to point interfaces
into the kernel after learning the route from the remote system, over the first link (Link A). If openvpn is started after OSPF has established adjacencioes and, if will fail to configure
the interface, because the kernel already has a /32 route installed. OSPF is running over the point to point links, so there does not seem to be a direct way to disable route redistribution.
If openvpn is started and tunnels are configured before OSPF establishes (which is normal during a reboot), the error does not happen.
Updated by Jim Pingle about 12 years ago
I suspect one possible solution would be to simply set it to not distribute routes for the actual OpenVPN tunnel interfaces. Those are not typically required anyhow, as the users are much more interested in the routes behind, and those are directly connected anyhow.
If we can confirm that fixes it, I can add an option to the interface to disable redistributing that interface's subnet.
Updated by Jim Pingle about 12 years ago
another tactic might be to have the OpenVPN code do a "route delete x.x.x.x" where x.x.x.x is the IP in the routing table.
You said it had a /32 route that it had learned - was that route the local IP, or the remote IP? It looks like mine (just a single interface in OSPF, not multiple) has the remote IP, but I'm not sure if that's what you were seeing in that scenario.
Updated by Jim Pingle about 12 years ago
I just committed a change that should work when the OS (re)starts OpenVPN, but I'm not sure if this will cover the case when openvpn resets itself with --ping-restart. Worth a try though.
Updated by Jeremy Porter about 12 years ago
The two vpns were 192.168.200.0/24 and 192.168.198.0/24.
The central site is the server, the remote site is the client. The client (when in broken state) is brought up, ospf forms the first adjacency, and advertises 192.168.200.2/32 (This will be the client's IP for the second VPN connection).
Updated by Chris Buechler about 12 years ago
I believe that change will fix the issue.
We tried telling it to not distribute the tun subnet, both as a /32 and as the /30, and that didn't seem to do anything. It was still in the RIB and FIB. not sure it's possible to have quagga not redistribute networks in that fashion.
Updated by Jim Pingle about 12 years ago
I didn't want to commit this to 2.0.x not knowing for sure if it fixed the issue, but here is a patch that can be applied to 2.0.x using the System Patches package:
http://files.nyi.pfsense.org/jimp/patches/openvpn-clear-route-20x.patch
Path Strip Count: 1
Base: /
Ignore Whitespace
Updated by Johan Braeken almost 12 years ago
I'm also experiencing this issue and applied the patch.
However, there is still a related issue. (I did not file this as a new bug as it is only occuring after applying this patch.)
I have Quagga enabled on a "ovpnc*" interface.
This interface goes down when the VPN goes down.
When the VPN comes back up, and the "ovpnc*" interface also comes back up, but Quagga does not work anymore as on the status page it says: "OSPF not enabled on this interface".
Going to the "Interface Settings", editing and saving the "ovpnc*" interface (without changing anything), makes it work again.
Updated by Jim Pingle about 11 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset pfsense-packages:commit:63d03dab164bb44ce4747629f14a022086aac3ec.
Updated by Jim Pingle about 11 years ago
- Status changed from Feedback to Resolved
For those interested in implementing the fix: After updating your Quagga package, edit each interconnect interface (e.g. VPNs) and check the "Accept Filter" box. This should be sufficient.
If it is not, you may need to enter the interconnect subnets on the first screen and check "Accept Filter" next to their entry there.