Openvpn - quagga ospf - mesh

tomas1list.ru

Hello - i think i have same problem (http://forum.pfsense.org/index.php?topic=60942.new;topicseen#new) like in this tread - i try to do failover OPENVPN site-to-site tunnel.
I found some instructions on the forum - for setting up the VPN failover scheme. And no one else had similar problems - so that Openvpn demo fails to start- why not all users have this problem?
I tried to apply patches - it did not help me. Is there a 100% solution to this problem?
I use pfsense 2.0.2
thanks.

heper

@tomas1

no solution at the moment. i hope the developers find some spare time to look into this further.

it has worked in the past.
2.0.1 with openospf worked for sure ; 2.0.1 in a mixed environment with quagga & openospf also worked.
around the time i've updated my site's to 2.0.2 - ALL - with quagga i've started to notice some odd behaviour but didn't have the time to worry about it.

Reiner030

Hi,

our setup is working this way…

@Reiner030:

so perhaps for 1st fix it's help to apply the patch only to client side ? I try it at evening again…

server side without patch:
[2.0.3-RELEASE][root@fw1.jws1.local]/root(71): ifconfig ovpns5
ovpns5: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
options=80000 <linkstate>inet6 fe80::225:90ff:fe26:1f22%ovpns5 prefixlen 64 scopeid 0x6e
inet 172.16.4.1 –> 172.16.4.2 netmask 0xffffffff
nd6 options=43 <performnud,accept_rtadv>Opened by PID 57530
[2.0.3-RELEASE][root@fw1.jws1.local]/root(72): grep 172.16 /var/etc/quagga/ospfd.conf
network 172.16.4.0/30 area 192.168.6.0
access-list dnr-list deny 172.16.4.0/24

client side with patch:
[2.1-BETA1][root@fw1.zws8.local]/root(1): ifconfig ovpnc1
ovpnc1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
options=80000 <linkstate>inet6 fe80::225:90ff:fe7a:c489%ovpnc1 prefixlen 64 scopeid 0x44
inet 172.16.4.2 –> 172.16.4.1 netmask 0xffffffff
nd6 options=1 <performnud>Opened by PID 30259
[2.1-BETA1][root@fw1.zws8.local]/root(2): grep 172.16 /var/etc/quagga/ospfd.conf
network 172.16.4.1/32 area 192.168.6.0
access-list dnr-list deny 172.16.4.0/24

so I guess that on both sides it would be better to have not this patch part:

+function quagga_fix_ovpn_peer_ip(&$ip, &$subnet) {
+	if ($subnet == 32) {
+		$baselong = ip2long32($ip) & ip2long32("255.255.255.252");
+		$ip1 = long2ip32($baselong + 1);
+		$ip2 = long2ip32($baselong + 2);
+		if (substr($realif, 4, 1) == "c") {
+			$ip = $ip2;
+		} else {
+			$ip = $ip1;
+		}
+	}
+}
+

but this one:


+function quagga_fix_ovpn_peer_ip(&$ip, &$subnet) {
+	if ($subnet == 32) {
+		$ip = ip2long32($ip) & ip2long32("255.255.255.252");
+	}
+}
+

which can be easily embedded in above if-then-else construct instead of own function if it works ;)</performnud></linkstate></up,pointopoint,running,multicast></performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>

vito

Hi Eveyone,
I will be setting something like this up very soon. (Two sites both with dual WAN/Carp)

Is this problem fixed with or without the patch?
thanks in advance.
vito

Reiner030

for me it's still working with patch on client side, no patch on server side… and since I saw no update for the package itself...

heper

it works for redundant vpn's between 2 sites.

it does not work when making a "triangle" between 3 sites.
I still hope someday some brilliant mind will come up with a solution for this ;)

jimp

Quagga works for doing many sites. I've seen some with half a dozen or more sites on the same "area" doing redundant OSPF+OpenVPN.

heper

I figure the rush to 2.1 is over now and am wondering if there are plans to
improve the way quagga behaves. As it still distributes tunnel networks this causes issues with mesh'd sites.

Reiner030

for completion of this thread/documentation:

final pfSense 2.1 works fine without the Quagga OSPF Patch offered by Jimp in this threat.
Quagga OSPF recognizes its neighbour over OpenVPN only if you use a peer2peer network /30.
No idea why for instance a /24 won't work (I see on both sides HELO packages, but no Quagga OSPF response).

Bests

jimp

If you want to use a /24 you can, but it requires using TAP.

Using a /24 with topology subnet appears to work but for some reason … doesn't. Switching to tap it works fine.

The tunnel networks being distributed is fixed in the newest version of the Quagga package, either check the "accept filter" button on the tunnel interfaces, or add them manually to the main list with 'accept filter' checked.

althornin

Jimp,
I still see this problem, even with the "Accept Filter" checked.
The routes don't show up in the "Quagga OSPF Database" section anymore, but they absolutely still show up in the "Quagga OSPF Router Database", and in the "Quagga OSPF Routes".
This means they are still distributed to the other OSPF clients, at which point, if you have a "triangle" topology, OpenVPN breaks on one leg during ifconfig because it sees a route to the other end of its private tunnel.

heper

@althornin:

Jimp,
I still see this problem, even with the "Accept Filter" checked.
The routes don't show up in the "Quagga OSPF Database" section anymore, but they absolutely still show up in the "Quagga OSPF Router Database", and in the "Quagga OSPF Routes".
This means they are still distributed to the other OSPF clients, at which point, if you have a "triangle" topology, OpenVPN breaks on one leg during ifconfig because it sees a route to the other end of its private tunnel.

you can sort of fix it by manually adding the tunnel IP to the "disable acceptance" list in the global-settings tab of the quagga service.

for example you have a tunnel net of 192.168.22.1/24:
on the server end add to "subnet to route': 192.168.22.1/32 (check disable acceptance)
on the client end add to "subnet to route': 192.168.22.2/32 (check disable acceptance)

do this for all the tunnel subnets on both ends and you won't have the problems with ifconfig.
i know it's a hassle, but its the only way i know, to get the job done

enjoy

jimp

If you keep all of your tunnel networks in a close range you can add a manual accept filter for the entire larger subnet which includes the smaller tunnel networks. For example if you have 192.168.22.0/30, 192.168.22.4/30, 192.168.22.8/30 and so on for tunnel networks, then you can setup an accept filter for 192.168.22.0/24 and I believe that should work OK.