Re: Packets passed by pf don't make it out?
On Wed, Oct 14, 2020 at 3:20 PM Kristof Provost wrote: > I’ve not dug very deep yet, but I wonder if we shouldn’t have to > teach pf to change the source port to avoid conflicting states in the > first place. That was my first thought as well, framed mentally as some sort of port-only Frankenstein's binat because my level of understanding is clearly more cartoonish than yours. ;-) My second thought was to wonder if my approach is architecturally wrong. Would it make sense for the many-to-many case to use route-to instead of rdr, leave the packet unmodified, and expect every machine in the server pool to catch all the public IPs? That might still be tricky. Using rdr would presumably hit the same problem. Maybe something gross like ifconfig'ing the public pool addresses as /32's on lo0, then binding on those, maybe? Thanks! ___ 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: Packets passed by pf don't make it out?
On 14 Oct 2020, at 21:16, J David wrote: On Wed, Oct 14, 2020 at 1:59 PM Kristof Provost wrote: There’s good reason to do this, as we have to be able to match state on both the pre-translation side (when processing LAN -> WAN traffic) and post-translation (WAN -> LAN). So, basically, pf would need separate states for each pre-redirect destination address in order to have the information needed to map the reply packet back to the original destination address. But even if pf did that, the problem does not go away. It just moves to the reply packet coming back with only the post-redirect info. That info matches multiple states, leaving pf no way to pick the right one. Is that about right? Pretty much, I think. I’ve not dug very deep yet, but I wonder if we shouldn’t have to teach pf to change the source port to avoid conflicting states in the first place. It’s a non-trivial problem in any case. Regards, 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: Packets passed by pf don't make it out?
On Wed, Oct 14, 2020 at 1:59 PM Kristof Provost wrote: > There’s good reason to do this, as we have to be able to match state > on both the pre-translation side (when processing LAN -> WAN traffic) > and post-translation (WAN -> LAN). So, basically, pf would need separate states for each pre-redirect destination address in order to have the information needed to map the reply packet back to the original destination address. But even if pf did that, the problem does not go away. It just moves to the reply packet coming back with only the post-redirect info. That info matches multiple states, leaving pf no way to pick the right one. Is that about right? Thanks! ___ 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: Packets passed by pf don't make it out?
On 14 Oct 2020, at 18:52, J David wrote: On 12 Oct 2020, at 23:48, Andreas Longwitz wrote: pf gives this messages in debug mode (pfctl -x loud). Yes, with that setting I'm also seeing those messages. On Tue, Oct 13, 2020 at 5:35 PM Kristof Provost wrote: 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. This is probably a dumb question because I know less than nothing about pf internals, but why wouldn't it match the existing state? “It’s complicated”. In essence, pf tracks both the pre- and post-translation tuple, so what we’re seeing here is one of those conflicting with an existing session and that’s causing the failure. There’s good reason to do this, as we have to be able to match state on both the pre-translation side (when processing LAN -> WAN traffic) and post-translation (WAN -> LAN). Best regards, 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: Packets passed by pf don't make it out?
On 12 Oct 2020, at 23:48, Andreas Longwitz wrote: > pf gives this messages in debug mode (pfctl -x loud). Yes, with that setting I'm also seeing those messages. On Tue, Oct 13, 2020 at 5:35 PM Kristof Provost wrote: > 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. This is probably a dumb question because I know less than nothing about pf internals, but why wouldn't it match the existing state? Yes, the original destination was different before the redirect, but after the redirect they're going from the same host/port to the same host/port. What's the definition of state equality, and does that satisfy it? In order to say that they're not the same state, wouldn't the packets have to bear some property that survived the redirect that would distinguish them as state-unequal? If it did, would/should that property not then be part of the computation of state entry uniqueness? Like I said, probably a dumb question. > It’s a little unusual for a client to keep re-using src ports like > that, but it’s not actually wrong. After further study, I think the DNS validators used by Let's Encrypt to control TLS certificate issuance may also be doing this, which would make it a little more urgent. (But that bears confirmation.) Thanks! ___ 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 14.10.20 04:37, tech-lists wrote: > > 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. > Your VM IP is assigned on VM's internal interface, not on tap0. This rule may does not make any sense: pass in quick on $ext_if inet proto tcp from any to ($tap_if) Try to try to specify real VM IP instead of interface name: pass in quick on $ext_if inet proto tcp from any to a.b.c.d In my setup for example, ifconfig bridge0 create addm ix0 addm tap0 ifconfig bridge0 a.b.c.d/24 (your external ip) Assign your VM ip (1.2.3.4) on VM internel interface (not on tap0). Set in /etc/sysctl.conf and apply it: net.link.bridge.pfil_bridge=1 net.link.bridge.pfil_member=1 net.link.bridge.pfil_local_phys=1 Your pf rules will look like this: ext_if="bridge0" vm_ip="1.2.3.4" 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 $vm_ip or pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 block in quick on $ext_if inet proto tcp from any to ($ext_if) pass in quick on $ext_if ___ 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"
