change route-to so it sends packets to IPs instead of interfaces.

this is a significant (and breaking) reworking of the policy based
routing that pf can do. the intention is to make it as easy as
nat/rdr to use, and more robust when it's operating.

the main reasons for this change are:

- route-to, reply-to, and dup-to do not work with pfsync

 this is because the information about where to route-to is stored in
 rules, and it is hard to have a ruleset synced between firewalls,
 and impossible to have them synced 100% of the time.

- i can make my boxes panic in certain situations using route-to

 yeah...

- the configuration and syntax for route-to rules are confusing.

 the argument to route-to and co is an interace name with an optional
 ip address. there are several problems with this. one is that people
 tend to think about routing as sending packets to peers by their
 address, not by the interface they're reachable on. another is that
 we currently have no way to synchronise interface topology information
 between firewalls, so using an interface to say where packets go
 means we can't do failover of these states with pfsync. another
 is that a change in routing topology means a host may become
 reachable over a different interface. tying routing policy to
 interfaces gets in the way of failover and load balancing.

this change does the following:

- stores the route info in the state instead of the pf rule

 this allows route-to to keep working when the ruleset changes, and
 allows route-to info to be sent over pfsync. there's enough spare bits
 in pfsync messages that the protocol doesnt break.

 the caveat is that route-to becomes tied to pass rules that create
 state, like rdr-to and nat-to.

- the argument to route-to etc is a destination ip address

 it's not limited to a next-hop address (thought a next-hop can be a
 destination address). this allows for the failover and load balancing
 referred to above.

- deprecates the address@interface host syntax in pfctl

 because routing is done entirely by IPs, the interface is derived from
 the route lookup, not pf. any attempt to use the @interface syntax
 will fail now in all contexts.

there's enthusiasm from proctor@ jmatthew@ and others
ok sashan@ bluhm@

0 files changed, 0 insertions, 0 deletions