Navigation

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

    Static routes ignored

    Routing and Multi WAN
    3
    6
    1406
    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
      blackstrap last edited by

      I've recently built myself a little network for learning some of the basics of pfSense firewalling and routing.  The idea is to have a perimeter firewall controlling Internet access, with separate firewalls behind that for controlling access to a DMZ and protected LANs.

      The internal firewalls (fw1 and fw2) have fw0 set as their default gateway, accessible via their route1 interface.  Additionally, fw1 has fw2 as a second gateway on its route1 interface, and static routes to lan1 and lan2 via this gateway.  Likewise, fw2 has fw1 as a second gateway on its route1 interface, with a static route to the DMZ.

      Unfortunately, it seems that my static routes are being ignored.  Example: ping from svr3 to svr1 only works when fw0 is turned on.  This traffic should be routed directly from fw2 to fw1, leaving fw0 out of the loop completely.

      I am pretty sure it has something to do with firewall rules and traffic being sent to the default gateway instead of the gateway specified in the static route.  This thread: https://forum.pfsense.org/index.php?topic=49963.0 seems to be dealing with the same issue.  Accordingly, I have tried creating floating rules to fix the problem, but no luck.  Perhaps I just haven't implemented the rules correctly yet, but I've tried every permutation I can think of with no success.

      Am I on the right track with the floating rules thing, or am I missing something else here?

      1 Reply Last reply Reply Quote 0
      • D
        divsys last edited by

        My first instinct upon seeing your diagram was to ask why 3 firewalls?

        Unless I'm misreading something about your setup (entirely possible) you should be able to do everything you've described with one firewall and three LAN NICS or one LAN NIC and three VLANS plus a VLAN switch.  I'm betting that would drastically simplify your rules and your ability to debug this setup.

        What hardware are you using to implement this?

        1 Reply Last reply Reply Quote 0
        • B
          blackstrap last edited by

          You're right; it would be much simpler with a single firewall.  That's how I initially had it built out, but my company has this thing about "separation of services" and our security guy wanted to see a little more "separation."

          I was asked to start learning about ways to build an inexpensive, secure, modular network that could be easily brought online from backups at a DR site in the event of a failure at the production site.  The whole thing is currently virtual on ESXi.

          1 Reply Last reply Reply Quote 0
          • D
            divsys last edited by

            If you really need to show the separation capabilities, I would do this in multiple stages.  First create the all in one solution and test the various rules you need to isolate all the pieces.  Second, pick one of the three firewalls to separate out and remove that functionality from the integrated firewall and create the new unit to fulfill the functions you need.  Thirdly move out the last piece and test again.

            The advantage of this approach is it's much easier to test a single piece at a time as you convert from integrated to separate firewalls and secondly you'll have examples you can show to the powers that be of the pluses and minuses of each approach.  The entire setup could be done in VM as required (which kind of blows the argument for "separation" of function when all the functions can be virtualized in one machine  ::) )

            Just my $.02

            1 Reply Last reply Reply Quote 0
            • B
              blackstrap last edited by

              OK… so I have taken your strategy and adapted it somewhat.

              I already had the system working with a single pfSense box (dmz, lan1, and lan2 all directly behind fw0), but needed to segregate the functionality a bit.  (Yes, you might argue that it's all running on one machine anyway since it's all virtual, but that's not exactly true -- it's running on a cluster of failover-capable physical servers.  So the separation thing isn't really coming from a concern about hardware reliability, but more out of an interest in keeping the virtual machines -- and the platforms that might be compromised by an attacker -- separate.)

              So from there I broke out the dmz firewall (fw1) and everything worked as expected.  At this point, however, this second firewall still only has one gateway and the default route to get to everything else.

              If I then add fw2 as in the original design, adding the appropriate gateways and routes, I run into the original problem: traffic sent out on the "wan" (route1) interface of fw1 or fw2 uses the default gateway (fw0) instead of the one specified in the static route.

              However, if I add fw2 BEHIND fw1 -- so that all three firewalls are in sequence-- all the routing works as I would expect:

              Again, however, in this scenario, each firewall still only has one gateway per interface.

              You might ask why I don't just use this second design instead of the first, since it works.  My answer is that it is, in my opinion, more complicated, and increases the firewalls' inter-dependency.  I like that in the original design, any one of the three firewalls could be offline, while the other two (and their respective networks) could still function together.

              Which leads me back to my original problem: how do I get traffic to go out the correct gateway when there are multiple gateways on an interface, and simply creating static routes doesn't seem to work?

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

                by implementing security by obscurity one usually ends up with holes in his/her feet

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Products

                • Platform Overview
                • TNSR
                • pfSense
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy