wireguard-openbsd/sbin/pfctl, branch master

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

2021-02-01T00:31:04Z

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@

Sometimes a user ID was logged in pflog(4) although the logopt of

2021-01-12T00:10:34Z

the rule did not specify it. Check the option again for the log rule in case another rule has triggered a socket lookup. Remove logopt group, it is not documented and cannot work as struct pfloghdr does not contain a gid. Rename PF_LOG_SOCKET_LOOKUP to PF_LOG_USER to express what it does. The lookup involved is only an implemntation detail. OK kn@ sashan@ mvs@

getifaddrs() can return entries where ifa_addr is NULL. Check for this

2020-12-29T19:50:28Z

before accessing anything in ifa_addr. ok claudio@

Fail to parse rules with invalid ranges

2020-12-16T18:01:16Z

This makes pfctl(8) detect bogus ranges (with and without `-n') before loading the ruleset and completes the previous commit. OK sashan sthen

Reject rules with invalid port ranges

2020-12-16T18:00:44Z

Ranges where the left boundary is bigger than the right one are always bogus as they work like `port any' (`port 34<>12' means "all ports") or in way that inverts the rule's action (`pass ... port 34:12' means "pass no port at all"). Add checks for all ranges and invalidate those that yield no or all ports. For this to work on redirections, make pfctl(8) pass the range's type, otherwise boundary including ranges are not detected as such; that is to say, `struct pf_pool's `port_op' member was unused in the kernel so far. `rdr-to' rules with invalid ranges could panic the kernel when hit. Reported-by: syzbot+9c309db201f06e39a8ba@syzkaller.appspotmail.com OK sashan

synproxy should be processing incoming SYN packets only.

2020-12-07T08:29:41Z

issue noticed by sthen@. fix discussed with bluhm@ and procter@ OK bluhm@, kn@, procter@

Accommodate a basename(3) that takes a non-const parameter and may

2020-10-14T19:30:37Z

in fact modify the string buffer. ok kn@ sashan@ cVS: ----------------------------------------------------------------------

rdomain IDs do not need to exist for "on rdomain N" to work

2020-10-01T14:02:08Z

Unlike "... rtable N", pf.conf(5)'s "on rdomain N" does not alter packet state and will always work no matter if rdomain N currently exists or not, i.e. the rule "pass on rdomain 42" will simply match (and pass) packets if rdomain 42 exists, and it will simply not match (neither pass nor block) packets if 42 does not exist. There's no need to reload the ruleset whenever routing domains are created or deleted, which can already be observed now by creating an rdomain, loading rules referencing it and deleting the same rdomain immediately afterwards: pf will continue to work as expected. Relax both pfctl(8)'s parser check as well as pf(4)'s copyin routine to accept any valid routing domain ID without expecting it to exist at the time of ruleset creation - this lifts the requirement to create rdomains before referencing them in pf.conf while keeping pf behaviour unchanged. Prompted by yasuoka's recent pfctl parse.y r1.702 commit requiring an rtable to exist upon ruleset creation. Discussed with claudio and bluhm at k2k20. Feedback sashan OK sashan yasouka claudio

Fix the previous commit whose conditions were reversed.

2020-09-17T14:26:59Z

ok kn

Make pfctl(8) check if the rtable really exists when parsing the

2020-09-17T10:09:43Z

config. work with and diff from kn ok kn