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

    PfSense, VPN Gateways and Quagga routing

    Scheduled Pinned Locked Moved Routing and Multi WAN
    4 Posts 3 Posters 2.3k 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.
    • V Offline
      Vetal
      last edited by

      I have following net:

      Where blue and red arrow shows VPN connections.

      Each pfSense box has OpenVPN client.

      VPS A and VPS B running OpenVPN servers which are linking everyone. That's only servers having public IP
      There are RW users and some servers, getting back-end data from some company resources. No speed requirements there, all based on Web-server caching

      There are DNS servers on VPS A and B, kind of TLD DNS for internal net.

      So far it is all working though I facing few problems:
      1. Complex static routing. Lot's of iRoute, push route etc. Hard to add new directions.
      2. Single point of failure problem

      I want to instal Quagga on VPS A, VPS B and every pfSense. As well as to connect VPS A and VPS B with VPN line as well. So everything connected to everything. No NAT on private NETs (as it is now). All access is based on source NET/IP.

      As base line, I took this tutorial:

      http://openmaniak.com/openvpn_routing.php

      So, every pfSense=>VPS link will be replaced by p2p OpenVPN link, since it looks like only working based on data googled.

      The problem is I had no experience with dynamic routing

      In particular, how it s going to look on pfSense? Right now I have a specific rule in the firewall, telling "LAN rules of Company C: if target is Company A LAN, go via OpenVPN, VPS A gateway (== VPN Client)". Specific nets directed via specific gateways.

      Is pfSense quagga going to take this role to itself? Or there is kind of Quagga GW? Since the route is not explicitly defined

      Any thoughts, critics and ideas are welcomed

      Thank you

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

        Did some reading, got the concept,

        https://doc.pfsense.org/index.php/Multi-WAN

        Policy Route Negation

        When a firewall rule directs traffic into the gateway, it bypasses the routing table on the firewall. Policy route negation is just a rule that passes traffic to other local or VPN-connected networks that does not have a gateway set. By not setting a gateway on that rule it will bypass the gateway group and use the routing table on the firewall. These rules should be at the top of the list – or at least above any rules using gateways.

        Always having some kind of Multi-Wan I overlooked this. Setting gateway to "default" works by routing table, which is good

        Though, other thoughts and ideas if OSPF + Quagga is viable solution and right are welcomed

        1 Reply Last reply Reply Quote 0
        • D Offline
          deddey
          last edited by

          Tinc perhaps more suitable for you

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

            quagga does routing not firewalling.

            with quagga you'd need to setup all tunnel networks with openvpn and you DONT push any other routes.
            you setup the vpn-interfaces that quagga needs to run on
            then, basically on each node, you'd have to insert what local subnets you wish to publish (you could choose to publish them all, but this is often not wanted)

            quagga will failover, depending on the cost you give each interface.

            there can be some issues with full mesh in case quagga decides to push tunnel subnets … but that can be worked around if needed

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