OpenBSD FAQ - Networking [FAQ Index]


For the bulk of this document, it helps if you have read and at least partially understand the ifconfig(8) and netstat(1) man pages.

If you are a network administrator, setting up routing protocols, using your OpenBSD box as a router or want to go in-depth into IP networking, you really need to read Understanding IP Addressing. This is an excellent document. "Understanding IP Addressing" contains fundamental knowledge to build upon when working with IP networks, especially when you deal with or are responsible for more than one network.

If you are working with applications such as web servers, ftp servers and mail servers, you may benefit greatly by reading the RFCs. Most likely, you can't read all of them. Pick some topics that you are interested in or that you use in your network environment. Look them up, find out how they are intended to work. The RFCs define many (thousands of) standards for protocols on the Internet and how they are supposed to work.

Network configuration

Normally, OpenBSD's network settings are initially configured by the installation process. However, it is good to understand what is happening in this process and how it works. All network configuration is done using simple text files in the /etc directory.

Identifying and setting up your network interfaces

In OpenBSD, interfaces are named for the type of card, not for the type of connection. You can see your network card get initialized during the booting process, or after the booting process using the dmesg(8) command. For example, here is the part of dmesg for a Intel Fast Ethernet network card, which uses the device name fxp.

fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
This device uses the fxp(4) driver, and is assigned the number 0 here. The number is assigned based on various criteria, depending upon the card and other details of the system. In most cases with today's common hardware, cards are assigned by the order they are found during bus probing. The first fxp found will be fxp0, second will be fxp1 and so on. Users of unusual or very old hardware (ISA) may find devices numbered by hardware resource settings (ISA ne2 is I/O 280 IRQ 9 even if there is no ne1 or ne0), or MAC address.

You can find out what network interfaces have been identified by using the ifconfig(8) utility. The following command will show all network interfaces on a system. This sample output shows us only one physical Ethernet interface, an fxp(4).

$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
        priority: 0
        groups: lo
        inet netmask 0xff000000
        lladdr 00:04:ac:dd:39:6a
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet netmask 0xffffff00 broadcast
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
        priority: 0
        groups: pflog

As you can see here, ifconfig(8) gives us a lot more information than we need at this point. But, it still allows us to see our interface. In the above example, the interface card is already configured. This is obvious because an IP network is already configured on fxp0, hence the values "inet netmask 0xffffff00 broadcast". Also, the UP and RUNNING flags are set.

Finally, you will notice several other interfaces come enabled by default. These are virtual interfaces that serve various functions. The following manual pages describe them:

Other virtual interfaces can be added with the ifconfig(8) create command. These include, but are not limited to:

For a complete listing of virtual interfaces, refer to the ifconfig(8) manpage.

Interfaces are configured at boot time using /etc/hostname.if files, where if is replaced by the full name of each interface. Each interface has its own file. The example above would use the file /etc/hostname.fxp0.

The layout of this file is simple:

address_family address netmask broadcast [other options]
Much more detail about the format of this file can be found in the hostname.if(5) man page. You will need to read this for less trivial configurations.

A typical interface configuration file, configured for an IPv4 address, would look like this:

$ cat /etc/hostname.fxp0
inet NONE

In this case, we have defined an IPv4 (inet) address, with an IP address of, a subnet mask of and no specific broadcast address (which will default to in this case).

You could also specify media types for Ethernet, say, if you wanted to force 100baseTX full-duplex mode.

$ cat /etc/hostname.fxp0
inet NONE media 100baseTX mediaopt full-duplex

Of course, you should never force full duplex mode unless both sides of the connection are set to do this! In the absence of special needs, media settings should be excluded. A more likely case might be to force 10base-T or half duplex when your infrastructure requires it.

You may also want to use special flags specific to a certain interface. The format of the hostname file doesn't change much.

$ cat /etc/hostname.vlan0
inet NONE vlan 2 vlandev fxp1

Default gateway

Put the IP of your gateway in the file /etc/mygate. This will allow for your gateway to be set upon boot. This file consists of one line, with just the address of this machine's gateway.

It is possible to use a symbolic name there, but be careful. You can't assume things like the resolver are fully configured (or even reachable) until AFTER the default gateway is configured. In other words, it had better be an IP address or something that is defined in the /etc/hosts file.

DNS Resolution

