Only first network of alias is parsed by firewall

clarknova

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?

eri--

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

clarknova

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?

bardelot

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)

clarknova

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

clarknova

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.

dszp

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.

cmb

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

Efonnes

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.