Quagga Dual-WAN OpenVPN
-
Dear All,
Trying to operate Quagga_OSPF 0.6.13 on pfSense 2.3 with dual-WAN VPN connections using OpenVPN, I would very much welcome some advice.
First, I am well able to link two pfSense devices each with dual-WAN via dual-VPN. One device has LAN 192.168.1.1 and the other 192.168.12.1. Entering the subnet of the respective other device unter “IPv4 Remote network(s)” in the OpenVPN client or server leads to two connections, of which one is in use and represented in the routing table. If that connection fails, the client will change to the other connection, however, this does take some time. Thus, I would like to use Quagga to (a) be able to assign costs to each route for non-random priorities and (b) a faster failover response. My understanding is that Quagga will update the routing table accordingly.
The first issue does occur when starting the device. Unlike with pfSense 2.2, Quagga frequently remains off instead of starting up. The result in the package GUI under “status” is then:
grep: /var/etc/quagga/zebra.conf: No such file or directory
grep: /var/etc/quagga/ospfd.conf: No such file or directory
ospfd does not appear to be runningIndeed, the config files do not exist, unless one does locate the existing configuration in the GUI and one presses “save”. Afterwards, Quagga does start immediately.
I think that I did configure everything necessary (at least in line with chapter 20.13 of the current book, even though I do not know for lack of further documentation).
My assumption is that if Quagga did work, I could remove the entry “IPv4 Remote network(s)” in the OpenVPN configuration and then Quagga would dynamically add the least cost route to the routing table. That, however, does not work. As soon as I remove the OpenVPN entry, there is no LAN-to-LAN connectivity while the VPN connections themselves do still work.
The Quagga OSPF Routes on both sides are as follows – and I think this is plausible:
============ OSPF network routing table ============
N 192.168.1.0/24 [10] area: 0.0.0.0 directly attached to lagg0
N 192.168.12.0/24 [20] area: 0.0.0.0 via 192.168.18.2, ovpns3
N 192.168.18.2/32 [10] area: 0.0.0.0 directly attached to ovpns3
N 192.168.19.2/32 [20] area: 0.0.0.0 directly attached to ovpns4
============ OSPF router routing table =============
============ OSPF external routing table ======================= OSPF network routing table ============
N 192.168.1.0/24 [20] area: 0.0.0.0 via 192.168.18.1, ovpnc2
N 192.168.12.0/24 [10] area: 0.0.0.0 directly attached to lagg0
N 192.168.18.1/32 [10] area: 0.0.0.0 directly attached to ovpnc2
N 192.168.19.1/32 [20] area: 0.0.0.0 directly attached to ovpnc3
============ OSPF router routing table =============
============ OSPF external routing table ===========The Quagga Zebra Routes are as follows (on one side overruled by a similar kernel entry):
O>* 192.168.12.0/24 [110/20] via 192.168.18.2, ovpns3, 00:03:12
O 192.168.1.0/24 [110/20] via 192.168.18.1, ovpnc2, 00:00:12
K>* 192.168.1.0/24 via 192.168.18.1, ovpnc2The system routing table also does contain corresponding routes:
192.168.12.0/24 192.168.18.2 UG1 2111 1500 ovpns3
192.168.1.0/24 192.168.18.1 UGS 5141 1500 ovpnc2
Nevertheless, nothing does ping. I did check “redistribute kernel” and I did enter the remote network under “Subnet to Route”, but with no effect.
What should I try next, please?
Regards,
Michael Schefczyk