Re: pf and tap(4) interfaces
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. signature.asc Description: PGP signature
Re: Packets passed by pf don't make it out?
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote: Hello, now I can confirm (on FreeBSD 10 Stable) what you see on fb2 when your program udp_client is running on fb1. pf creates a state for the first packet only, for the other packets pf failes to create a state with messages like pf: stack key attach failed on re0: UDP in wire: 192.168.14.10:23456 172.16.0.2:12345 stack: 192.168.14.10:23456 192.168.14.100:12345 1:0, existing: UDP in wire: 192.168.14.10:23456 172.16.0.1:12345 stack: 192.168.14.10:23456 192.168.14.100:12345 1:0 pf gives this messages in debug mode (pfctl -x loud). I do not know if we see a bug in pf or if your program udp_client does something illegal, I think Kristof can tell us. Your confidence is both flattering and misplaced :) I think I can reproduce the problem on CURRENT and with VNET jails, which is convenient. I see the same ‘stack key attach failed’ error message. My current thinking is that we’re hitting a state collision, because post-RDR our connection information is the same (192.168.14.10:23456 192.168.14.100:12345). That means we can’t create a new state, and the packet gets dropped. It’s a little unusual for a client to keep re-using src ports like that, but it’s not actually wrong. I’m not sure how we can fix this. Best, Kristof ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: pf and tap(4) interfaces
On 13.10.20 19:07, tech-lists wrote: > Hi, > > Is it possible to have a ruleset allowing unfiltered access to a tap > interface, but filtered on the real interface it's bridged to? > > Let's say there are these: > > ext_if="ix0" # real external ip, on a /29 int_if="igb0" # internal ip > 10.0.0.2/8 > tap_if="tap0" # this services a vm on this machine, also with a real ip > > bridge0 has ix0 and tap0 as members > > tap0 needs unfiltered access. it has its own firewall. > ix0 wants to block everything apart from ssh. > > This doesn't work (it blocks everything apart from ssh to the vm as > well): > > [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 As for me I prefer to have all IPs and filter it on bridge interface and not on members. ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
pf and tap(4) interfaces
Hi, Is it possible to have a ruleset allowing unfiltered access to a tap interface, but filtered on the real interface it's bridged to? Let's say there are these: ext_if="ix0" # real external ip, on a /29 int_if="igb0" # internal ip 10.0.0.2/8 tap_if="tap0" # this services a vm on this machine, also with a real ip bridge0 has ix0 and tap0 as members tap0 needs unfiltered access. it has its own firewall. ix0 wants to block everything apart from ssh. This doesn't work (it blocks everything apart from ssh to the vm as well): [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, -- J. signature.asc Description: PGP signature
