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

PFSense ignoring OSPF and static route on routing table

Scheduled Pinned Locked Moved Routing and Multi WAN
9 Posts 2 Posters 4.7k 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.
  • B
    barbosa.rodolfo
    last edited by Nov 24, 2014, 3:07 PM

    Hi Guys,

    I'm implementing a network with the following architecture:

    – 1 routing running PFSense on HQ;
    -- 12 routes running Mikrotik's RouterOS on branches.

    My goal is connect all the 12 routers running Mikrotik's RouterOS to the PFSense box through OpenVPN connections and use OSPF to route the LAN of each branch to access the LAN of HQ.

    After config the OpenVPN tunnels and implement a OSPF cloud I'm facing the following problem:
    Although the routing table of PFSense box has the OSPF routes to the branches' LANs, every packet from HQ LAN to any branch LAN is being forwarded throughout HQ's PFSense default route and not by the dynamic route installed on the routing table by OSPF. I ran out off alternatives of testing and debugging that's way I ask for your help. Is there any else that I can or would do?

    Thank's,
    Rod Barbosa

    1 Reply Last reply Reply Quote 0
    • H
      heper
      last edited by Nov 24, 2014, 5:00 PM

      why would traffic go out the default GW when there is a route for the subnet on the pfsense? that doesn't make much sense. does the ospf-route get added the the pfsense routing table ?

      could you draw a schematic with all the subnet's on it? also might want to include the various routing tables/traceroutes/… to help us understand what exactly is going on

      1 Reply Last reply Reply Quote 0
      • B
        barbosa.rodolfo
        last edited by Nov 25, 2014, 1:39 AM Nov 25, 2014, 1:33 AM

        Hi,

        The following images are:
        – network schematics;
        -- routing table from HQ PFSense;
        --  traceroute from HQ PFSense to Branch26 LAN address;
        -- routing table of our Brach26 router OS;
        -- traceroute from Branch26 OVPN tunnel address to HQ PFSense LAN address;
        -- traceroute from Branch26 LAN address to HQ PFSense LAN address;
        -- and traceroute from Brach26 LAN address to HQ PFSense OVPN tunnel address.

        If You pay attention to third line of traceroute from HP PFSense to Branch26 LAN address You can see that the response address is our WAN address 200.195.70.206. That's why I said in the previous post that our PFSense box is routing packages to Branches network through the default gateway.

        On the sixth picture You can see that a traceroute from Branch26 OVPN tunnel address to the HQ's PFSense LAN address is successful. After that and other testes I realized that the PFSense box routes only direct connected routes properly, every network that needs another hop to be reached it keeps sending packages through default route.

        Thank's
        Rod Barbosa

        NetworkDiagram.jpg
        NetworkDiagram.jpg_thumb
        HQ_PFSense_RouteTable-Part1.png
        HQ_PFSense_RouteTable-Part1.png_thumb
        HQ_PFSense_RouteTable-Part2.png
        HQ_PFSense_RouteTable-Part2.png_thumb
        HQ_PFSense-Traceroute.png
        HQ_PFSense-Traceroute.png_thumb
        Branch26-RoutingTable.png
        Branch26-RoutingTable.png_thumb
        Traceroute-FROM_OVPN-Branch26_TO_LAN-HQ.png
        Traceroute-FROM_OVPN-Branch26_TO_LAN-HQ.png_thumb
        Traceroute_FROM_BRANCH26-LAN_TO_HQ-OVPN.png
        Traceroute_FROM_BRANCH26-LAN_TO_HQ-OVPN.png_thumb
        Traceroute_FROM_Branch26-LAN_TO_HQ-LAN.png
        Traceroute_FROM_Branch26-LAN_TO_HQ-LAN.png_thumb

        1 Reply Last reply Reply Quote 0
        • H
          heper
          last edited by Nov 25, 2014, 8:19 AM

          i'm seeing some strangeness (when comparing to similar setups of mine). I do have to say, that i always assign interfaces to my openvpn-connections … but that should not make a difference AFAIK.
          strangeness:
          branch_routing_table:
          -multiple routes for conflicting subnets (192.168.26.0/24 –> ether2 ; 192.168.26.0/29 --> 10.240.26.1 ; ether2-route has lower cost)
          -is there a reason you are "publishing" the tunnel networks of other tunnels ? (don't see any harm in it, but seems pointless)

          HQ pfsense
          On my pfsense systems my routing tables never show the tunnel networks of the openvpn. ( no /29 routes even though i also use the same tunnel-subnet)
          This might be because i assign interface to all openvpn-connection or ???
          Perhaps they are being published by ospf and picked up by pfsense ?

          I'm just pointing out differences, not sure if anything will help to get your setup working or not ;)

          snippet of my routing table attached to this post

          enjoy

          rtable.png
          rtable.png_thumb

          1 Reply Last reply Reply Quote 0
          • B
            barbosa.rodolfo
            last edited by Nov 26, 2014, 11:43 AM

            Guys,

            After spending more time studding  the matter I realize the this is not a routing problem.

            For some reason packets coming from or send out to any non direct connected network of our PFSense Box are not passing through OpenVPN tunnel. I still don't know what is causing this, I just suspect that is a incompatibility between OpenVPN implementation or Mikrotik's RouterOS and PFSense.

            Thank's for your help!
            Rod Barbosa

            1 Reply Last reply Reply Quote 0
            • H
              heper
              last edited by Nov 26, 2014, 12:20 PM

              perhaps you are using policy routing somewhere?

              1 Reply Last reply Reply Quote 0
              • B
                barbosa.rodolfo
                last edited by Nov 27, 2014, 1:22 AM

                I don't think so. I had never heard about policy routing before.

                1 Reply Last reply Reply Quote 0
                • B
                  barbosa.rodolfo
                  last edited by Nov 27, 2014, 1:29 AM

                  I forgot to mention that I have made a test replacing a OpenVPN connection to a ethernet connect (I took a branch Mikrotik router to HQ Data Center) and no problem on routing networks was found. OSPF routing and static routes worked well. I talk about the matter on a Mikrotik Forum and we think there is some bug on Mikrotik's implementation of OpenVPN.

                  Thank's
                  Rod Barbosa

                  1 Reply Last reply Reply Quote 0
                  • H
                    heper
                    last edited by Nov 27, 2014, 7:32 AM

                    @barbosa.rodolfo:

                    I don't think so. I had never heard about policy routing before.

                    What is policy routing

                    Policy routing in pfSense refers to the capability of routing traffic by matching it to specific firewall rules. Each firewall rule allows selection of a gateway. If none is selected, traffic goes out the default gatway or follows the routing table. If additional WAN interfaces (OPT WAN) or gateway groups are defined, these may be selected in the Gateway field when adding or editing rules to direct matching traffic as desired. This is primary used for multi-WAN, though it has other uses as well.

                    https://doc.pfsense.org/index.php/What_is_policy_routing
                    https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

                    1 Reply Last reply Reply Quote 0
                    9 out of 9
                    • First post
                      9/9
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                      This community forum collects and processes your personal information.
                      consent.not_received