> The code says it well - after your divert(4) client reinjects the
quoted text
> 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.

quoted text
> 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 <martin.pelikan@gmail.com>:
quoted text
> 2010/10/3, Daniel Browning-Weber <weberdan@gmail.com>:
>> 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.
quoted text
>
> 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