pf and tap(4) interfaces

[tech-lists]

Hello,

On Tue, Oct 13, 2020 at 08:26:23PM +0300, Oleksandr Kryvulia wrote:
>>
>> [snip]
>> block all
>> pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22
>> pass in quick on $tap_if inet proto tcp from any to ($tap_if)
>>
>> thanks,
>
>External traffic to your tap interface arrives through ix0. So you need
>to change a third rule:
>
>block all
>pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22
>pass in quick on $ext_if inet proto tcp from any to ($tap_if)
>
>Also check net.link.bridge.pfil_member=1

Unfortunately this suggestion didn't work for me, but thanks for
suggesting. It ends up blocking everything to the vm. 

I should also have mentioned my full context originally: 
What I have in this instance is a freebsd host running a freebsd 
vm through bhyve. Both the host and the vm have real ips. 
The vm wants full access as it has its own pf within itself. 

The host wants ssh open and no more. I can lock down the ssh server on
the host with sshd_config plus some additions to sysctl.conf, without
involving pf at all. I just wondered if I can do it with pf on the 
host. I'm surprised there's no mention of this type of config in 
the handbook. I would have thought it was common?

I've also tried
set skip on $tap_if

to no effect, in that if I apply this (but have the allow only ssh to
$ext_if), then I can't access the vm on the vm's open ports. Clearly I'm
doing something wrong.

>As for me I prefer to have  all IPs and filter it on bridge interface and
>not on members.

How do you do that? It's probably (if I understand correctly) not for me
because I'm using bhyve, and $ext_if and $tap_if are both members and
they need different access. But I'd be interested how you're filtering
on the bridge interface.

-- 
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20201014/29141ff5/attachment.sig>