On 2016-02-16 16:34, Patrick Lamaiziere wrote:
> Le Tue, 16 Feb 2016 13:05:51 +0100,
> Clemens Goessnitzer a écrit :
>
> Ok I think :
>
> the pf.conf rule
> ### rules for internal network ###
> pass inet proto { tcp, udp } from internal:network to port $udp_services
>
> is expanded to
>
> pa
Le Tue, 16 Feb 2016 13:05:51 +0100,
Clemens Goessnitzer a écrit :
Ok I think :
the pf.conf rule
### rules for internal network ###
pass inet proto { tcp, udp } from internal:network to port $udp_services
is expanded to
pass inet proto udp from 10.0.0.0/24 to any port = 22
pass inet proto udp
Le Tue, 16 Feb 2016 00:10:41 +0100,
Clemens Goessnitzer a écrit :
> Hello misc,
Hi
...
> So, if I specify a group for re1, everything is working as expected.
> However, if re1 is not a member of any group, DHCP request are blocked
> by pf, as tcpdump shows. Is this intended behaviour? Or have
On 2016-02-16 11:17, Patrick Lamaiziere wrote:
> Le Tue, 16 Feb 2016 00:10:41 +0100,
> Clemens Goessnitzer a écrit
>> Hello misc,
>
> Hi
>
Salut!
>
>> So, if I specify a group for re1, everything is working as expected.
>> However, if re1 is not a member of any group, DHCP request are blocke
Hello misc,
I noticed a strange behaviour with pf, when having three interfaces
connected with a bridge(4) device, where two are assigned to the group
wlan and one to no group at all. I have two WLAN interfaces, athn0 and
athn1, and three wired interfaces, re0 to re2. (re2 is not used ATM.)
re0 i
5 matches
Mail list logo