LinuxQuestions.org - [SOLVED] Bridging with PF and rdomains on OpenBSD 6.2-current

- *BSD (https://www.linuxquestions.org/questions/%2Absd-17/)

- - Bridging with PF and rdomains on OpenBSD 6.2-current (https://www.linuxquestions.org/questions/%2Absd-17/bridging-with-pf-and-rdomains-on-openbsd-6-2-current-4175615250/)

Bridging with PF and rdomains on OpenBSD 6.2-current

I've been alternating between two configurations on a router and am now trying to set them up to run concurrently but in different rdomains so as to have two different LANs on the same machine using the different Ethernet ports.

So on each LAN I have physical Ethernet ports. Here is that part of one LAN:

Code:

# cat /etc/hostname.vr[123]  

up description "Part of bridge0" group lana rdomain 2

up description "Part of bridge0" group lana rdomain 2

up description "Part of bridge0" group lana rdomain 2

I can see from ifconfig(8) that they are part of rdomain 2 and groupl lana now.

I also have a virtual Ethernet interface for that LAN on which to hang an IP address:

Code:

# cat /etc/hostname.vether0

rdomain 2

inet 10.111.111.1 255.255.255.0 10.111.111.255

group lana

!route -T2 -n add default 10.222.222.1

up

Then I tie them together using a bridge(4), which used to work prior to setting the rdomain(4).

Code:

# cat /etc/hostname.bridge0                                                    

rdomain 2

group lana

add vether0

add vr1

add vr2

add vr3

blocknonip vether0

blocknonip vr1

blocknonip vr2

blocknonip vr3

up

What happens now is that broadcast packets, from dhclient(8) on a connected host for example, come in on, say, vr3 and reach the bridge0 just fine:

Code:

# route -T2 exec tcpdump -nqpli vr3

tcpdump: listening on vr3, link-type EN10MB

16:44:14.376229 0.0.0.0.68 > 255.255.255.255.67: udp 300 [tos 0x10]

16:44:14.376272 0.0.0.0.68 > 255.255.255.255.67: udp 300 [tos 0x10]

^C

2 packets received by filter

0 packets dropped by kernel

# route -T2 exec tcpdump -nqpli bridge0

tcpdump: listening on bridge0, link-type EN10MB

16:44:33.297587 0.0.0.0.68 > 255.255.255.255.67: udp 300 [tos 0x10]

16:44:33.685594 0.0.0.0.68 > 255.255.255.255.67: udp 300 [tos 0x10]

16:44:34.712752 0.0.0.0.68 > 255.255.255.255.67: udp 300 [tos 0x10]

^C

4 packets received by filter

0 packets dropped by kernel

But they do not reach vether0 any more.

Code:

# route -T2 exec tcpdump -nqpli vether0 

tcpdump: listening on vether0, link-type EN10MB

^C

0 packets received by filter

0 packets dropped by kernel

What have I missed or broken? I would like to use dhcpd(8) off of vether(4) as I used to but only for the Ethernet ports inside rdomain(4) number 2.

If you haven't already seen it, this thread may help.

https://marc.info/?t=149282595600001&r=1&w=2

Thanks. That's a bit different arrangement than I have. For me, vether0 is already inside bridge0. So pair(4) can't be used (I think):

Code:

.-----------------.-----------.    .-----------------.-----------.

|  bridge0        |    vr1    |    |  bridge1        |    vr4    |

| rdomain 2      | rdomain 2 |    | rdomain 3      | rdomain 3 |

|                |  (no ip)  |    |                |  (no ip)  |

|                '-----------'    |                '-----------'

|                |    vr2    |    |                |    vr5    |

|                | rdomain 2 |    |                | rdomain 3 |

.--------------.  |  (no ip)  |    '--------------.  |  (no ip)  |

|  vether0    |  .-----------.    |  vether1    |  '-----------'

|  rdomain 2  |  |    vr3    |    |  rdomain 3  |  |    vr6    |  

|    dhcpd    |  | rdomain 2 |    |    dhcpd    |  | rdomain 3 |

| 10.111.111.1 |  |  (no ip)  |    | 10.333.333.1 |  |  (no ip_  |

'-------^------'--'-----------'    '-------^------'--'-----------'

        |                                  |

        v                                  |

      vr0 <-------------------------------'-------- . . . etc 

    rdomain 0

      dhcp 

  10.222.222.10

        ^

        |

        v

    .-,( ),-.

 .-(        )-.

(    internet  )

 '-(        ).-'

    '--.( ).'

The packets don't seem to be flowing within the bridge itself. In bridge0, vether0 is not getting packets from vr1, etc. Nor is vr1 getting packets from vr2 and so on. Though bridge0 is getting those packets according to tcpdump(8) Maybe I am misunderstanding something about bridge(4).

I don't know enough about routing domains to provide any further recommendations. If no one else steps in, consider posting to the misc@ mailing list.

I'll need to improve my knowledge of logging with PF, going beyond the FAQ and Book of PF, but that is where I am looking right now and have made some progress. I have fairly simply rules and am still having to tweak them to work with the new setup.

Ok. I'm about to call this solved. I have one question about passing UDP packets to/from the bootps/bootpc ports.

I had to update pf.conf in three places. Here are the working values:

Code:

. . .

match out on $ext inet from vether0:network nat-to ($ext)

. . .

pass in quick on rdomain 2 from <leased>        to any set prio (2, 5) rtable 0

. . .

pass in quick on rdomain 2 proto udp from any port bootpc to any port bootps

. . .

That last line was the first hurdle, it seems that the "from any" is needed.

Can or should that be tightened down at all?

I've never tried to "tighten" DHCP addresses, primarily because the protocol uses broad addresses, and I'm either using a portable device (where attaching subnets vary) or I'm using it on trusted networks.

If you want to restrict to permitted subnets and to 0.0.0.0 and 255.255.255.255, you could certainly give it a try.

https://en.wikipedia.org/wiki/Dynami...ation_Protocol

It's possible to pass an interface (without an address) or an rdomain in PF, but it looks like not both. Specifically, these two cannot be combined in the same rule:

Code:

pass in on rdomain 2

pass in on vr2

Maybe it can be done in two steps with tagging or something.

So, I'm going to call this one solved. Everything else is otherwise working.