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

    Bypass firewall rule for static routes

    Scheduled Pinned Locked Moved Firewalling
    15 Posts 5 Posters 9.4k 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.
    • F
      fluca1978
      last edited by

      How can I manage static routes since the system does not allow the multi-static routing thru different interfaces? It is not clear to me your solution, could you please explain better?

      1 Reply Last reply Reply Quote 0
      • M
        mericksonj
        last edited by

        Shadow, 
        I think what you're missing is that LAN0 is not an interface on the firewall, so it makes things a bit harder.

        Fluca,

        You've got two separate BSD processes going on here that are going to tell a packet where to go.

        The first is the normal routing process as shown in your routing tables, this is not going to do what you want it to do because there is no mechanism for discriminating which next-hop should be selected from the routing table based on anything the L3 packet header other than destination IP.  It is a rather "dumb" process which will just choose the shortest prefix from its routing table that matches the packets destination and after matching that, forward the packet out the interface (in your case nfe0 which is controlled by that default block you mentioned in the first post).

        The second process here is something akin to (and I'm a newbie here so don't quote me) iptables mangle on Linux.  This will match a packet with some logic (your rules) and evaluate the network and the interface the packet arrived from.  The logic will then adjust it's next-hop action to match what you want done in your rules (policy).

        The limitation here (I think) is that the rules are going to flag interesting vs uninteresting packets and choose the best of these two processes to handle the packet's routing.  The "pass" rule makes the packet uninteresting to the policy and the firewall will forward the packet based on its first process without logic other than basic IP forwarding.

        The "block" rule makes the packet "interesting" to the policy and the firewall will evaluate it and act upon it according to the policy logic you're defining.

        This flagging interesting vs uninteresting may have something to do with the "quick" option in the rule, but as I said I'm new here, my background is in routing not pfsense and I can only guess that the keyword does what i think it does.  someone else can correct me if I'm wrong.

        Hope this helps!
        –James

        1 Reply Last reply Reply Quote 0
        • S
          shadowadepts
          last edited by

          @mericksonj:

          Shadow, 
          I think what you're missing is that LAN0 is not an interface on the firewall, so it makes things a bit harder.

          oh ok my bad. ya ignore that.

          Fluca1978,
          outta curiousity why do you need the two 4/44 networks. there might be a better solution. you may need to configure them differently. could you better explain what your attempting. because there is another method.

          1 Reply Last reply Reply Quote 0
          • F
            fluca1978
            last edited by

            My idea is to have two separated lans to be routed thru the pfsense machine to internet and other networks. It's a kind of double-department setup where each department must be kept separated but must have the same routing decided by the pfsense machine.
            I think the other solution is using vlans,  but that too is causing some problems.
            Suggestions?

            1 Reply Last reply Reply Quote 0
            • M
              mericksonj
              last edited by

              Which direction is your ISP?  Through the 192.168.1.0/24 or via WAN on the Firewall?
              What other networks are involved locally? or is it just the 3 local networks+WAN(ISP)?

              1 Reply Last reply Reply Quote 0
              • F
                fluca1978
                last edited by

                The ISP is connected thru the WAN, while the internal networks are connected only to the 192.168.1.0 (and together).
                Is this wrong?

                1 Reply Last reply Reply Quote 0
                • M
                  mericksonj
                  last edited by

                  Nothing wrong specifically, if you don't have the NICs available on the PFsense for an interface for the 192.168.1.0/24 network, and aren't too concerned about security.

                  It would be Ideal to use the firewall to make the routing decisions, let it be the local router instead of the device you're using now.

                  The router you have between the local subnets now is sort of a weak link in your security scheme; it probably isn't a security device (correct me if I'm wrong).  If you want the best security/control over your three networks, try to get another NIC added to your firewall.

                  Without the PFsense performing true gateway functions for all LAN networks you leave yourself with a hole into 192.168.1.0/24 as well as a back-door into your other networks.  It wouldn't be that difficult for a malicious attacker, if he can sniff your IP numbering and deduce network topology to use local access to either of the 3 networks or a trojan horse running SOCAT/NETCAT-like binary to force its way into your other two networks.

                  If you aren't too concerned about the security, feel free to leave it how it is, the policy with the block (interesting that it's not the pass rule) is apparently doing what you want it to do with the policy-based routing, so you might want to set up both interfaces with a similar rule and leave it at that.

                  1 Reply Last reply Reply Quote 0
                  • S
                    shadowadepts
                    last edited by

                    meric is right. it would be the easiest to just install another card in the pfs box and then pfs box could be your wan end point or just point to another router. by setting up strict firewall rules you can create network isolations or not.

                    1 Reply Last reply Reply Quote 0
                    • P
                      pneumoboy
                      last edited by

                      Maybe coming in a little late, but I have a similar configuration using VLANs without an issue. Basically each subnet is on its own VLAN. For you:

                      192.168.1.0/24 VLAN1
                      192.168.4.0/24 VLAN2
                      192.168.44.0/24 VLAN3

                      Each subnet's default gateway resides on the pfSense box. And each VLAN has its own Firewall ruleset, which you can use to control the traffic between the VLANs. So it is possible to let both 4/44 talk to 1, but 4 cannot talk to 44 and 44 cannot talk to 4.

                      My corp configs use one physical interface for the trunked link (for all the vlans), and one physical interface for management (that is not trunked). No one says you cannot use a trunked link for management, but for sanity (and fat finger mistakes) I keep them separate.

                      1 Reply Last reply Reply Quote 0
                      • M
                        medora
                        last edited by

                        @pneumoboy:

                        Maybe coming in a little late, but I have a similar configuration using VLANs without an issue. Basically each subnet is on its own VLAN. For you:

                        192.168.1.0/24 VLAN1
                        192.168.4.0/24 VLAN2
                        192.168.44.0/24 VLAN3

                        Each subnet's default gateway resides on the pfSense box. And each VLAN has its own Firewall ruleset, which you can use to control the traffic between the VLANs. So it is possible to let both 4/44 talk to 1, but 4 cannot talk to 44 and 44 cannot talk to 4.

                        My corp configs use one physical interface for the trunked link (for all the vlans), and one physical interface for management (that is not trunked). No one says you cannot use a trunked link for management, but for sanity (and fat finger mistakes) I keep them separate.

                        I have this configuration setup, but for me the rules are negated by the "Default deny rule" and any connection to the other VLANs are dropped by the firewall.
                        Any ideas of what  a possible problem is?

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