Book of PF news flashes: OpenBSD 4.3: hoststated becomes relayd; 4.4: more changes

Just after The Book of PF was sent off to be printed, hoststated was 
renamed in the OpenBSD-current source code tree (yes, the one destined 
to become OpenBSD 4.3, which was sent off to production about the time 
I wrote the first draft of this update, in late March of 2008). The new 
name, relayd, was chosen to emphasize a new direction in the program's 
development, to include ever more layer 7 or application layer processing, 
including relaying and filtering logic.  In OpenBSD 4.3 onwards, relayd 
still includes the now familiar redirection and host status checking logic, 
but the combination of new and planned features and a desire to get more into 
line with general PF syntax made it necessary to make a number of changes to 
the configuration file language.

The interface with /etc/pf.conf changed slightly too.  The anchor name 
was renamed to match the program name and became

rdr-anchor "relayd/*"

In OpenBSD 4.4, relayd had acquired enough filtering related features to warrant 
an anchor for filtering rules too:

anchor "relayd/*"

No other changes to your pf.conf are needed.

To bring the simple hoststated example from page 52 onwards over to relayd syntax, 
a few hanges are needed, and I'll explain them as we go along.  First off, the 
name of the configuration file is now relayd.conf, and it is worth noting that 
the control program hoststatectl was renamed to relayctl.  

Turning to the relayd.conf configuration file, we can keep the macro
definitions intact, but the table syntax has changed ever so slightly
to conform with what you would expect from a pf.conf table definition,
and for consistency the data structure now only serves to define the
address tables.  This means our tables become

table <webpool> { $web1, $web2, $web3, $web4, }
table <sorry> { $sorry_server }

That is, basically the same as if they were still defined in your pf.conf. 
Meanwhile the service we set up to use the tables, now called a redirect, becomes 

redirect "www" {
	 listen on $webserver port 80
	 forward to <webpool> check http "/status.html" code 200 timeout 300
	 forward to <sorry> timeout 300 check icmp 
}

Notice that even though the name of the service now needs to be quoted, all the 
elements we recognize from the old syntax are still there, but essentially all 
table attributes other than the addresses are now defined as part of the service.

Our ssl relay example survives almost intact with only very minor changes.  First, 
the protocol specification changed to include some specific  cases to be declared 
by prefix, such as http (the other cases are dns and the tcp, implicit default). 
This means our httpssl becomes

http protocol "httpssl" {
	      header append "$REMOTE_ADDR" to "X-Forwarded-For"
	      header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
	      header change "Keep-Alive" to "$TIMEOUT"
	      query hash "sessid"
	      cookie hash "sessid"
	      path filter "*command=*" from "/cgi-bin/index.cgi"

	      ssl { sslv2, ciphers "MEDIUM:HIGH" }
	      tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}

also note that the keyword url was repurposed (see the relayd.conf man page) and 
the more general term query took its place.  The example here filters out the 
string "*command=*" from any string containing  references to a particular CGI 
binary and drops any connections where the combination occurs.  One other use of 
filter directives (popular among certain types of system administrators) is to 
block certain clients such as instant messaging clients based the on contents of 
User-Agent or Content-Type strings.

The relay defintion again mainly needs quotes around the protocol name and angle 
brackets to enclose the table name:

relay wwwssl {
	     # Run as a SSL accelerator
	     listen on $webserver port 443 ssl
	     protocol "httpssl"
	     table <webhosts> loadbalance check ssl
}

We also added a check ssl, assuming that each member of the <webhosts> table is 
properly configured to complete an ssl handshake.  Depending on your application, 
it could be useful to look into keeping all ssl processing in relayd, offloading 
the encryption handling tasks from the backends.