DNS resolution is controlled by the file resolv.conf(5). Here is an example of the /etc/resolv.conf file:
$ cat /etc/resolv.conf
lookup file bind
In this case, the default domain name will be, there are two DNS resolvers, and specified, and the /etc/hosts file will be consulted before the DNS resolvers are.

As with virtually all Unix (and many non-Unix) systems, there is a hosts(5) file that can be used to specify systems that are not in (or if used with the above "lookup" priority, not as desired in) the formal DNS system.

If you are using DHCP, you'll want to read DHCP, taking note of resolv.conf.tail(5).

Host name

Every Unix machine has a name. In OpenBSD, the name is specified as a "Fully Qualified Domain Name" (FQDN) on one line in the file /etc/myname. If this machine is named "puffy" and in the domain, the file would contain:
$ cat /etc/myname

Activating the changes

From here, you can either reboot or run the /etc/netstart script. You can do this by simply typing (as root):
# sh /etc/netstart
writing to routing socket: File exists
add net 127: gateway File exists
writing to routing socket: File exists
add net gateway File exists

Notice that a few errors were produced. By running this script, you are reconfiguring things which are already configured. As such, some routes already exist in the kernel routing table. From here, your system should be up and running. Again, you can check to make sure that your interface was set up correctly with ifconfig(8).

Even though you can completely reconfigure networking on an OpenBSD system without rebooting, a reboot is HIGHLY recommended after any significant reconfiguration. The reason for this is that the environment at boot is somewhat different than it is when the system is completely up and running. For example, if you had specified a DNS-resolved symbolic name in any of the files, you would probably find it worked as expected after reconfigure. On initial boot, however, your external resolver may not be available, so the configuration will fail.

Checking routes

You can check your routes via netstat(1) or route(8). If you are having routing problems, you may want to use the -n flag to route(8), which prints the IP addresses rather than doing a DNS lookup and displaying the hostname. Here is an example of viewing your routing tables using both programs.
$ netstat -rn
Routing tables

Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default             UGS         0       86      -  fxp0
127/8              UGRS        0        0      -  lo0          UH          0        0      -  lo0
10.0.0/24          link#1             UC          0        0      -  fxp0           aa:0:4:0:81:d      UHL         1        0      -  fxp0          UGHS        0        0      -  lo0
224/4              URS         0        0      -  lo0

Source             Port  Destination        Port  Proto SA(Address/SPI/Proto)

$ route show
Routing tables

Destination      Gateway            Flags
default           UG        LOCALHOST          UG
localhost        LOCALHOST          UH         link#1             U         aa:0:4:0:81:d      UH        LOCALHOST          UGH

Setting up your OpenBSD box as a forwarding gateway

This is covered in more detail here.

Setting up aliases on an interface

OpenBSD has a simple mechanism for setting up IP aliases on an interface. To do this, simply edit the file /etc/hostname.if. This file is read upon boot by the netstart(8) script, which is part of the rc startup hierarchy. For the example, we assume that the user has an interface dc0 and is on the network Other important information:

A few side notes about aliases. In OpenBSD, you only use the interface name. There is no difference between the first alias and the second alias. Unlike some other operating systems, OpenBSD doesn't refer to them as dc0:0, dc0:1. If you are referring to a specific aliased IP address with ifconfig, or adding an alias, be sure to use ifconfig int alias instead of just ifconfig int at the command line. You can delete aliases with ifconfig int delete.

Assuming you are using multiple IP addresses which are in the same IP subnet with aliases, your netmask setting for each alias becomes They do not need to follow the netmask of the first IP bound to the interface. In this example, /etc/hostname.dc0, two aliases are added to the device dc0, which was configured as netmask

$ cat /etc/hostname.dc0
inet NONE media 100baseTX
inet alias
inet alias
Once you've made this file, it just requires a reboot for it to take effect. You can, however, bring up the aliases by hand using the ifconfig(8) utility. To bring up the first alias, you would use the command:
# ifconfig dc0 inet alias netmask
(but again, a reboot is recommended to make sure you entered everything as you expected it to be!)

To view these aliases, you must use the command:

$ ifconfig -A
        media: Ethernet manual
        inet netmask 0xffffff00 broadcast
        inet netmask 0xffffffff broadcast

Adding and replacing NICs

