> On 4 Jan 2021, at 9:27 pm, Alexandr Nedvedicky
> <alexandr.nedvedi...@oracle.com> wrote:
>
> Hello,
>
> there is one more thing, which just came up on my mind.
>
> </snip>
>>
>> so i want to change route-to in pfctl so it takes a nexthop instead
>> of an interface. you could argue that pf already lets you do this,
>> because there's some bs nexthop@interface syntax. my counter argument
>> is that the interface the nexthop is reachable over is redundant, and it
>> makes fixing some of the other problems harder if we keep it.
>>
>
> what is your plan for dup-to then? if my understanding of dup-to is
> correct, then it allows administrator to copy matching packets and send
> them out dedicated interface so another physical box (box with running
> snort) can intercept them and process them.
>
> I remember we had to do some assumptions about this, when porting PF to
> Solaris. So Solaris interpretation of option
>
> 'dup-to net12'
>
> is to send out copy of matching packet via net12 interface. because there
> is no next-hop specified, we just use link broadcast when pushing out the
> packet to network. I agree this is a hack. If route-to will be changed
> to accept next-hop instead of interface, then we will be able to kill
> such hack.
route-to, reply-to, and dup-to take an address as an argument. In dup-to's
case, the packet is duplicated and then the copy is routed toward the
destination.
As discussed previously, the address argument is a destination, it's not a link
local address per se. The destination address could be a directly connected or
link local address, but it could also be via a gateway (including a those
learnt by a dynamic routing protocol), and/or via multiple gateways. This
allows for failover or ECMP like we get with packets where the path is selected
by the rtable lookup.
dlg
>
> </snip>
>
>>
>> if we limit the information needed for pf_route to a nexthop address,
>> and which direction the address is used, this is doable. both the
>> pf_state and pfsync_state structs already contain an address to store a
>> nexthop in, i just had to move the route-to direction from the rule into
>> the state. this is easy with pf_state, but i used a spare pad field in
>> pfsync_state for this.
>>
>
> this should be fine, because route-to et.al. don't work with 'block' rules.
>
>
> thanks and
> regards
> sashan
