Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Openvpn - quagga ospf - mesh

    Scheduled Pinned Locked Moved General pfSense Questions
    40 Posts 6 Posters 23.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jimpJ Offline
      jimp Rebel Alliance Developer Netgate
      last edited by

      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.

      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      1 Reply Last reply Reply Quote 0
      • R Offline
        Reiner030
        last edited by

        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)

        1 Reply Last reply Reply Quote 0
        • R Offline
          Reiner030
          last edited by

          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...

          1 Reply Last reply Reply Quote 0
          • jimpJ Offline
            jimp Rebel Alliance Developer Netgate
            last edited by

            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.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • R Offline
              Reiner030
              last edited by

              Hi yes, could be perhaps another thread/problem…
              Only the idea / nice to have that this patch can fix both scenarios if possible ;)

              I tested before and got stable OpenVPN tunnel... with quagga routing/traffic.

              Then I setup like this to filter traffic separately per tunnel:
              http://doc.pfsense.org/index.php/Can_I_filter_OpenVPN_traffic%3F#Assign_OpenVPN_interface_as_OPT

              but now get wrong IP in server back and quagga is disables on my server interface again:
                network 172.16.4.1/32 area 192.168.6.0

              1 Reply Last reply Reply Quote 0
              • H Offline
                heper
                last edited by

                @reiner030 so you have found that it works on a tunnel but stops working when you assign an interface to the tunnel ?

                I just confirmed that members are can only be found on ovpn-client side of the tunnel.

                situation:

                ovpns_A  –-----interwebs--------- ovpnc_A
                ovpnc_B  -------interwebs--------- ovpns_B

                if patch is enabled on both ends: no members found by "left" nor "right"
                if patch is enabled on the "left" side but not the "right": 1 member is found on the B-connection
                if patch is enabled on the "right" side but not the "left": 1 member is found on the A-connection

                do note that all vpn's have been assigned an interface and quagga is bound on the interfaces

                hope this makes sense somehow ;)

                1 Reply Last reply Reply Quote 0
                • R Offline
                  Reiner030
                  last edited by

                  mmh, not sure ..
                  Yesterday it works for me but perhaps only because my server side was not restarted and my manually fix in the quagga config was still available.
                  Ssince yesterday evening it won't work again as written so it could be the "old" problem and not my bridge try…

                  Make sense when taking a look onto interfaces... the OpenVPN tunnel => Interface assigning makes no difference to my interface definition itself:

                  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 3002

                  so perhaps for 1st fix it's help to apply the patch only to client side ? I try it at evening again…</performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast>

                  1 Reply Last reply Reply Quote 0
                  • T Offline
                    tomas1list.ru
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • H Offline
                      heper
                      last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • R Offline
                        Reiner030
                        last edited by

                        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>

                        1 Reply Last reply Reply Quote 0
                        • V Offline
                          vito
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • R Offline
                            Reiner030
                            last edited by

                            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...

                            1 Reply Last reply Reply Quote 0
                            • H Offline
                              heper
                              last edited by

                              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 ;)

                              1 Reply Last reply Reply Quote 0
                              • jimpJ Offline
                                jimp Rebel Alliance Developer Netgate
                                last edited by

                                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.

                                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                Need help fast? Netgate Global Support!

                                Do not Chat/PM for help!

                                1 Reply Last reply Reply Quote 0
                                • H Offline
                                  heper
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • R Offline
                                    Reiner030
                                    last edited by

                                    for completion of this thread/documentation:

                                    1. final pfSense 2.1 works fine without the Quagga OSPF Patch offered by Jimp in this threat.
                                    2. 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

                                    1 Reply Last reply Reply Quote 0
                                    • jimpJ Offline
                                      jimp Rebel Alliance Developer Netgate
                                      last edited by

                                      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.

                                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                      Need help fast? Netgate Global Support!

                                      Do not Chat/PM for help!

                                      1 Reply Last reply Reply Quote 0
                                      • A Offline
                                        althornin
                                        last edited by

                                        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.

                                        1 Reply Last reply Reply Quote 0
                                        • H Offline
                                          heper
                                          last edited by

                                          @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

                                          1 Reply Last reply Reply Quote 0
                                          • jimpJ Offline
                                            jimp Rebel Alliance Developer Netgate
                                            last edited by

                                            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.

                                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                            Need help fast? Netgate Global Support!

                                            Do not Chat/PM for help!

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.