RELAYD.CONF(5) OpenBSD Programmer's Manual RELAYD.CONF(5)NAMErelayd.conf - relay daemon configuration file
DESCRIPTIONrelayd.conf is the configuration file for the relay daemon, relayd(8).
SECTIONSrelayd.conf is divided into six main sections:
Macros
User-defined variables may be defined and used later, simplifying
the configuration file.
Global Configuration
Global settings for relayd(8). Do note that the config file allows
global settings to be added after defining tables in the config
file, but those tables will use the built-in defaults instead of
the global settings below them.
Tables
Table definitions describe a list of hosts, in a similar fashion to
pf(4) tables. They are used for relay, redirection, and router
target selection with the described options and health checking on
the host they contain.
Redirections
Redirections are translated to pf(4) rdr-to rules for stateful
forwarding to a target host from a health-checked table on layer 3.
Relays
Relays allow application layer load balancing, SSL acceleration,
and general purpose TCP proxying on layer 7.
Protocols
Protocols are predefined protocol handlers and settings for relays.
Routers
Routers are used to insert routes with health-checked gateways for
(WAN) link balancing.
Within the sections, a host address can be specified by IPv4 address,
IPv6 address, interface name, or DNS hostname. If the address is an
interface name, relayd(8) will look up the first IPv4 address and any
other IPv4 and IPv6 addresses of the specified network interface. A port
can be specified by number or name. The port name to number mappings are
found in the file /etc/services; see services(5) for details.
Comments can be put anywhere in the file using a hash mark (`#'), and
extend to the end of the current line.
Additional configuration files can be included with the include keyword,
for example:
include "/etc/relayd.conf.local"
MACROS
Macros can be defined that will later be expanded in context. Macro
names must start with a letter, and may contain letters, digits, and
underscores. Macro names may not be reserved words (for example, table,
relay, or timeout). Macros are not expanded inside quotes.
For example:
www1="10.0.0.1"
www2="10.0.0.2"
table <webhosts> {
$www1
$www2
}
GLOBAL CONFIGURATION
Here are the settings that can be set globally:
demote group
Enable the global carp(4) demotion option, resetting the carp
demotion counter for the specified interface group to zero on
startup and to 128 on shutdown of the daemon. For more
information on interface groups, see the group keyword in
ifconfig(8).
interval number
Set the interval in seconds at which the hosts will be checked.
The default interval is 10 seconds.
log (updates|all)
Log state notifications after completed host checks. Either only
log the updates to new states or log all state notifications,
even if the state didn't change. The host state can be up (the
health check completed successfully), down (the host is down or
didn't match the check criteria), or unknown (the host is
disabled or has not been checked yet).
prefork number
When using relays, run the specified number of processes to
handle relayed connections. This increases the performance and
prevents delays when connecting to a relay. relayd(8) runs 5
relay processes by default and every process will handle all
configured relays.
send trap
Send an SNMP trap when the state of a host changes. relayd(8)
will try to connect to snmpd(8) and request it send a trap to the
registered trap receivers; see snmpd.conf(5) for more information
about the configuration.
timeout number
Set the global timeout in milliseconds for checks. This can be
overridden by the timeout value in the table definitions. The
default interval is 200 milliseconds and it must not exceed the
global interval. Please note that the default value is optimized
for checks within the same collision domain - use a higher
timeout, such as 1000 milliseconds, for checks of hosts in other
subnets. If this option is to be set, it should be placed before
overrides in tables.
TABLES
Tables are used to group a set of hosts as the target for redirections or
relays; they will be mapped to a pf(4) table for redirections. Tables
may be defined with the following attribute:
disable Start the table disabled - no hosts will be checked in this
table. The table can be later enabled through relayctl(8).
Each table must contain at least one host; multiple hosts are separated
by newline, comma, or whitespace. Host entries may be defined with the
following attributes:
ip ttl number
Change the default time-to-live value in the IP headers for host
checks.
parent number
The optional parent option inherits the state from a parent host
with the specified identifier. The check will be skipped for this
host and copied from the parent host. This can be used to prevent
multiple checks on hosts with multiple IP addresses for the same
service. The host identifiers are sequentially assigned to the
configured hosts starting with 1; it can be shown with the
relayctl(8) show summary commands.
retry number
The optional retry option adds a tolerance for failed host checks;
the check will be retried for number more times before setting the
host state to down. If this table is used by a relay, it will
also specify the number of retries for outgoing connection
attempts.
For example:
table <service> { 192.168.1.1, 192.168.1.2, 192.168.2.3 }
table <fallback> disable { 10.1.5.1 retry 2 }
redirect "www" {
listen on www.example.com port 80
forward to <service> check http "/" code 200
forward to <fallback> check http "/" code 200
}
Tables are used by forward to directives in redirections or relays with a
set of general options, health-checking rules, and timings; see the
REDIRECTIONS and RELAYS sections for more information about the forward
context. Table specific configuration directives are described below.
Multiple options can be appended to forward to directives, separated by
whitespaces.
The following options will configure the health-checking method for the
table, and is mandatory for redirections:
check http path [host hostname] code number
For each host in the table, verify that retrieving the URL path
gives the HTTP return code number. If hostname is specified, it
is used as the ``Host:'' header to query a specific hostname at
the target host. To validate the HTTP return code, use this
shell command:
$ echo -n "HEAD <path> HTTP/1.0\r\n\r\n" | \
nc <host> <port> | head -n1
This prints the status header including the actual return code:
HTTP/1.1 200 OK
check https path [host hostname] code number
This has the same effect as above but wraps the HTTP request in
SSL.
check http path [host hostname] digest string
For each host in the table, verify that retrieving the URL path
produces non-binary content whose message digest matches the
defined string. The algorithm used is determined by the string
length of the digest argument, either SHA1 (40 characters) or MD5
(32 characters). If hostname is specified, it is used as the
``Host:'' header to query a specific hostname at the target host.
The digest does not take the HTTP headers into account. Do not
specify a binary object (such as a graphic) as the target of the
request, as relayd.conf expects the data returned to be a string.
To compute the digest, use this simple command:
$ ftp -o - http://host[:port]/path | sha1
This gives a digest that can be used as-is in a digest statement:
a9993e36476816aba3e25717850c26c9cd0d89d
check https path [host hostname] digest string
This has the same effect as above but wraps the HTTP request in
SSL.
check icmp
Ping hosts in this table to determine whether they are up or not.
This method will automatically use ICMP or ICMPV6 depending on
the address family of each host.
check script path
Execute an external program to check the host state. The program
will be executed for each host by specifying the hostname on the
command line:
/usr/local/bin/checkload.pl front-www1.private.example.com
relayd(8) expects a positive return value on success and zero on
failure. Note that the script will be executed with the
privileges of the "_relayd" user and terminated after timeout
milliseconds.
check send data expect pattern [ssl]
For each host in the table, a TCP connection is established on
the port specified, then data is sent. Incoming data is then
read and is expected to match against pattern using shell
globbing rules. If data is an empty string or nothing then
nothing is sent on the connection and data is immediately read.
This can be useful with protocols that output a banner like SMTP,
NNTP, and FTP. If the ssl keyword is present, the transaction
will occur in an SSL tunnel.
check ssl
Perform a complete SSL handshake with each host to check their
availability.
check tcp
Use a simple TCP connect to check that hosts are up.
The following general table options are available:
demote group
Enable the per-table carp(4) demotion option. This will
increment the carp demotion counter for the specified interface
group if all hosts in the table are down. For more information
on interface groups, see the group keyword in ifconfig(8).
interval number
Override the global interval and specify one for this table. It
must be a multiple of the global interval.
timeout number
Set the timeout in milliseconds for each host that is checked
using TCP as the transport. This will override the global
timeout, which is 200 milliseconds by default.
The following options will set the scheduling algorithm to select a host
from the specified table:
mode hash
Balances the outgoing connections across the active hosts based
on the hashed name of the table. Additional input can be fed
into the hash by looking at HTTP headers and GET variables; see
the PROTOCOLS section below. This mode is only supported by
relays.
mode loadbalance
Balances the outgoing connections across the active hosts based
on the hashed name of the table, the source and destination
addresses, and the corresponding ports. This mode is only
supported by relays.
mode roundrobin
Distributes the outgoing connections using a round-robin
scheduler through all active hosts. This is the default mode and
will be used if no option has been specified. This mode is
supported by redirections and relays.
REDIRECTIONS
Redirections represent a pf(4) rdr-to rule. They are used for stateful
redirections to the hosts in the specified tables. pf(4) rewrites the
target IP addresses and ports of the incoming connections, operating on
layer 3. The configuration directives that are valid in the redirect
context are described below:
disable
The redirection is initially disabled. It can be later enabled
through relayctl(8).
forward to <table> [port number] options ...
Specify the tables of target hosts to be used; see the TABLES
section above for information about table options. If the port
option is not specified, the first port from the listen on
directive will be used. This directive can be specified twice -
the second entry will be used as the backup table if all hosts in
the main table are down. At least one entry for the main table
is mandatory.
listen on address [ip-proto] port port [interface name]
Specify an address and a port to listen on. pf(4) will redirect
incoming connections for the specified target to the hosts in the
main or backup table. The port argument can optionally specify a
port range instead of a single port; the format is
min-port:max-port. The optional argument ip-proto can be used to
specify an IP protocol like tcp or udp; it defaults to tcp. The
rule can be optionally restricted to a given interface name.
route to <table> [port number] options ...
Like the forward to directive, but directly routes the packets to
the target host without modifying the target address using a
pf(4) route-to rule. This can be used for ``direct server
return'' to force the target host to respond via a different
gateway. Note that hosts have to accept sessions for the same
address as the gateway, which is typically done by configuring a
loopback interface on the host with this address.
session timeout seconds
Specify the inactivity timeout in seconds for established
redirections. The default timeout is 600 seconds (10 minutes).
sticky-address
This has the same effect as specifying sticky-address for an rdr-
to rule in pf.conf(5). It will ensure that multiple connections
from the same source are mapped to the same redirection address.
[match] tag name
Automatically tag packets passing through the pf(4) rdr-to rule
with the name supplied. This allows simpler filter rules. The
optional match keyword will change the default rule action from
pass in quick to match in to allow further evaluation in the pf
ruleset using the tagged name rule option.
RELAYS
Relays will forward traffic between a client and a target server. In
contrast to redirections and IP forwarding in the network stack, a relay
will accept incoming connections from remote clients as a server, open an
outgoing connection to a target host, and forward any traffic between the
target host and the remote client, operating on layer 7. A relay is also
called an application layer gateway or layer 7 proxy.
The main purpose of a relay is to provide advanced load balancing
functionality based on specified protocol characteristics, such as HTTP
headers, to provide SSL acceleration and to allow basic handling of the
underlying application protocol.
The relay configuration directives are described below:
disable
Start the relay but immediately close any accepted connections.
[transparent] forward [with ssl] to address [port port] options ...
Specify the address and port of the target host to connect to.
If the port option is not specified, the port from the listen on
directive will be used. Use the transparent keyword to enable
fully-transparent mode; the source address of the client will be
retained in this case.
The with ssl directive enables client-side SSL mode to connect to
the remote host. Verification of server certificates can be
enabled by setting the ca file option in the protocol section.
The following options may be specified for forward directives:
retry number
The optional host retry option will be used as a
tolerance for failed host connections; the connection
will be retried for number more times.
inet If the requested destination is an IPv6 address,
relayd(8) will forward the connection to an IPv4 address
which is determined by the last 4 octets of the original
IPv6 destination. For example, if the original IPv6
destination address is 2001:db8:7395:ffff::a01:101, the
session is relayed to the IPv4 address 10.1.1.1
(a01:101).
inet6 address-prefix
If the requested destination is an IPv4 address,
relayd(8) will forward the connection to an IPv6 address
which is determined by setting the last 4 octets of the
specified IPv6 address-prefix to the 4 octets of the
original IPv4 destination. For example, if the original
IPv4 destination address is 10.1.1.1 and the specified
address prefix is 2001:db8:7395:ffff::, the session is
relayed to the IPv6 address 2001:db8:7395:ffff::a01:101.
forward to <table> [port port] options ...
Like the previous directive, but connect to a host from the
specified table; see the TABLES section above for information
about table options. This directive can be specified twice - the
second entry will be used as the backup table if all hosts in the
main table are down. At least one entry for the main table is
mandatory.
forward to nat lookup options ...
When redirecting connections with an rdr-to rule in pf.conf(5) to
a relay listening on localhost, this directive will look up the
real destination address of the intended target host, allowing
the relay to be run as a transparent proxy. If an additional
forward to directive to a specified address or table is present,
it will be used as a backup if the NAT lookup failed.
listen on address [port port] [ssl]
Specify the address and port for the relay to listen on. The
relay will accept incoming connections to the specified address.
If the port option is not specified, the port from the listen on
directive will be used.
If the ssl keyword is present, the relay will accept connections
using the encrypted SSL protocol. The relay will look up a
private key in /etc/ssl/private/address.key and a public
certificate in /etc/ssl/address.crt, where address is the
specified IP address of the relay to listen on. See ssl(8) for
details about SSL server certificates.
protocol name
Use the specified protocol definition for the relay. The generic
TCP protocol options will be used by default; see the PROTOCOLS
section below.
session timeout seconds
Specify the inactivity timeout in seconds for accepted sessions.
The default timeout is 600 seconds (10 minutes).
PROTOCOLS
Protocols are templates defining actions and settings for relays. They
allow setting generic TCP options, SSL settings, and actions specific to
the selected application layer protocol.
The protocol directive is available for a number of different application
layer protocols. There is no generic handler for UDP-based protocols
because it is a stateless datagram-based protocol which has to look into
the application layer protocol to find any possible state information.
dns protocol
(UDP) Domain Name System (DNS) protocol. The requested IDs in
the DNS header will be used to match the state. relayd(8)
replaces these IDs with random values to compensate for
predictable values generated by some hosts.
http protocol
Handle the HyperText Transfer Protocol (HTTP, or "HTTPS" if
encapsulated in an SSL tunnel).
[tcp] protocol
Generic handler for TCP-based protocols. This is the default.
The available configuration directives are described below:
[direction] [type] action [marked id] [log]
Define an action for the selected entity. The optional log
keyword will log the entity name and the value and the optional
marked keyword requires that the session has been marked with a
given identifier in order to execute the action. The actions are
dependent on the underlying application protocol.
[direction] may be one of:
request
Handle the data stream from the client to the relay, like HTTP
requests. This is the default if the direction directive is
omitted.
response
Handle the data stream from the target host to the relay, like
HTTP server replies.
[type] may be one of:
cookie Look up the entity as a value in the Cookie header when using the
http protocol. This type is only available with the direction
request.
header Look up the entity in the application protocol headers, like HTTP
headers in http mode.
path Look up the entity as a value in the URL path when using the http
protocol. This type is only available with the direction
request. The key will match the path of the requested URL
without the hostname and query and the value will match the
complete query, for example:
request path filter "/index.html"
request path filter "foo=bar*" from "/cgi-bin/t.cgi"
query Look up the entity as a query variable in the URL when using the
http protocol. This type is only available with the direction
request, for example:
# Will match /cgi-bin/example.pl?foo=bar&ok=yes
request query expect "bar" from "foo"
url Look up the entity as a URL suffix/prefix expression consisting
of a canonicalized hostname without port or suffix and a path
name or prefix when using the http protocol. This type is only
available with the direction request, for example:
request url filter "example.com/index.html"
request url filter "example.com/test.cgi?val=1"
relayd(8) will match the full URL and different possible
suffix/prefix combinations by stripping subdomains and path
components (up to 5 levels), and the query string. For example,
the following lookups will be done for
http://www.example.com:81/1/2/3/4/5.html?query=yes:
www.example.com/1/2/3/4/5.html?query=yes
www.example.com/1/2/3/4/5.html
www.example.com/
www.example.com/1/
www.example.com/1/2/
www.example.com/1/2/3/
example.com/1/2/3/4/5.html?query=yes
example.com/1/2/3/4/5.html
example.com/
example.com/1/
example.com/1/2/
example.com/1/2/3/
[action] may be one of:
append value to key
Append the specified value to a protocol entity with the selected
name. When using the http protocol, key will indicate a
specified HTTP header. If key does not exist in the request, it
will be created with the value set to value.
The value string may contain predefined macros that will be
expanded at runtime:
$REMOTE_ADDR The IP address of the connected client.
$REMOTE_PORT The TCP source port of the connected client.
$SERVER_ADDR The configured IP address of the relay.
$SERVER_PORT The configured TCP server port of the relay.
$SERVER_NAME The server software name of relayd(8).
$TIMEOUT The configured session timeout of the relay.
change key to value
Like the append directive above, but change the contents of the
specified entity. If key does not exist in the request, it will
be created with the value set to value.
The value string may contain predefined macros that will be
expanded at runtime, as detailed for the append directive above.
expect value from key
Expect an entity key and match against value using shell globbing
rules. If the entity is not present or the value doesn't match,
the connection will be dropped.
expect [digest] key
Expect an entity key with any possible value. This is the short
form of expect * from key.
If the digest keyword is specified, compare the message digest of
the entity against the defined string. The algorithm used is
determined by the string length of the key argument, either SHA1
(40 characters) or MD5 (32 characters). To compute the digest,
use this simple command:
$ echo -n "example.com/path/?args" | sha1
expect file path
Like the directive above, but load the non-digest keys from an
external file with the specified path containing one key per
line. Lines will be stripped at the first whitespace or newline
character. Any empty lines or lines beginning with a hash mark
(`#') will be ignored.
filter value from key
Like the expect .. from directive above, but drop any connections
with the specified entity key and a matching value.
filter [digest] key
Like the expect directive above, but drop any connections with
the specified entity key and any possible value. This is the
short form of filter * from key.
filter file path
Like the directive above, but load the non-digest keys from path.
See expect file path for more information.
hash key
Feed the value of the selected entity into the load balancing
hash to select the target host. See the table keyword in the
RELAYS section above.
log key
Log the name and the value of the entity.
log file path
Like the directive above, but load the keys from path. See
expect file path for more information.
mark [value from] key with id
Mark the session with the specified identifier (a positive number
between 1 and 65535) if the specified condition matches. Note
that the mark action does not accept the marked option (see
above).
label string
Add a label to subsequently added actions. The label will be
printed as part of the error message if the return error option
is set and may contain HTML tags, for example:
label "<a href='http://example.com/advisory.pl?id=7359'>\
Advisory provided by example.com</a>"
url filter digest 5c1e03f58f8ce0b457474ffb371fd1ef
url filter digest 80c1a7b8337462093ef8359c57b4d56a
no label
no label
Do not set a label for subsequently added actions; this is the
default.
remove key
Remove the entity with the selected name.
remove file path
Like the directive above, but load the keys from path. See
expect file path for more information.
return error [option]
Return an error response to the client if an internal operation
or the forward connection to the client failed. By default, the
connection will be silently dropped. The effect of this option
depends on the protocol: HTTP will send an error header and page
to the client before closing the connection. Additional valid
options are:
style string
Specify a Cascading Style Sheet (CSS) to be used for the
returned HTTP error pages, for example:
body { background: #a00000; color: white; }
ssl option
Set the SSL options and session settings. This is only used if
SSL is enabled in the relay. Valid options are:
ca file path
This option enables CA verification in SSL client mode.
The daemon will load the CA (Certificate Authority)
certificates from the specified path to verify the server
certificates. OpenBSD provides a default CA bundle in
/etc/ssl/cert.pem.
ciphers string
Set the string defining the SSL cipher suite. If not
specified, the default value HIGH:!ADH will be used
(strong crypto cipher suites without anonymous DH). See
the CIPHERS section of openssl(1) for information about
SSL cipher suites and preference lists.
session cache value
Set the maximum size of the SSL session cache. If the
value is zero, the default size defined by the SSL
library will be used. A positive number will set the
maximum size in bytes and the keyword disable will
disable the SSL session cache.
[no] sslv2
Enable the SSLv2 protocol; disabled by default.
[no] sslv3
Disable the SSLv3 protocol; enabled by default.
[no] tlsv1
Disable the TLSv1/SSLv3.1 protocol; enabled by default.
tcp option
Enable or disable the specified TCP/IP options; see tcp(4) and
ip(4) for more information about the options. Valid options are:
backlog number
Set the maximum length the queue of pending connections
may grow to. The backlog option is 10 by default and is
limited by the kern.somaxconn sysctl(8) variable.
ip minttl number
This option for the underlying IP connection may be used
to discard packets with a TTL lower than the specified
value. This can be used to implement the Generalized TTL
Security Mechanism (GTSM) according to RFC 3682.
ip ttl number
Change the default time-to-live value in the IP headers.
[no] nodelay
Enable the TCP NODELAY option for this connection. This
is recommended to avoid delays in the relayed data
stream, e.g. for SSH connections.
[no] sack
Use selective acknowledgements for this connection.
socket buffer number
Set the socket-level buffer size for input and output for
this connection. This will affect the TCP window size.
ROUTERS
Routers represent routing table entries in the kernel forwarding
database, see route(4), and a table of associated gateways. They are
used to dynamically insert or remove routes with gateways based on their
availability and health-check results. A router can include multiple
network statements and a single forward statement with a table of one or
more gateways. All entries in a single router directive must match the
same address family, either IPv4 or IPv6.
The kernel supports multipath routing when multiple gateways exist to the
same destination address. The multipath routing behaviour can be changed
globally using the sysctl(8) variables net.inet.ip.multipath and
net.inet6.ip6.multipath. With the default setting of 0, the first route
selected will be used for subsequent packets to that destination
regardless of source. Setting it to 1 will enable load balancing based
on the packet source address across gateways; multiple routes with the
same priority are used equally. The kernel will also check the link
state of the related network interface and try a different route if it is
not active.
The configuration directives that are valid in the routers context are
described below:
forward to <table> port number options ...
Specify the table of target gateways to be used; see the TABLES
section above for information about table options. This entry is
mandatory and must be specified once.
route address/prefix
Specify the network address and prefix length of a route
destination that is reachable via the active gateways. This
entry must be specified at least once in a router directive.
rtable id
Add the routes to the kernel routing table with the specified id.
rtlabel label
Add the routes with the specified label to the kernel routing
table.
FILES
/etc/relayd.conf relayd(8) configuration file.
/etc/services Service name database.
/etc/ssl/address.crt
/etc/ssl/private/address.key Location of the relay SSL server
certificates, where address is the
configured IP address of the relay.
/etc/ssl/cert.pem Default location of the CA bundle that
can be used with relayd(8).
EXAMPLES
This configuration file would create a redirection service ``www'' which
load balances four hosts and falls back to one host containing a ``sorry
page'':
www1=front-www1.private.example.com
www2=front-www2.private.example.com
www3=front-www3.private.example.com
www4=front-www4.private.example.com
interval 5
table <phphosts> { $www1, $www2, $www3, $www4 }
table <sorryhost> disable { sorryhost.private.example.com }
redirect "www" {
listen on www.example.com port 8080 interface trunk0
listen on www6.example.com port 80 interface trunk0
tag REDIRECTED
forward to <phphosts> port 8080 timeout 300 \
check http "/" digest "630aa3c2f..."
forward to <sorryhost> port 8080 timeout 300 check icmp
}
It is possible to specify multiple listen directives with different IP
protocols in a single redirection configuration:
redirect "dns" {
listen on dns.example.com tcp port 53
listen on dns.example.com udp port 53
forward to <dnshosts> port 53 check tcp
}
The following configuration would add a relay to forward secure HTTPS
connections to a pool of HTTP webservers using the loadbalance mode (SSL
acceleration and layer 7 load balancing). The HTTP protocol definition
will add two HTTP headers containing address information of the client
and the server, set the ``Keep-Alive'' header value to the configured
session timeout, and include the ``sessid'' variable in the hash to
calculate the target host:
http protocol "http_ssl" {
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" }
}
relay "sslaccel" {
listen on www.example.com port 443 ssl
protocol "http_ssl"
forward to <phphosts> port 8080 mode loadbalance check tcp
}
The second relay example will accept incoming connections to port 2222
and forward them to a remote SSH server. The TCP nodelay option will
allow a ``smooth'' SSH session without delays between keystrokes or
displayed output on the terminal:
protocol "myssh" {
tcp { nodelay, socket buffer 65536 }
}
relay "sshforward" {
listen on www.example.com port 2222
protocol "myssh"
forward to shell.example.com port 22
}
The next simple router configuration example can be used to run
redundant, health-checked WAN links:
table <gateways> { $gw1 ip ttl 1, $gw2 ip ttl 1 }
router "uplinks" {
route 0.0.0.0/0
forward to <gateways> check icmp
}
SEE ALSOrelayctl(8), relayd(8), snmpd(8), ssl(8)HISTORY
The relayd.conf file format, formerly known as hoststated.conf, first
appeared in OpenBSD 4.1. It was renamed to relayd.conf in OpenBSD 4.3.
AUTHORS
The relayd(8) program was written by Pierre-Yves Ritschard
<pyr@openbsd.org> and Reyk Floeter <reyk@openbsd.org>.
CAVEATSrelayd(8) Verification of SSL server certificates is based on a static CA
bundle and relayd(8) currently does not support CRLs (Certificate
Revocation Lists).
OpenBSD 4.9 October 26, 2010 OpenBSD 4.9
