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.
</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
