Re: Duplicate pf rules when using groupname
Actually this is a bit odd, can't reproduce it here on 5.5 or -current.
Re: timer_create for openbsd. Any equivalent ?
Ok, thank you Le mar. 28 avr. 2015 à 01:36, Ted Unangst t...@tedunangst.com a écrit : syphax azmole wrote: Hello list, I have a small C program using standard POSIX timer_create(2), timer_delete(2) and SIGEV_SIGNAL. It seems that OpenBSD doesn't have such API. (and doesn't have librt). I'm curious: why are they not implemented ? For security reason ? they are not easy to implement ? Maybe they are useless ? Most missing features are missing because nobody cared enough to implement them. A fair chunk of the real time extensions fall into that category. What I need to do is to call a function after x milliseconds. What do you suggest me to do ? I suppose there is a simpler and better way than using libevent for that, right ? libevent is probably the simplest. Or a timeout for poll/select whatever you're using.
Re: What bad things could happen if we don't use sudoedit?
On Tue, 28 Apr 2015 07:19:34 +0200, someone wrote: You are perfectly correct, it was ed, not vi and sudoedit could be the solution, thanks. I will try to search the internet how to do the LD_PRELOAD trick with ed. You cannot as LD_PRELOAD only works with dynamic executables and ed is static. The best you could hope to do is monitor it via ptrace(2). It's really a moot point since if you can write to files as root you can trivially get a root shell other ways, such as editing /etc/sudoers. The reason we have sudoedit is that there is no safe way to constrain what an editor run as root can do. - todd
Re: help with bgpd error messages
On Tue, Apr 28, 2015 at 11:28:31AM +0200, Marko Cupa?? wrote: Hi, I have a pair of OpenBSD 5.6 firewalls running releases happily for years (I think since 5.1). They are in CARP failover mode, running bgp sessions with upstrem providers and filtering traffic. Few days ago I had Internet outage (first in years), which appear to happen as a result of bgpd crash. I could ping ISP's interface, but then i noticed i have no routes at all (except connected ones) in routing table. Next, I discovered there is no bgpd running process. Restarting bgpd gave me routes and Internet connectivity back. Here's excerpt from messages log: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Also from daemon log at the same time: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established - Idle, reason: Fatal error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle - Connect, reason: Start Apr 17 18:29:18 bgp2 bgpd[32268]: incremented the demote state of group 'carp' Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect - OpenSent, reason: Connection opened Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent - Active, reason: Connection closed Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Active - Idle, reason: Fatal error Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle - Connect, reason: Start Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect - OpenSent, reason: Connection opened Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent - OpenConfirm, reason: OPEN message received Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenConfirm - Established, reason: KEEPALIVE message received Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[32268]: decremented the demote state of group 'carp' Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established - Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): state change Established - Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: session engine exiting Apr 17 18:29:54 bgp2 bgpd[32268]: kernel routing table 0 (Loc-RIB) decoupled Apr 17 18:29:55 bgp2 bgpd[32268]: Terminating I would be grateful if someone explained me me what happened here, and also what to do in order to avoid it in the future. The fatal in RDE: peer_up: bad state bug is fixed in 5.7 IIRC. Not sure if it was backported to 5.6. As a workaround you can disable the graceful restart capability to not trigger that code path. Hope that helps. -- :wq Claudio
help with bgp error messages
Hi, I have a pair of OpenBSD 5.6 firewalls running releases happily for years (I think since 5.1). They are in CARP failover mode, running bgp sessions with upstrem providers and filtering traffic. Few days ago I had Internet outage (first in years), which appear to happen as a result of bgpd crash. I could ping ISP's interface, but then i noticed i have no routes at all (except connected ones) in routing table. Next, I discovered there is no bgpd running process. Restarting bgpd gave me routes and Internet connectivity back. Here's excerpt from messages log: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Also from daemon log at the same time: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established - Idle, reason: Fatal error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle - Connect, reason: Start Apr 17 18:29:18 bgp2 bgpd[32268]: incremented the demote state of group 'carp' Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect - OpenSent, reason: Connection opened Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent - Active, reason: Connection closed Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Active - Idle, reason: Fatal error Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle - Connect, reason: Start Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect - OpenSent, reason: Connection opened Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent - OpenConfirm, reason: OPEN message received Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenConfirm - Established, reason: KEEPALIVE message received Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[32268]: decremented the demote state of group 'carp' Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established - Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): state change Established - Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: session engine exiting Apr 17 18:29:54 bgp2 bgpd[32268]: kernel routing table 0 (Loc-RIB) decoupled Apr 17 18:29:55 bgp2 bgpd[32268]: Terminating I would be grateful if someone explained me me what happened here, and also what to do in order to avoid it in the future. Thank you in advance, -- Marko Cupać https://www.mimar.rs
Re: How pf chooses nics on bridges?
* Listas IT listas...@dna.uba.ar [2015-04-28 11:25]: We have a 5.6-stable box doing transparent filtering with pf. blog log all is default on ruleset. The bridge is composed of fxp0 and vether0 on int net 192.168.192/23 and xl0 (internet). While doing normal work pflog0 shows this: 06:19:08.497855 rule 17/(match) block in on vether0: 192.168.193.41.3138 77.234.44.65.80: tcp 0 (DF) 06:19:08.546275 rule 17/(match) block in on fxp0: 192.168.193.28.59751 77.234.44.76.443: tcp 0 (DF) 06:19:08.582708 rule 17/(match) block in on fxp0: 192.168.192.146.61276 23.202.94.13.80: tcp 0 (DF) 06:19:08.869587 rule 17/(match) block in on vether0: 192.168.193.12.2103 77.234.44.77.443: tcp 0 (DF) 06:19:08.872942 rule 17/(match) block in on vether0: 192.168.193.12.2104 77.234.42.76.443: tcp 0 (DF) 06:19:09.000769 rule 17/(match) block in on vether0: 192.168.193.41.3138 77.234.44.65.80: tcp 0 (DF) 06:19:09.046083 rule 17/(match) block in on fxp0: 192.168.193.28.59751 77.234.44.76.443: tcp 0 (DF) vether0 is 192.168.192.119 ie in the same net as fxp0 and def gw for the net. There are no static rules for any of those destination sites. Why is it that blocked packets appear sometimes on fxp0 and sometimes on vether0? it's simply the interface the packet came in on. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Duplicate pf rules when using groupname
On 2015-04-27, Brian S. Vangsgaard b...@avalanic.dk wrote: When using interface groupnames in my pf.conf, I see the same rule 4 times when doing a pfctl -s rules. The interface group i'm using, have a vlan and carp member. Ex. pass in on groupA from groupA:network to groupB:network tag A_TO_B It's expanding the address of each member of groupA (which you have as both carp and vlan in the same subnet), and groupB (same). Will produce something like (pfctl -s rules); ... pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B pass in on groupA inet from 1.2.3.0/24 to 5.6.7.0/24 flags S/SA keep state (pflow) tag A_TO_B Using a single interface (ex. vlan) will only produce one line (as I expect it to do) in the pfctl -s rules output. This is probably the simplest fix. The actual packets you want to filter show up on the vlan interfaces anyway. My question is: Why are pf making 4 identical rules when using groupnames? The rule is expanded like this: from carpX:network to carpY:network from carpX:network to vlanY:network from vlanX:network to carpY:network from vlanX:network to vlanY:network So you can see how it happens. There would need to be some extra logic in pfctl to suppress duplicates to avoid this.
Re: streamdvd question
hi,all. streamdvd is like dvdshrink . by streamdvd -hshll script-echo ' input name ' read x VIDEO_FORMAT=NTSC dvdauthor -t -o $x -f 'streamdvd -i /dev/rcd1c -t 1 -s 0xe0,0x81 -f 1.5 |' VIDEO_FORMAT=NTSC dvdauthor -T -o $x
Re: streamdvd question
hi,all. streamdvd is like dvdshrink . by streamdvd -h shll script - echo ' input name ' read x VIDEO_FORMAT=NTSC dvdauthor -t -o $x -f 'streamdvd -i /dev/rcd1c -t 1 -s 0xe0,0x81 -f 1.5 |' VIDEO_FORMAT=NTSC dvdauthor -T -o $x
How pf chooses nics on bridges?
Hello We have a 5.6-stable box doing transparent filtering with pf. blog log all is default on ruleset. The bridge is composed of fxp0 and vether0 on int net 192.168.192/23 and xl0 (internet). While doing normal work pflog0 shows this: 06:19:08.497855 rule 17/(match) block in on vether0: 192.168.193.41.3138 77.234.44.65.80: tcp 0 (DF) 06:19:08.546275 rule 17/(match) block in on fxp0: 192.168.193.28.59751 77.234.44.76.443: tcp 0 (DF) 06:19:08.582708 rule 17/(match) block in on fxp0: 192.168.192.146.61276 23.202.94.13.80: tcp 0 (DF) 06:19:08.869587 rule 17/(match) block in on vether0: 192.168.193.12.2103 77.234.44.77.443: tcp 0 (DF) 06:19:08.872942 rule 17/(match) block in on vether0: 192.168.193.12.2104 77.234.42.76.443: tcp 0 (DF) 06:19:09.000769 rule 17/(match) block in on vether0: 192.168.193.41.3138 77.234.44.65.80: tcp 0 (DF) 06:19:09.046083 rule 17/(match) block in on fxp0: 192.168.193.28.59751 77.234.44.76.443: tcp 0 (DF) vether0 is 192.168.192.119 ie in the same net as fxp0 and def gw for the net. There are no static rules for any of those destination sites. Why is it that blocked packets appear sometimes on fxp0 and sometimes on vether0? Thanks
help with bgpd error messages
Hi, I have a pair of OpenBSD 5.6 firewalls running releases happily for years (I think since 5.1). They are in CARP failover mode, running bgp sessions with upstrem providers and filtering traffic. Few days ago I had Internet outage (first in years), which appear to happen as a result of bgpd crash. I could ping ISP's interface, but then i noticed i have no routes at all (except connected ones) in routing table. Next, I discovered there is no bgpd running process. Restarting bgpd gave me routes and Internet connectivity back. Here's excerpt from messages log: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Also from daemon log at the same time: Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sync error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Header error, synchronization error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, keeping routes Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established - Idle, reason: Fatal error Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle - Connect, reason: Start Apr 17 18:29:18 bgp2 bgpd[32268]: incremented the demote state of group 'carp' Apr 17 18:29:18 bgp2 bgpd[24107]: neighbor 82.117.192.121 (sbb): bad nlri prefix Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect - OpenSent, reason: Connection opened Apr 17 18:29:18 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent - Active, reason: Connection closed Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: error in UPDATE message, network unacceptable Apr 17 18:29:19 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Active - Idle, reason: Fatal error Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Idle - Connect, reason: Start Apr 17 18:29:49 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Connect - OpenSent, reason: Connection opened Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): graceful restart of IPv4 unicast, not restarted, flushing Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenSent - OpenConfirm, reason: OPEN message received Apr 17 18:29:51 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change OpenConfirm - Established, reason: KEEPALIVE message received Apr 17 18:29:52 bgp2 bgpd[24107]: fatal in RDE: peer_up: bad state Apr 17 18:29:52 bgp2 bgpd[32268]: dispatch_imsg in main: pipe closed Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[32268]: decremented the demote state of group 'carp' Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 82.117.192.121 (sbb): state change Established - Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): sending notification: Cease, administratively down Apr 17 18:29:52 bgp2 bgpd[9759]: neighbor 178.253.194.253 (orion): state change Established - Idle, reason: Stop Apr 17 18:29:52 bgp2 bgpd[9759]: session engine exiting Apr 17 18:29:54 bgp2 bgpd[32268]: kernel routing table 0 (Loc-RIB) decoupled Apr 17 18:29:55 bgp2 bgpd[32268]: Terminating I would be grateful if someone explained me me what happened here, and also what to do in order to avoid it in the future. Thank you in advance, -- Marko Cupać https://www.mimar.rs
Re: Duplicate pf rules when using groupname
Stuart Henderson skrev den 2015-04-28 15:55: Actually this is a bit odd, can't reproduce it here on 5.5 or -current. I'm running 5.5 GENERIC.MP SHA256 (/sbin/pfctl) = 9b84b5b3d846cf2f4c4a189d9711cc5d00c4ea096431df4eaea57ebfcd29de8c
Re: How pf chooses nics on bridges?
06:19:08.497855 rule 17/(match) block in on vether0: 192.168.193.41.3138 77.234.44.65.80: tcp 0 (DF) 06:19:08.546275 rule 17/(match) block in on fxp0: 192.168.193.28.59751 77.234.44.76.443: tcp 0 (DF) 06:19:08.582708 rule 17/(match) block in on fxp0: 192.168.192.146.61276 23.202.94.13.80: tcp 0 (DF) 06:19:08.869587 rule 17/(match) block in on vether0: 192.168.193.12.2103 77.234.44.77.443: tcp 0 (DF) 06:19:08.872942 rule 17/(match) block in on vether0: 192.168.193.12.2104 77.234.42.76.443: tcp 0 (DF) 06:19:09.000769 rule 17/(match) block in on vether0: 192.168.193.41.3138 77.234.44.65.80: tcp 0 (DF) 06:19:09.046083 rule 17/(match) block in on fxp0: 192.168.193.28.59751 77.234.44.76.443: tcp 0 (DF) Why is it that blocked packets appear sometimes on fxp0 and sometimes on vether0? it's simply the interface the packet came in on. Thank you. I get that. The question is why sometimes it logs fxp0 and sometimes is vether0 as both are the same physical nic?
Re: Duplicate pf rules when using groupname
Using a single interface (ex. vlan) will only produce one line (as I expect it to do) in the pfctl -s rules output. This is probably the simplest fix. The actual packets you want to filter show up on the vlan interfaces anyway. You'r right, this would be the best solution at the momemnt. My question is: Why are pf making 4 identical rules when using groupnames? The rule is expanded like this: from carpX:network to carpY:network from carpX:network to vlanY:network from vlanX:network to carpY:network from vlanX:network to vlanY:network It all makes sense now, thank you. I actually tried using the -vg option, hoped that I might get some interface details/id(s) attached to the rule. That would have explained it too. But then again, it is not pf's job :) So you can see how it happens. There would need to be some extra logic in pfctl to suppress duplicates to avoid this. Yes, but other programs show it the same way, tried with pftop, it will also display the duplicates.