You may have to replace or add a network adapter on an OpenBSD system, maybe upgrading the capabilities of the system or repairing failed hardware. This will require some reconfiguration. The good news is that it's relatively easy, though there are some things to be aware of.

The key is understanding how OpenBSD names NICs. Unlike some OSs that try to remember any network adapter the installed OS has ever seen, OpenBSD does not remember a NIC's identification between boots -- it names them in order that they are found. In most cases, this is far simpler for you, as the system will always identify a NIC the same way in the same hardware configuration, and when configurations change, the results are easily understood.

Here are some cases:

In addition to the hostname.if files, any other file that deals with hardware interfaces will have to be adjusted. Some likely candidates might include:

How do I filter and firewall with OpenBSD?

Packet Filter (from here on referred to as PF) is OpenBSD's system for filtering IP traffic and doing Network Address Translation. PF is also capable of normalizing and conditioning IP traffic, providing bandwidth control and packet prioritization, and can be used to create powerful and flexible firewalls. It is described in the PF User's Guide.

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol is a way to configure network interfaces "automatically." OpenBSD can be a DHCP server (configuring other machines), a DHCP client (configured by another machine) or, in some cases, both.

DHCP client

To use the DHCP client included with OpenBSD, dhclient(8), edit /etc/hostname.xl0. This is assuming your main Ethernet interface is xl0. Yours might be em0 or fxp0 or something else.

# echo dhcp > /etc/hostname.xl0

This will cause OpenBSD to automatically start the DHCP client on boot. OpenBSD will gather its IP address, default gateway, and DNS servers from the DHCP server.

If you want to start a DHCP client from the command line, make sure /etc/dhclient.conf exists, then run:

# dhclient xl0
Where xl0 is the interface on which you want to receive DHCP.

No matter how you start the DHCP client, you can edit the /etc/dhclient.conf file to not update your DNS according to the DHCP server's idea of DNS by first uncommenting the "request" lines in it. They are examples of the default settings, but you need to uncomment them to override dhclient's defaults.

request subnet-mask, broadcast-address, time-offset, routers,
      domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
Then remove domain-name-servers. Of course, you may want to remove host-name, or other settings too.

By changing options in your dhclient.conf(5) file, you're telling the DHCP client how to build your resolv.conf(5) file. The DHCP client overrides any information you already have in resolv.conf with the information it retrieves from the DHCP server. Therefore, you'll lose any changes you made manually to resolv.conf.

There are two mechanisms available to prevent this:

An example would be if you're using DHCP but want to append lookup file bind to the resolv.conf created by dhclient. There is no option for this in dhclient.conf, so you must use resolv.conf.tail to preserve this.

# echo "lookup file bind" > /etc/resolv.conf.tail
Now your resolv.conf should include "lookup file bind" at the end.
$ cat /etc/resolv.conf
lookup file bind

DHCP server

If you want to use OpenBSD as a DHCP server, enable the dhcpd(8) daemon at startup. For example:

# rcctl enable dhcpd
This will run dhcpd and attach to all NICs which have valid configurations in dhcpd.conf(5). You may specify individual interfaces instead by naming them explicitly. For example:
# rcctl set dhcpd flags xl1 xl2 xl3

Then edit /etc/dhcpd.conf. The options are pretty self-explanatory.

