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

    Only first network of alias is parsed by firewall

    2.0-RC Snapshot Feedback and Problems - RETIRED
    6
    9
    2.2k
    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.
    • C
      clarknova
      last edited by

      2.0-BETA4 (i386)
      built on Sun Dec 5 07:23:23 EST 2010
      Platform nanobsd (1g)

      1. Create an alias for RFC1918 and local networks as per the first screenshot.
      2. Make a pair of firewall rules on a local interface as per second screenshot, first to pass all !RFC1918, second to reject all TCP/UDP.
      3. Attempt to telnet to random external 192.168.x.x address from host on local network in question->attempt is rejected as expected.
      4. Attempt to telnet to random external 10.x.x.x or 172.x.x.x address->attempt times out. Reject rule is not working.

      For some reason I'm observing this behaviour on one of my local interfaces (WISP–third screenshot), but not on another (UBNT), and not on the WAN. I updated to the latest firmware (as above) and I'm still seeing the same thing after the reboot.

      Ideas?
      alias.png
      alias.png_thumb
      wisp.png
      wisp.png_thumb
      ubnt.png
      ubnt.png_thumb

      db

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        This is not enogh information to judge.
        Please show your /tmp/rules.debug

        1 Reply Last reply Reply Quote 0
        • C
          clarknova
          last edited by

          ok, but when I open the file in notepad to sanitize it there are no line breaks. Is there a simple way to format it for editing in Windows?

          db

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

            Use Diagnostics -> Command Prompt -> Execute Shell Command

            Execute "cat /tmp/rules.debug"
            and copy output to notepad

            or use an editor that handles the different file endings properly, like Notepad2 (http://www.flos-freeware.ch/notepad2.html)

            1 Reply Last reply Reply Quote 0
            • C
              clarknova
              last edited by

              Thanks.

              And just to verify, it's the pass to !RFC1918 rule that appears to be failing, not the reject all rule that follows it, because I can telnet to the UNCLEAN (172.18.66.254) address from a WISP host, although nothing shows up in the firewall log, and I am logging the first rule.

              rules.debug.txt

              db

              1 Reply Last reply Reply Quote 0
              • C
                clarknova
                last edited by

                Found it. This rule was the culprit:
                pass  in  quick  on {  vr1_vlan102  }  from 192.168.102.254/24 to  ! 192.168.0.0/16 keep state  dnpipe ( 2, 1)  label "USER_RULE: WISP 10/1 mbps limiter (non-local)"

                I didn't think floating rules were parsed before rules on a specific interface. Is this expected behaviour?

                I definitely don't understand why floating rules exist. I changed 192.168.0.0/16 to RFC1918 in that rule and now rejects happen as expected. I think I may be moving all my floating rules onto specific interfaces now.

                db

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

                  I have attempted to understand floating rules a few times but so far have failed to really grasp them. I know they're powerful. I know they're even more complex when messing around with Layer 7 (when it works at all, hopefully soon :-) and QoS, and I think I had the logical concept of how they worked and in what order they were applied in my head at one point, esp. after I asked a clarifying question on the forum here. But now I've forgotten, and I will probably wait for an exceptionally good forum post or a Doc Wiki update describing them with several examples before I have it for good.

                  David Szpunar

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    @clarknova:

                    I didn't think floating rules were parsed before rules on a specific interface. Is this expected behaviour?

                    Yes, that's the main point of them, so you can apply behavior before interface specific rules.

                    1 Reply Last reply Reply Quote 0
                    • E
                      Efonnes
                      last edited by

                      Probably should have a note that they are placed before interface-specific rules.  This is something that is enforced at the code that parses the rules and generates rules.debug (I've looked).

                      A side note – interface groups probably need a clearly defined position where the rules will go.  Currently their placement is simply determined by the name of the interface group.

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