Only first network of alias is parsed by firewall



  • 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?







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



  • 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?



  • 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)



  • 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



  • 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.



  • 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.



  • @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.



  • 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.


Log in to reply