Openvpn - quagga ospf - mesh

heper

i've looked into this a bit further and found that in the ospfd.conf file on the pfsense's the tunnel networks are there. This is unwanted and unspecified in the webgui.
they are probably automagically by a script on the background.
I'd like someone who is more knowledgeable then me to investigate this.

[# This file was created by the pfSense package manager.  Do not edit!

password *****
interface ovpnc1
  ip ospf cost 100
  ip ospf dead-interval 20
interface ovpns2
  ip ospf cost 50
  ip ospf dead-interval 20
interface ovpns5
interface ovpnc6
  ip ospf authentication-key ******

router ospf
  ospf router-id 10.10.10.1
  network 192.168.88.0/30 area 0.0.0.1    <--tunnel-network
  network 192.168.99.0/30 area 0.0.0.1    <--tunnel-network
  network 192.168.222.0/30 area 0.0.0.1
  network 192.168.224.0/30 area 0.0.0.1
  network 10.10.10.0/24 area 0.0.0.1
  network 10.10.100.0/24 area 0.0.0.1
  network 192.168.77.0/24 area 0.0.0.1
  network 10.10.44.0/24 area 0.0.0.1
  network 192.168.1.0/24 area 0.0.0.1
/code]

quagga.png_thumb

jimp

The network statement is how it's indicated to quagga that it should use that interface for ospf. I'm not sure there is a way to exclude that and still have it attach to the interface properly.

I'd love to be proven wrong though, if you figure out a way around that, I'd be happy to fix the package to work that way.

jimp

Might be a variation on this:
http://www.nongnu.org/quagga/docs/docs-info.html#OSPF-area

heper

i've tried some manual editing the confs without success.

Still this setup has worked since 2.0 beta builds up till a couple of weeks ago … the only option i currently have is to start the vpn tunnels and start quagga afterwards.

This is very troubling because one wrong click and i have to drive 40miles to fix it :(
I hope someone could find a way to solve this.

Thanks in advance and kind regards.

heper

@jimp
would this patch cause any issue's on 2.0.3 ? it's 5 months old so i figured i'd better ask before trying ;)
This appears to be exactly the thing i'm experiencing. Is there an easy fix for the last comment by Johan braeken ?

http://redmine.pfsense.org/issues/2712

thanks in advance

jimp

I believe I'd already put that into 2.0.3.

heper

Thanks for the heads up about the patch jimp.
For whatever reason it does not seem to work in all scenarios on 2.0.3

I've attached a new screenshot; hopefully it contains some clue's to figure out how to get this working properly.
note that my ovpn instances have all been assigned to interfaces and that quagga binds itself to the interfaces and not the ovpn itself.

Thanks in advance.

PF_quagga_redundant_ovpn.png_thumb

jimp

I have an idea on how to fix this, but since I can't replicate it locally, I need a guinea pig to test the fix. Any takers?

With the most current version of the Quagga OSPF package installed, install the System Patches package and apply this patch:

http://files.pfsense.org/jimp/patches/quagga-tun-route-fix.patch
Path Strip: 1
Base: /
Ignore Whitespace: checked

Then edit/save the Quagga OSPF Settings.

heper

patch fetch failed on webgui. When going to that link with browser i get a 403 - Forbidden ; probably needs a 6 somewhere in the chmod ;)

i'll gladly volunteer as i am the one who keeps bothering you with this :D

jimp

ok try now

heper

i haven't had time to fully look into it, but i'm having some odd preliminary results.

when enabling patch on PF1 it stops finding ANY neighbours. yet no errors in quagga webgui. Reverting the patch makes it work again.
i'll try rebooting PF1 after closing time in the next couple of days to see if that resolves it.

when enabling patch on PF2 everything seems to remain functional.

I've also setup another site, lets call it PF3. I've setup a vpn to PF1 and a seperate one to PF2.
without the patch quagga see's both members, with the patch it only see's 1 member. (not sure if this is intended behaviour or not)

i'll investigate further when i find some spare time …

jimp

What OpenVPN role do each of those have? Client? Server?

What did the OSPF status look like on the ones that did work compared to the ones that didn't? Did it show as being attached to the interface?

Reiner030

Hi,

@heper:

i haven't had time to fully look into it, but i'm having some odd preliminary results.

i'll investigate further when i find some spare time …

we need this patch also … I tested it and found out that ospfd.conf wrote for server and client same line for OpenVPN client and server.

network 172.16.4.1/32 area 192.168.6.0

Normally it must be:

server side:
network 172.16.4.2/32 area 192.168.6.0
client side:
network 172.16.4.1/32 area 192.168.6.0

=> I think /guess there is a logical error in your network mask decision because the OpenVPN mask is /30 and not /32 in Openvpn config (but on ovpn interface later)

        if ($subnet == 32) {

but I'm not sure.

Bests

jimp

The mask selection isn't the issue, there's probably a bit of a logic error in the client or server detection, I just haven't had a chance to go back and hack on it. Probably a very simple fix.

heper

@jimp:

What OpenVPN role do each of those have? Client? Server?

What did the OSPF status look like on the ones that did work compared to the ones that didn't? Did it show as being attached to the interface?

It seems WITH patch that only the ovpn-client neighbour is found. without patch both are found.
for more info see pdf's attached. As noted before i do have on 1 point in my mashup of vpn's where no members are found when patch is enabled, this while there are both client as server instances.

if you require more logs/screenshots/… please let me know

Reiner030

ok, next guess ^^

http://blog.milkfarmsoft.com/2007/11/ip2long-32-bit64-bit/
http://forums.phpfreaks.com/topic/254568-bitwise-not-wip2long-32-bit-vs-64-bit-os/

still "buggy"…

=> + $baselong = ip2long32($ip) & ip2long("255.255.255.252");

must be better
=> + $baselong = ip2long32($ip) & ip2long32("255.255.255.252");

I try to check it later when our network is not used…

Must it be the p2p IP/32 or could we not easy add the OpenVPN "network /30" to quagga ?

jimp

It used /30 before, that's the whole problem.

Let me know if the ip2long32 change works. I still haven't had time to go back and try it.

Reiner030

Hi,

I modified the patch and seems that the missing (typo) 32 in the function name is the problem…
Actually I'm running OpenVPN tunnel with quagga routing searching for my next problem ^^
(Nagios checks won't reach/get response when routing over OpenVPN tunnel)

Reiner030

mmh, actually it won't work again…

Perhaps because I need a "separated" OpenVPN tunnel which is bound to an interface (opt12) ...
We have OpenVPN client networks... and one bridge network and want allow all traffic going between the (transfer) bridge network but not from/to the client networks...

jimp

ok I fixed the line in the patch to have ip2long32. I'm not sure about your other question, that may need its own thread since it may not be related to the problem that initiated this discussion.