On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote: > Hello, > > On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote: > > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote: > > > How are you injecting the crafted packet into the stack? > > > > Via BPF. It is a spoofing program that I made 23 years ago. While that's > > not really a great achievement it found at least 5 or so panic conditions > > on OpenBSD throughout its existance, for which I'm sure everyone is grateful > > for. I am willing to share it (I have shared it in the past), but now only > > for @openbsd.org addresses, I keep hacking on it time and time again, > > but it only does IPv4 unless it reads the entire frame which I've never > > tried > > I don't think. Anyhow regarding the panics they pop up whenever I get > > "creative" with packets, which keeps me away from what I really wanted to > > achieve. > > > > So in private conversation I had with Alexandr, I noticed that in the > > OpenBSD > > pf firewall there is this statement in the pf.conf manpage (which is a lie). > > > > ICMP responses are not permitted unless they either match an > > existing request, or unless no state or keep state (sloppy) is > > specified. > > > > > > the paragraph you quote assumes a context of stateful packet filtering. > however the truth is that if ICMP response packet does not match existing > state (existing request), then the ICMP packet fate depends on rules which > is covered in second paragraph in 'PACKET FILTERING' section: > > Each time a packet processed by the packet filter comes in on or goes out > through an interface, the filter rules are evaluated in sequential order, > from first to last. For block and pass, the last matching rule decides > what action is taken; if no rule matches the packet, the default action > is to pass the packet without creating a state. For match, rules are > evaluated every time they match; the pass/block state of a packet remains > unchanged. > > > regards > sashan
Hi, So I shared my pf.conf with you and sthen so that we're not guessing anymore, I should have done this earlier. There is a pass from <rfc1918> to any in anchor "pppoe0 inet" but before that is a NAT match rule in the NAT anchor. So my question is the following. Why does this match not work? And why is there no state made for this packet though I specified keep state in the pass in last paragraph. This packet is an odd one to me for sure. Am I being difficult here? Sorry if you think I am. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
