Re: Unexpected pf behavior for DHCP traffic?
On 19/08/2021 19:01, Stefan Sperling wrote:
Any idea?
I suspect the packets towards vether0 are being dropped by pf.
What does your pf.conf look like?
I have been looking in that direction, and reduced my pf.conf to this:
default_tcp_ports="{ 22 }"
set block-policy return
set skip on lo0
set skip on bridge0
set skip on vether0
anchor tables
block drop # block stateless traffic
pass out# establish keep-state
anchor letsencrypt_traffic
pass in on cnmac2 inet proto icmp from 192.168.1.0/24 to \
( cnmac2 ) keep state
pass in on cnmac2 inet proto tcp from any to \
( cnmac2) port $default_tcp_ports flags S/SA keep state
Do you see anything related in tcpdump -n -i pflog0, provided you've
using 'log' statements on your block rules in pf.conf?
I wasn't, so I switched "block drop" for "block drop log", and I saw the
DHCP requests in the output of "tcpdump -n -i pflog0". First, it puzzled
me that PF was the culprit, when I had specified "set skip" on bridge0
and vether0. Then, I realised I didn't "set skip" on the physical
interfaces of the bridge, cnmac0 and cnmac1.
I still need to adjust things a bit, but thanks already for putting me
on the right track!
--
Étienne
Re: Unexpected pf behavior for DHCP traffic?
On Thu, Aug 19, 2021 at 06:42:25PM +0100, Étienne wrote:
> On 31/07/2021 19:27, Stefan Sperling wrote:
> > On Sat, Jul 31, 2021 at 07:02:35PM +0100, Étienne wrote:
> > > On 30/07/2021 04:37, Theo de Raadt wrote:
> > > > dhcpleased (and a few other daemons) use bpf, thus see raw packets
> > > > from the wire before pf can block them. Most daemons of this type
> > > > also use bpf to send packets, and pf doesn't see these either
> > > Does that prevent dhcpd from listening on any virtual interface? I'm
> > > trying
> > > to have it listen for requests on a vether in a bridge, and that fails (or
> > > I'm making a mistake).
> >
> > It should work, unless are running dhclient/dhcpleased on the same machine,
> > because the bpf filter will eat DHCP-related packets. You'll know whether
> > this affects you by checking whether dhcpd starts working when you kill the
> > DHCP client.
>
> Thanks for your help, Stefan, and sorry for coming back so late on that.
> Despite the tip, I'm afraid it doesn't work.
>
> I have two Ubiquiti EdgerouterLite running 6.9, these boxes have 3
> interfaces cnmac0, cnmac1 and cnmac2. I bridge cnmac0 and cnmac1, and I
> connect cnmac0 on both boxes to one switch, and cnmac1 on both boxes to
> another switch. I turn RSTP on all these interfaces and on the switches, add
> a vether0 with an IP address (in 172.16.0.0/16) in bridge0 on either box,
> and I have connectivity.
>
> I also configure an IP address on cnmac2 (in 192.168.1.0/24). Then I
> configure dhcpd to listen on cnmac2 and on vether0:
>
> dhcpd_flags=-y vether0 -Y vether0 vether0 cnmac2
>
> With this setup, I see DHCP leases added in the 192.168.1.0 range, but none
> in the 172.16.0.0 range. Moreover, I see DHCP requests when running tcpdump
> on bridge0, but not on vether0. So I'm not sure what's preventing it to
> work.
>
> My configuration files content:
>
> % cat /etc/hostname.cnmac0
> up
> % cat /etc/hostname.cnmac1
> up
> % cat /etc/hostname.cnmac2
> inet 192.168.1.4 255.255.255.0 NONE
> !route add 0.0.0.0/0 192.168.1.254
> inet6 autoconf
> up
> % cat /etc/hostname.vether0
> lladdr fe:e1:ba:d0:be:d3
> inet 172.16.0.4 255.255.255.0
> up
> % cat /etc/hostname.bridge0
> add cnmac0
> stp cnmac0
> add cnmac1
> stp cnmac1
> add vether0
> maxaddr 1000
> timeout 40
> up
> % cat /etc/dhcpd.conf
>
> option domain-name-servers 192.168.1.254;
> default-lease-time 14400;
> max-lease-time 86400;
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> option routers 192.168.1.254;
>
> range 192.168.1.16 192.168.1.126;
> }
>
> subnet 172.16.0.0 netmask 255.255.255.0 {
> option routers 172.16.0.1;
>
> range 172.16.0.16 172.16.0.126;
> }
>
> Running tcpdump shows this:
>
> % doas tcpdump -ve -i bridge0 "port 67 or port 68"
> tcpdump: listening on bridge0, link-type EN10MB
> 19:16:57.596572 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1120 [|bootp] (ttl 64, id 0,
> len 328)
> 19:17:00.597025 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1123 [|bootp] (ttl 64, id 0,
> len 328)
> 19:17:03.600246 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1126 [|bootp] (ttl 64, id 0,
> len 328)
> […]
> 19:17:42.630441 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
> 255.255.255.255.bootps: xid:0x10e264ab secs:1165 [|bootp] (ttl 64, id 0,
> len 328)
> ^C
> 74 packets received by filter
> 0 packets dropped by kernel
> % doas tcpdump -ve -i vether0 "port 67 or port 68"
> tcpdump: listening on vether0, link-type EN10MB
> ^C
> 1320 packets received by filter
> 0 packets dropped by kernel
>
> Any idea?
I suspect the packets towards vether0 are being dropped by pf.
What does your pf.conf look like?
Do you see anything related in tcpdump -n -i pflog0, provided you've
using 'log' statements on your block rules in pf.conf?
Does adding this as the final rule help?
pass on bridge0 no state
Re: Unexpected pf behavior for DHCP traffic?
On 31/07/2021 19:27, Stefan Sperling wrote:
On Sat, Jul 31, 2021 at 07:02:35PM +0100, Étienne wrote:
On 30/07/2021 04:37, Theo de Raadt wrote:
dhcpleased (and a few other daemons) use bpf, thus see raw packets
from the wire before pf can block them. Most daemons of this type
also use bpf to send packets, and pf doesn't see these either
Does that prevent dhcpd from listening on any virtual interface? I'm trying
to have it listen for requests on a vether in a bridge, and that fails (or
I'm making a mistake).
It should work, unless are running dhclient/dhcpleased on the same machine,
because the bpf filter will eat DHCP-related packets. You'll know whether
this affects you by checking whether dhcpd starts working when you kill the
DHCP client.
Thanks for your help, Stefan, and sorry for coming back so late on that.
Despite the tip, I'm afraid it doesn't work.
I have two Ubiquiti EdgerouterLite running 6.9, these boxes have 3
interfaces cnmac0, cnmac1 and cnmac2. I bridge cnmac0 and cnmac1, and I
connect cnmac0 on both boxes to one switch, and cnmac1 on both boxes to
another switch. I turn RSTP on all these interfaces and on the switches,
add a vether0 with an IP address (in 172.16.0.0/16) in bridge0 on either
box, and I have connectivity.
I also configure an IP address on cnmac2 (in 192.168.1.0/24). Then I
configure dhcpd to listen on cnmac2 and on vether0:
dhcpd_flags=-y vether0 -Y vether0 vether0 cnmac2
With this setup, I see DHCP leases added in the 192.168.1.0 range, but
none in the 172.16.0.0 range. Moreover, I see DHCP requests when running
tcpdump on bridge0, but not on vether0. So I'm not sure what's
preventing it to work.
My configuration files content:
% cat /etc/hostname.cnmac0
up
% cat /etc/hostname.cnmac1
up
% cat /etc/hostname.cnmac2
inet 192.168.1.4 255.255.255.0 NONE
!route add 0.0.0.0/0 192.168.1.254
inet6 autoconf
up
% cat /etc/hostname.vether0
lladdr fe:e1:ba:d0:be:d3
inet 172.16.0.4 255.255.255.0
up
% cat /etc/hostname.bridge0
add cnmac0
stp cnmac0
add cnmac1
stp cnmac1
add vether0
maxaddr 1000
timeout 40
up
% cat /etc/dhcpd.conf
option domain-name-servers 192.168.1.254;
default-lease-time 14400;
max-lease-time 86400;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
range 192.168.1.16 192.168.1.126;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
option routers 172.16.0.1;
range 172.16.0.16 172.16.0.126;
}
Running tcpdump shows this:
% doas tcpdump -ve -i bridge0 "port 67 or port 68"
tcpdump: listening on bridge0, link-type EN10MB
19:16:57.596572 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1120 [|bootp] (ttl 64, id
0, len 328)
19:17:00.597025 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1123 [|bootp] (ttl 64, id
0, len 328)
19:17:03.600246 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1126 [|bootp] (ttl 64, id
0, len 328)
[…]
19:17:42.630441 00:17:88:61:85:5a Broadcast ip 342: 0.0.0.0.bootpc >
255.255.255.255.bootps: xid:0x10e264ab secs:1165 [|bootp] (ttl 64, id
0, len 328)
^C
74 packets received by filter
0 packets dropped by kernel
% doas tcpdump -ve -i vether0 "port 67 or port 68"
tcpdump: listening on vether0, link-type EN10MB
^C
1320 packets received by filter
0 packets dropped by kernel
Any idea?
--
Étienne
