bridge rules are evaluated different compared to pf?
Good day! I hope someone could clarify if the following behavior is expected in a bridge configuration I have following rules added in hostname.bridge0 --- #this will result out to be blocked rule block in on vic0 rule block out on vic0 rule pass out on vic0 #this will result out to be passed #rule block in on vic0 #rule pass out on vic0 #rule block out on vic0 As you see in comments the uncommented section will block out traffic and second section will let it pass it. Somehow these rules behaves like rules added to pf but with 'quick' keyword. So I deduce that a catch all policy must be added last and not first like in pf In manpage of ifconfig I see this: "Rules are processed in the order in which they were added to the interface" So I believe it makes sense the behavior but I just want to confirm with you this behavior as I read in a book(Building Firewalls With OpenBSD And PF) the opposite: "rule block out on ne1 rule pass out on ne1 src 00:00:00:00:00:01 rule pass out on ne1 src 00:00:00:00:00:02 rule pass out on ne1 src 00:00:00:00:00:03 Please note that the last matching rule wins, hence the global block or pass rule should be listed before more specific rules." I would like to understand if the book has a mistake or I do something wrong. Thank you.
Re: bridge rules are evaluated different compared to pf?
On Tue, Jul 26, 2022 at 11:18:06AM +0300, Cristian Danila wrote: > Good day! > I hope someone could clarify if the following behavior is > expected in a bridge configuration > I have following rules added in hostname.bridge0 > > --- > #this will result out to be blocked > rule block in on vic0 > rule block out on vic0 > rule pass out on vic0 > > #this will result out to be passed > #rule block in on vic0 > #rule pass out on vic0 > #rule block out on vic0 > > As you see in comments the uncommented section will block out > traffic and second section will let it pass it. Somehow these > rules behaves like rules added to pf but with 'quick' keyword. > So I deduce that a catch all policy must be added last and not > first like in pf > > In manpage of ifconfig I see this: > "Rules are processed in the order in which they were added to > the interface" > So I believe it makes sense the behavior but I just want to > confirm with you this behavior as I read in a book(Building > Firewalls With OpenBSD And PF) the opposite: > > "rule block out on ne1 > rule pass out on ne1 src 00:00:00:00:00:01 > rule pass out on ne1 src 00:00:00:00:00:02 > rule pass out on ne1 src 00:00:00:00:00:03 > Please note that the last matching rule wins, hence the > global block or pass rule should be listed before more > specific rules." > > I would like to understand if the book has a mistake or I do > something wrong. The manpage actually has a bit more: Rules are processed in the order in which they were added to the interface. The first rule matched takes the action ... So the book got this wrong. bridge(4) uses a first match logic unlike pf(4) where last match is the default. -- :wq Claudio
Re: bridge rules are evaluated different compared to pf?
Thank you for info, I was confused by the book. Happy to see this is the intended behavior. Kind regards, Claudiu On Tue, Jul 26, 2022, 11:36 Claudio Jeker wrote: > On Tue, Jul 26, 2022 at 11:18:06AM +0300, Cristian Danila wrote: > > Good day! > > I hope someone could clarify if the following behavior is > > expected in a bridge configuration > > I have following rules added in hostname.bridge0 > > > > --- > > #this will result out to be blocked > > rule block in on vic0 > > rule block out on vic0 > > rule pass out on vic0 > > > > #this will result out to be passed > > #rule block in on vic0 > > #rule pass out on vic0 > > #rule block out on vic0 > > > > As you see in comments the uncommented section will block out > > traffic and second section will let it pass it. Somehow these > > rules behaves like rules added to pf but with 'quick' keyword. > > So I deduce that a catch all policy must be added last and not > > first like in pf > > > > In manpage of ifconfig I see this: > > "Rules are processed in the order in which they were added to > > the interface" > > So I believe it makes sense the behavior but I just want to > > confirm with you this behavior as I read in a book(Building > > Firewalls With OpenBSD And PF) the opposite: > > > > "rule block out on ne1 > > rule pass out on ne1 src 00:00:00:00:00:01 > > rule pass out on ne1 src 00:00:00:00:00:02 > > rule pass out on ne1 src 00:00:00:00:00:03 > > Please note that the last matching rule wins, hence the > > global block or pass rule should be listed before more > > specific rules." > > > > I would like to understand if the book has a mistake or I do > > something wrong. > > The manpage actually has a bit more: > Rules are processed in the order in which they were added to > the > interface. The first rule matched takes the action ... > > So the book got this wrong. bridge(4) uses a first match logic unlike > pf(4) where last match is the default. > > -- > :wq Claudio > >
Re: doas and args matching
Chris Narkiewicz writes:
Is it possible to match command arguments against an expression
in
doas.conf?
I'd like to allow user to run wsconsctl
display.brightness=<0-100> and
the only solution i found so far is to explicitly put all values
in
doas.conf.
Since no-one has yet offered any better suggestions: perhaps you
could write a wrapper script that can be called without arguments,
and instead takes the brightness value from stdin? E.g. something
like:
$ echo 50 | doas /usr/local/bin/my-wrapper
where my-wrapper is something like:
#!/bin/ksh
IFS=
read -u VAL
wsconsctl display.brightness=${VAL}
(Obviously the script should check that VAL is an appropriate
value.)
Alexis.
Blocking ARP packet for specific MAC
Good day! I've been having a headache for days(I still fight, no success yet) in trying to find a way to block ARP for specific MAC address(example 00:50:56:c0:00:08). I want to see how I can achieve this on OpenBSD, I would appreciate a technical answer or a hint/site/doc/book where I can research more to expand my knowledge. I've tried lot of combinations on config, many lookups over the internet and I was not able to find an answer yet. This is what I've found and tried. OpenBSD can filter level 2 traffic only if the interface is part of a BRIDGE. By adding it to a bridge it put it in promiscuous mode so that it can receive every packet sent on the network. So by having this requirement I have hostname.bridge0 ---hostname.vic0 inet autoconf up ---hostname.bridge0 #add my network card to bridge add vic0 blocknonip vic0 rule block in on vic0 rule block out on vic0 src 00:50:56:c0:00:08 rule block out on vic0 dst 00:50:56:c0:00:08 up --- now I reboot and expect to see the packets blocked for 00:50:56:c0:00:08 However these are not blocked and here is the log: 00:50:56:c0:00:08 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.121.131 tell 102.168.121.1 00:50:56:c0:00:08 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.121.131 tell 102.168.121.1 00:0c:29:c3:d9:a7 00:50:56:c0:00:08 0806 60: arp reply 192.168.121.131 is-at 00:0c:29:c4:d9:a7 So I see a success request/response for 00:50:56:c0:00:08 I would appreciate any help. Kind Regards, Claudiu
Re: Mouse forward/back buttons same as scroll wheel
You are probably right. I'm still learning what's what with this. I have never dabbled with this sort of stuff before. It appears I may have been warm because I see I had looked at this once before. So then, if my scroll wheel and the forward/back buttons are 4 and 5, would that mean that those are perhaps the logical mappings? I'll have to see how I can find the physical mappings. Thank you On 7/23/22 20:22, Stuart Longland wrote: On Thu, 21 Jul 2022 18:12:49 -0700 Courtney wrote: I have learned that the forward/back buttons (4,5) are the same as scroll in OpenBSD. I thought 4 and 5 _was_ the scroll wheel… years ago I had a mouse that featured 5 discrete buttons and scroll wheel, wheel was 4 and 5, the extra buttons on the side were mapped as 6 and 7. http://man.openbsd.org/mouse#Option~17 might provide some clues too, assuming this is in X.
pppoe problems
Hello misc@ I installed 7.1-release to an edgerouter-lite-3 (mips64, octeon). In the errata, I saw there was a security fix https://ftp.openbsd.org/pub/OpenBSD/patches/7.1/common/005_pppoe.patch.sig which was especially pertinent as this is a router. So, cvs-uped to 7.1-stable and built the kernel from those sources as mips64 isn't supported with syspatch. It installed fine, boots up fine. The problem is that I can't get pppoe to work. Before seeing if it's an issue with pppoe, what I'd like to know is, should I have also rebuilt the userland? The reason I didn't in the first place is that the pppoe patch mentions rebuilding/installing the kernel only, and building the userland will take an age on this hardware. Was just building and installing a new kernel incorrect, in this context? thanks in advance for any clarification
