> The code says it well - after your divert(4) client reinjects the
> packet back into the kernel, it bypasses any pf checks and goes
> straight to the {ip_,ip6_}output function because of possible loops.That's all perfectly sensible, and I feel more likely to hurt myself if I could get a packet to go back into pf. > What exactly are you trying to accomplish here, with the > combination of these two? I have two network connections I want to load balance. I'm using the example rules here: http://www.openbsd.org/faq/pf/pools.html#outgoing Those work great, without the divert-packet. And the divert-packet works great, if I only have one internet connection. But I'm trying to get them to both be applied. 2010/10/4 Martin Pelikan <[email protected]>: > 2010/10/3, Daniel Browning-Weber <[email protected]>: >> Okay, and the divert (4) man page says that outbound packets, >> after being reinjected, "are processed directly by the relevant >> IP/IPv6 output function," so I probably can't get pf to take >> another look at them so that "route-to" will apply. >> >> If I were feeling brave and wanted to mess with this in the >> kernel, should I try to get the packet's routing changed >> after processing? Or would it be less insane for me to >> try to play with the routing before the divert? > > The code says it well - after your divert(4) client reinjects the > packet back into the kernel, it bypasses any pf checks and goes > straight to the {ip_,ip6_}output function because of possible loops. > > What exactly are you trying to accomplish here, with the combination > of these two? > Please be more specific about your goals, not just the technical stuff around. > > I'm not sure about this though, but passing the packet to divert app > and changing IP headers _in there_ should suffice for most what you'd > accomplish using route-to (now I'm waiting for the cold-shower of > corrections and RTFM's). Provided that your routing table is > consistent with what you want to do, of course. > -- > Martin Pelikan