option  domain-name "";
option  domain-name-servers,;
subnet netmask {
        option routers;
This will tell your DHCP clients that the domain to append to DNS requests is (so, if the user types in 'telnet joe' then it will send them to It will point them to DNS servers and For hosts that are on the same network as an Ethernet interface on the OpenBSD machine, which is in the range, it will assign them an IP address between and It will set their default gateway as

If you want to start dhcpd(8) from the command line after editing /etc/dhcpd.conf, run:

# rcctl start dhcpd
If there were fatal configuration errors, it will exit and let you know that it failed to start. You can usually see why in /var/log/messages or /var/log/daemon.

If you are serving DHCP to a Windows box, you may want dhcpd(8) to give the client a 'WINS' server address. To make this happen, just add the following line to your /etc/dhcpd.conf:

option    netbios-name-servers;
where is the IP of your Windows or Samba server. See dhcp-options(5) for more options that your DHCP clients may want.

Using NFS

NFS, or the Network File System, is used to share a filesystem over the network.

This section will go through the steps for a simple setup of NFS. This example details a server on a LAN, with clients accessing NFS on the LAN. It does not talk about securing NFS. We presume you have already set up packet filtering or other firewalling protection to prevent outside access. If you are allowing outside access to your NFS server, and you have any kind of sensitive data stored on it, we strongly recommend that you employ IPsec. Otherwise, people can potentially see your NFS traffic. Someone could also pretend to be the IP address which you are allowing into your NFS server. There are several attacks that can result. When properly configured, IPsec protects against these types of attacks.

Setting up an NFS server

These services must be enabled and running on the server:

By default, each of these is disabled in OpenBSD. If you want them enabled, run the following commands:

# rcctl enable portmap mountd nfsd
# rcctl set nfsd flags -tun 4
The next step is to configure the list of filesystems that will be made available for clients to mount.

In this example, we have a server with IP address This server will be serving NFS only to clients within its own subnet. All of this is configured in the /etc/exports file. This file lists which filesystems you wish to have accessible via NFS and defines who is able to access them. There are many options that you can use in /etc/exports; it is best that you read the exports(5) man page. For our example server, we've setup an exports file that looks like this:

# NFS exports Database
# See exports(5) for more information.  Be very careful, misconfiguration
# of this file can result in your filesystems being readable by the world.
/work -alldirs -ro -network=10.0.0 -mask=
This means that the local filesystem /work will be made available via NFS. The -alldirs option specifies that clients will be able to mount at any point under /work as well as /work itself. For example, if there was a directory called /work/monday, clients could mount /work (and have access to all files/directories underneath that directory) or they could mount /work/monday and have access to just the files/directories contained there. The -ro option specifies that clients will only be granted read-only access. The last two arguments specify that only clients within the network using a netmask of will be authorized to mount this filesystem. This is important for some servers that are accessible by different networks.

Another important security note: don't just add a filesystem to /etc/exports without some kind of list of allowed host(s). Without a list of hosts which can mount a particular directory, anyone who can reach your server will be able to mount your NFS exported directories.

Now you can start the server services. You can either reboot (after enabling them as per the instructions above) or start them manually.

# rcctl start portmap mountd nfsd
The nfsd_flags enable TCP (-t) and UDP (-u) connections and enable 4 instances (-n) of nfsd to run. You should set an appropriate number of NFS server instances handle the maximum number of concurrent client requests that you want to service by adjusting the flags nfsd is started with.

You're now ready to mount the exported filesystems from the client(s).

Remember: If you make changes to /etc/exports while NFS is already running, you need to make mountd aware of this! Just HUP mountd and the changes will take affect.

# rcctl reload mountd

Mounting NFS Filesystems

NFS filesystems can be mounted from a client without needing to enable any services or daemons. They can be mounted just like any other filesystem.

NFS filesystems should be mounted via mount(8), or more specifically, mount_nfs(8). To mount the /work filesystem on host to local filesystem /mnt, do this (note that you don't need to use an IP address; mount will resolve host names):

# mount -t nfs /mnt
To have that filesystem mounted at boot, add something like this to fstab(5):
# echo ' /mnt nfs rw 0 0' >> /etc/fstab
It is important that you use 0 0 at the end of this line so that your computer does not try to fsck the NFS filesystem on boot. The other standard security options, such as noexec, nodev, and nosuid, should also be used where applicable. For example: /mnt nfs rw,nodev,nosuid 0 0
This way, no devices or setuid programs on the NFS server can subvert security measures on the NFS client. If you are not mounting programs that you expect to run on the NFS client, add noexec to this list.

When accessing an NFS mount as the root user, the server automatically maps root's access to username "nobody" and group "nobody." This is important to know when considering file permissions. For example, take a file with these permissions:

-rw-------    1 root     wheel           0 Dec 31 03:00 _daily.B20143
If this file was on an NFS share and the root user tried to access this file from the NFS client, access would be denied. This is because the server uses the credentials of the user "nobody" when root tries to access the file. Since the user nobody doesn't have permissions to access the file, access is denied.

The user and group that root are mapped to are configurable via the exports(5) file on the NFS server.

Checking Stats on NFS

One thing to check to ensure NFS is operating properly is that all the daemons have properly registered with RPC. To do this, use rpcinfo(8).
$ rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    633  mountd
    100005    3   udp    633  mountd
    100005    1   tcp    916  mountd
    100005    3   tcp    916  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
During normal usage, there are a few other utilities that allow you to see what is happening with NFS. One is showmount(8), which allows you to view what is currently mounted and who is mounting it. There is also nfsstat(1), which shows much more verbose statistics. To use showmount(8), try /usr/bin/showmount -a host. For example:
$ showmount -a
All mount points on
This output shows that the client has mounted the /work export being served from the server at

Setting up a network bridge in OpenBSD

A bridge(4) is a link between two or more separate networks. Unlike a router, packets transfer through the bridge "invisibly" -- logically, the two network segments appear to be one segment to nodes on either side of the bridge. The bridge will only forward packets that have to pass from one segment to the other, so among other things, they provide an easy way to reduce traffic in a complex network and yet allow any node to access any other node when needed.

Note that because of this "invisible" nature, an interface in a bridge may or may not have an IP address of its own. If it does, the interface has effectively two modes of operation, one as part of a bridge, the other as a normal, stand-alone NIC. If neither interface has an IP address, the bridge will pass network data, but will not be externally maintainable (which can be a feature).

A simple example of a bridge application

One of my computer racks has a number of older systems, none of which have a built-in 10BASE-TX NIC. While they all have an AUI or AAUI connector, my supply of transceivers is limited to coax. One of the machines on this rack is an OpenBSD-based terminal server which is always on and connected to the high-speed network. Adding a second NIC with a coax port will allow me to use this machine as a bridge to the coax network.

This system has two NICs in it now, an Intel EtherExpress/100 fxp0 and a 3c590-Combo card ep0 for the coax port. fxp0 is the link to the rest of my network and will thus have an IP address, while ep0 is going to be for bridging only, and will have no IP address. Machines attached to the coax segment will communicate as if they were on the rest of my network. So, how do we make this happen?

The file hostname.fxp0 contains the configuration info for the fxp0 card. This machine is set up using DHCP, so its file looks like this:

$ cat /etc/hostname.fxp0
No surprises here.

The ep0 card is a bit different, as you might guess:

$ cat /etc/hostname.ep0
up media 10base2
Here, we are instructing the system to activate this interface using ifconfig(8) and setting it to 10BASE-2 (coax). No IP address or similar information needs to be specified for this interface. The options the ep card accepts are detailed in its man page.

Now, we need to set up the bridge. Bridges are initialized by the existence of a file named something like hostname.bridge0. Here is an example for my situation here:

$ cat /etc/hostname.bridge0
add fxp0
add ep0
This is saying set up a bridge consisting of the two NICs, fxp0 and ep0, and activate it. Does it matter which order the cards are listed? No, remember a bridge is very symmetrical -- packets flow in and out in both directions.

That's it! Reboot and you now have a functioning bridge.

A bridge acting as a DHCP server

Let's say we have a small system which has four vr(4) interfaces, vr0 through vr3. We want to bridge vr1, vr2 and vr3 together, leaving out vr0 for an uplink (a cable modem for instance). We also want to serve IP addresses through DHCP over the bridged interfaces. Being a DHCP server and an uplink router, the box needs to have an IP address on the bridged network (contrary to the previous example in which the bridging box was not visible on the network).

It is not possible to assign an IP address directly to a bridge interface. The IP address should be added to one of the member interfaces, but we cannot use a physical interface as the link might be down, in which case the address would not be reachable. Fortunately, there is the vether(4) virtual Ethernet interface driver that can be used for this purpose. We will add it to the bridge, assign the IP address to it and make dhcpd(8) listen there.


First, mark the vr1, vr2 and vr3 interfaces as up:

# echo up > /etc/hostname.vr1
# echo up > /etc/hostname.vr2
# echo up > /etc/hostname.vr3
Then create the vether0 configuration:
# echo 'inet' > /etc/hostname.vether0
We configure the bridge interface to contain all the above interfaces:
$ cat /etc/hostname.bridge0
add vether0
add vr1
add vr2
add vr3
And finally we make dhcpd(8) listen on the vether0 interface:
# rcctl set dhcpd flags vether0
Reboot and voilà!

Filtering on a bridge

While there are certainly uses for a simple bridge like this, it is likely you might want to DO something with the packets as they go through your bridge. As you might expect, Packet Filter can be used to restrict what traffic goes through your bridge.

Keep in mind, by the nature of a bridge, the same data flows through both interfaces, so you only need to filter on one interface. Your default "pass all" statements would look something like this:

pass in  on ep0  all
pass out on ep0  all
pass in  on fxp0 all
pass out on fxp0 all
Now, let's say I wish to filter traffic hitting these old machines. I want only web and SSH traffic to reach them. In this case, we are going to let all traffic in and out of the ep0 interface, but filter on the fxp0 interface.
# Pass all traffic through ep0
pass in  quick on ep0 all
pass out quick on ep0 all

# Block fxp0 traffic
block in  on fxp0 all
block out on fxp0 all

pass in quick on fxp0 proto tcp from any to any port { 22 80 }
Note that this rule set will prevent anything but incoming HTTP and SSH traffic from reaching either the bridge machine or any of the other nodes "behind" it. Other results could be had by filtering the other interface.

To monitor and control the bridge you have created, use the ifconfig(8) command, which can also be used to create a bridge after boot.

Tips on bridging

How do I boot using PXE? (i386, amd64)

The Preboot Execution Environment, or PXE, is a way to boot a computer from the network, rather than from a hard disk, USB drive or CD-ROM. The technology was originally developed by Intel, but is supported by most major network card and computer manufacturers now. Traditionally, PXE booting is done using ROMs on the NIC or mainboard of the system, but boot floppies are available from various sources that will permit PXE booting, as well. Many ROMs on older NICs support network booting but do NOT support PXE; OpenBSD/i386 or amd64 cannot currently be booted across the network by these.

How does PXE booting work?

First, it is wise to understand how OpenBSD boots on i386 and amd64 platforms. Upon starting the boot process, the PXE-capable NIC broadcasts a DHCP request over the network. The DHCP server will assign the adapter an IP address, and gives it the name of a file to be retrieved from a tftp(1) server and executed. This file then conducts the rest of the boot process. For OpenBSD, the file is pxeboot, which takes the place of the standard boot(8) file. pxeboot(8) is then able to load and execute a kernel (such as bsd or bsd.rd) from the same TFTP server.

How do I do it?

The first and obvious step is you must have a pxeboot-capable computer or network adapter. Some documentation will indicate all modern NICs and computers are PXE capable, but this is clearly not true -- many low cost systems do not include PXE ROMs or use an older network boot protocol. You also need a properly configured DHCP and TFTP server.

Assuming an OpenBSD machine is the source of the boot files (this is NOT required), your DHCP server's dhcpd.conf file will need to have the following line:

filename "pxeboot";
to have the DHCP server offer that file to the booting workstation. For example:
shared-network LOCAL-NET {
        option  domain-name "";
        option  domain-name-servers,;

        subnet netmask {
                option routers;
                filename "pxeboot";
                default-lease-time 86400;
                max-lease-time 90000;

You will also have to activate the tftpd(8) daemon.

# rcctl enable tftpd
# rcctl set tftpd flags /tftpboot
It serves files from a particular directory, and in the case that directory is /tftpboot, which we will use for this example. Obviously, this directory needs to be created and populated. Typically, you will have only a few files here for PXE booting: Note that /etc/boot.conf is only needed if the kernel you wish to boot from is not named bsd, or other pxeboot defaults are not as you need them (for example, you wish to use a serial console). You can test your tftpd(8) server using a tftp(1) client, making sure you can fetch the needed files.

When your DHCP and TFTP servers are running, you are ready to try it. You will have to activate the PXE boot on your system or network card; consult your system documentation. Once you have it set, you should see something similar to the following:

Intel UNDI, PXE-2.0 (build 067)
Copyright (C) 1997,1998 Intel Corporation

For Realtek RTL 8139(X) PCI Fast Ethernet Controller v1.00 (990420)

probing: pc0 com0 com1 apm pxe![2.1] mem[540k 28m a20=on]
disk: hd0*
net: mac 00:e0:c5:c8:cf:e1, ip, server
>> OpenBSD/i386 PXEBOOT 3.23
At this point, you have the standard OpenBSD boot prompt. If you simply type "bsd.rd" here, you will then fetch the bsd.rd file from the TFTP server.
>> OpenBSD/i386 PXEBOOT 3.23
boot> bsd.rd
booting tftp:bsd.rd: 4375152+733120 [58+122112+105468]=0x516d04
entry point at 0x100120

Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
The bsd.rd install kernel will now boot.

Can I boot OpenBSD kernels other than bsd.rd using PXE?

Yes, although with the tools currently in OpenBSD, PXE booting is primarily intended for installing the OS.

Using OpenNTPD

Accurate time is important for many computer applications. However, many people have noticed that their $5 watch can keep better time than their $2000 computer. In addition to knowing what time it is, it is also often important to synchronize computers so that they all agree on what time it is. For some time, has produced a Network Time Protocol (RFC1305, RFC2030) application, available through ports, which can be used to synchronize clocks on computers over the Internet. However, it is a non-trivial program to set up, has code that's difficult to audit and has a large memory requirement. In short, it fills an important role for some people, but it is far from a solution for all.

OpenNTPD is an attempt to resolve some of these problems, making a trivial-to-administer, safe and simple NTP-compatible way to have accurate time on your computer. OpenBSD's ntpd(8) is controlled with an easy to understand configuration file, ntpd.conf(5).

The OpenNTPD daemon is enabled by default at install time, which will result in your computer's clock slowly moving towards, then keeping itself synchronized to the time servers. Once your clock is accurately set, ntpd will hold it at a high degree of accuracy. However, if your clock is more than a few minutes off, it is highly recommended that you bring it close to accurate initially, as it may take days or weeks to bring a very-off clock to sync. You can do this using the -s option of ntpd(8) or any other way to accurately set your system clock.

"But OpenNTPD isn't as accurate as the daemon!"

This may be true, as that is not among OpenNTPD's design goals. It is intended to be free, simple, reliable and secure. There is no plan or desire to have OpenNTPD bloated with every imaginable feature.

"Someone has claimed that OpenNTPD is 'harmful'!"

Some people have not understood the goals of OpenNTPD -- a simple, secure and easy to maintain way to keep your computer's clock accurate. If accurate time keeping is important, a number of users have reported better results from OpenNTPD than from's ntpd. If security is important, OpenNTPD's code is much more readable (and thus, auditable) and was written using native OpenBSD function calls like strlcpy, rather than more portable functions like strcpy. It was also written to be secure from the beginning, not "made secure" later. If having more people using time synchronization is valuable, OpenNTPD makes it much easier for larger numbers of people to use it. If this is "harmful," we're all for it.

There are applications where the ntpd is more appropriate; however it is felt that for a large majority of the users, OpenNTPD is more than sufficient.

A more complete response to this by one of the maintainers of OpenNTPD can be read here.

Why can't my other machines synchronize to OpenNTPD?

ntpd(8) does not listen on any address by default. So in order to use it as a server, you have to uncomment the "#listen on *" line in /etc/ntpd.conf and restart the ntp daemon. Of course, if you wish it to listen on a particular IP address rather than all available addresses and interfaces, replace the "*" with the desired address.

When you have ntpd(8) listening, it may happen that other machines still can't synchronize to it! A freshly started ntpd(8) daemon (for example, if you just restarted it after modifying ntpd.conf) refuses to serve time information to other clients until it adjusts its own clock to a reasonable level of stability first. When ntpd(8) considers its own time information stable, it announces it by a "clock now synced" message in /var/log/daemon. Even if the system clock is pretty accurate in the beginning, it can take up to 10 minutes to get in sync, and hours or days if the clock is not accurately set at the start.

What are my wireless networking options?

OpenBSD has support for a number of wireless chipsets: (AP) indicates card can be used as an access point.

Adapters based on these chips can be used much like any other network adapter to connect an OpenBSD system to an existing wireless network, configured using the standard ifconfig(8) utility. Please see the manual pages for precise details. Some of these cards can also be used in the "Host-Based Access Point" mode, permitting them to be made into the wireless access point for your network as part of your firewall.

Note that in order to use some of these cards, you will need to acquire the firmware files, which the manufacturers refuse to allow free distribution of, so they can not be included with OpenBSD. When possible, the man pages linked above include contact information so you can contact the right people at the manufacturers to let them know what you feel about this, or to let them know what other product you have purchased instead.

Another option to consider for using your OpenBSD-based firewall to provide wireless access is to use a conventional NIC and an external bridging Access Point. This has the added advantage of letting you easily position the antenna where it is most effective, which is often not directly on the back of your firewall.

Configuring your wireless adapter

Your wireless adapter can be configured through a hostname.if(5) file as other network adapters are, but as they have more options, they will often be more complicated.

An example of a wireless hostname file might be:

nwid puffyuberalles
wpakey puffyguffy
nwid puffyuberalles
wpakey puffyguffy
Note that the dhcp should be AFTER the other configuration lines, as the network adapter will not be able to request the DHCP until it is configured.

trunk(4)ing your wireless adapter

Many laptops have both a wireless and a hard-wired adapter. Sometimes, you may be directly connected to your high speed network and want the full performance of the wire, other times, you will be using the wireless. You probably don't want to reconfigure your machine each time you switch locations.

You COULD set up both interfaces with DHCP, but then you would have to wait for the unused interface to time out while booting, plus things would be a little confusing if you had both resources available, and switching between the two resources would be a bit annoying.

Using a trunk(4) device may simplify your life. Trunks are virtual interfaces made up of one or more other network interfaces. In this case, we will use a laptop with a wired bge0 and a wireless iwn0 interface. Using these two interfaces we will build an interface, trunk0, then use DHCP to get an IP address for this virtual interface. If we have a cable available, we want to use it, but if not we want to use the wireless interface.

To do this, we first configure the two physical ports. As we are just assigning them to a combined trunk0 interface, we won't do much of anything with the wired interface other than activate it:

# echo up > /etc/hostname.bge0
The wireless interface, however, needs a bit more configuration. It will need to attach to our wireless WPA-protected network:
$ cat /etc/hostname.iwn0
nwid puffynet
wpakey mysecretkey
Now, our trunk interface is defined like this:
$ cat /etc/hostname.trunk0
trunkproto failover trunkport bge0
trunkport iwn0
The trunk is set up to be in "failover" mode, so either interface can be used, but if both are available, it will prefer the bge0 port, since that is the first added to the trunk device.

How can I do equal-cost multipath routing?

Equal-cost multipath routing refers to having multiple routes in the routing table for the same network, such as the default route, When the kernel is doing a route lookup to determine where to send packets destined to that network, it can choose from any of the equal-cost routes. In most scenarios, multipath routing is used to provide redundant uplink connections, e.g., redundant connections to the Internet.

The route(8) command is used to add/change/delete routes in the routing table. The -mpath argument is used when adding multipath routes.

# route add -mpath default
# route add -mpath default
Verify the routes:
# netstat -rnf inet | grep default
default      UGS       2      134      -     fxp1
default        UGS       0      172      -     fxp2
In this example we can see that one default route points to which is accessible via the fxp1 interface, and the other points to which is accessible via fxp2.

Since the mygate(5) file does not yet support multipath default routes, the above commands should be added to the bottom of the hostname.if(5) files for the fxp1 and fxp2 interfaces. The /etc/mygate file should then be deleted.

$ tail -1 /etc/hostname.fxp1
!route add -mpath default
$ tail -1 /etc/hostname.fxp2
!route add -mpath default
Lastly, don't forget to activate the use of multipath routes by enabling the proper sysctl(3) variable.
# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1
Be sure to edit sysctl.conf(5) to make the changes permanent.

Now try a traceroute to different destinations. The kernel will load balance the traffic over each multipath route.

# traceroute -n
traceroute to (, 64 hops max, 60 byte packets
 1  19.337 ms  18.194 ms  18.849 ms
 2  17.642 ms  18.176 ms  17.731 ms
 3  110.486 ms  19.478 ms  100.949 ms
 4  32.772 ms  33.534 ms  32.835 ms

# traceroute -n
traceroute to (, 64 hops max, 60 byte packets
 1  14.175 ms  14.503 ms  14.58 ms
 2  13.664 ms  13.962 ms  13.445 ms
 3  13.964 ms  13.347 ms  13.788 ms
 4  30.177 ms  30.95 ms  30.593 ms
For more information about how the route is chosen, please refer to RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".

It's worth noting that if an interface used by a multipath route goes down (i.e., loses carrier), the kernel will still try to forward packets using the route that points to that interface. This traffic will of course be blackholed and end up going nowhere. It's highly recommended to use ifstated(8) to check for unavailable interfaces and adjust the routing table accordingly.