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.
    • H
      heper
      last edited by

      Hi all,

      I've been playing around a bit at work and tried to setup something like the attached drawing.
      I've stumbled upon a complication.

      For some reason quagga-ospf "publishes" the tunnel-routes to ALL members, this while i don't think i've configured it like that.
      so for example:

      • Site-C has routes for the tunnel network between A & B

      • Site-C has routes for the tunnel network between B & C

      • Site-C Allready has routes for the tunnel network between A & C - Even before you start the openvpn-service that connects A&C

      This is an issue because you cannot start an openvpn-client/server when the tunnel-network-subnet is a route allready in the routing table.
      The route in the routing table is being "pushed" from the other end of the ospf network.
      I don't see the need for ospf to publish remote tunnel-networks to each member, but i could be mistaken.

      Can someone duplicate this behavior? Is this intended behaviour ?
      Is there any way to solve this? If yes, how ? =)

      Kind Regards,

      Jeroen

      quagga_mesh.png
      quagga_mesh.png_thumb

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

        bump

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

          Some fixes for this were put into 2.0.3 already, but you can try adding the following to your advanced options:

          persist-remote-ip; persist-local-ip;
          

          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
            heper
            last edited by

            sorry for the late responds but i was on holliday

            the persist-remote-ip nor local-ip works …
            it seems something drastically has changed in what routes quagga distributes ... i'm starting to have issues with 2.0.3 release and dual-vpn failover between two sites.
            for whatever reason the tunnel-networks are being distributed and it is screwing things up; this cause the last openvpn deamon to be unable to start because the route is allready there

            syslog:

            Apr 16 23:21:52 	kernel: ovpnc1: link state changed to DOWN
            Apr 16 23:21:52 	kernel: ifa_add_loopback_route: insertion failed
            Apr 16 23:21:52 	kernel: ovpnc1: link state changed to UP
            

            ovpnlog:

            Apr 16 23:21:52 	openvpn[7315]: Exiting
            Apr 16 23:21:52 	openvpn[7315]: FreeBSD ifconfig failed: external program exited with error status: 1
            Apr 16 23:21:52 	openvpn[7315]: /sbin/ifconfig ovpnc1 192.168.99.2 192.168.99.1 mtu 1500 netmask 255.255.255.255 up
            Apr 16 23:21:52 	openvpn[7315]: TUN/TAP device /dev/tun1 opened
            Apr 16 23:21:52 	openvpn[7315]: LZO compression initialized
            Apr 16 23:21:52 	openvpn[7315]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
            Apr 16 23:21:52 	openvpn[7315]: OpenVPN 2.2.2 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013
            

            route is allready there, distributed by quagga from the primary openvpn link between the 2 sites.

            O>* 192.168.99.2/32 [110/100] via 192.168.88.2, ovpns2, 00:05:33
            ``` <– 192.168.88.0 being the primary ovpn-network
            
            please advice
            
            Also note that this exact setup has worked before without any problem ... this started happening after update from 2.0.2 --> 2.0.3-prerelease
            1 Reply Last reply Reply Quote 0
            • H
              heper
              last edited by

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

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

                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.

                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
                • jimpJ
                  jimp Rebel Alliance Developer Netgate
                  last edited by

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

                  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
                    heper
                    last edited by

                    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.

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

                      @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

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

                        I believe I'd already put that into 2.0.3.

                        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
                          heper
                          last edited by

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

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

                            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.

                            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
                              heper
                              last edited by

                              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

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

                                ok try now

                                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
                                  heper
                                  last edited by

                                  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 …

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

                                    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?

                                    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
                                      Reiner030
                                      last edited by

                                      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

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

                                        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.

                                        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
                                          heper
                                          last edited by

                                          @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

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

                                            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 ?

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