This device uses the fxp(4) driver and is assigned the number 0 here.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
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.
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
index 3 priority 0 llprio 3
groups: lo
inet 127.0.0.1 netmask 0xff000000
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:02:b3:2b:10:f7
index 1 priority 0 llprio 3
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
index 4 priority 0 llprio 3
groups: pflog
This sample shows only one physical Ethernet interface: fxp0.
An IP is configured on it, hence the values
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255.
The UP and RUNNING flags are also set on it.
The netstart(8) script configures network interfaces at boot time using hostname.if(5) files, where "if" is replaced by the full name of each interface. The example above would use the file /etc/hostname.fxp0, containing the following options:
This hostname.fxp0 file also has an interactive equivalent:inet 10.0.0.38 255.255.255.0
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 ifconfig(8)'s create subcommand.# ifconfig fxp0 10.0.0.38 255.255.255.0
Here, the default domain name will be example.com, there will be two DNS resolvers, 125.2.3.4 and 125.2.3.5, and the hosts(5) file will be consulted before the DNS resolvers are.$ cat /etc/resolv.conf search example.com nameserver 125.2.3.4 nameserver 125.2.3.5 lookup file bind
Note that a few warnings may be produced when running this script if you are reconfiguring interfaces that have already been configured. Use ifconfig(8) to make sure that your interfaces were set up correctly.# sh /etc/netstart
Even though you can completely reconfigure networking on a running OpenBSD system, a reboot is recommended after any significant reconfiguration.
$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Interface default 10.0.0.1 UGS 4 16 - 12 fxp0 224/4 127.0.0.1 URS 0 0 32768 8 lo0 127/8 127.0.0.1 UGRS 0 0 32768 8 lo0 127.0.0.1 127.0.0.1 UH 2 15 32768 1 lo0 10.0.0/24 link#1 UC 1 4 - 4 fxp0 10.0.0.1 aa:0:4:0:81:d UHL 1 11 - 1 fxp0 10.0.0.38 127.0.0.1 UGHS 0 0 - 1 lo0 $ route show Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 10.0.0.1 UGS 4 16 - 12 fxp0 base-address.mcast localhost URS 0 0 32768 8 lo0 loopback localhost UGRS 0 0 32768 8 lo0 localhost localhost UH 2 15 32768 1 lo0 10.0.0/24 link#1 UC 1 4 - 4 fxp0 10.0.0.1 aa:0:4:0:81:d UHL 1 11 - 1 fxp0 10.0.0.38 localhost UGHS 0 0 - 1 lo0
Suppose you have a dc0 interface. You are on the network 192.168.0.0, the IP address for dc0 is 192.168.0.2 and the netmask is 255.255.255.0.
Assuming you are using multiple IP addresses which are in the same subnet with aliases, your netmask setting for each alias becomes 255.255.255.255. They do not need to follow the netmask of the first IP bound to the interface. In this example, two aliases are added to the interface dc0, which was configured as 192.168.0.2 with a netmask of 255.255.255.0.
Once you've created this file, run netstart or reboot. To view all aliases, use ifconfig -A.$ cat /etc/hostname.dc0 inet 192.168.0.2 255.255.255.0 inet alias 192.168.0.3 255.255.255.255 inet alias 192.168.0.4 255.255.255.255
OpenBSD will gather its IP address, default gateway and DNS servers from the DHCP server at startup time.dhcp
If you want to get an IP via DHCP from the command line, simply run:
Replace xl0 with your interface name.# dhclient xl0
The resolv.conf file will be overwritten by dhclient(8) if the DHCP server provides the domain-name, domain-search or domain-name-servers options. Any of these can be ignored, overridden or modified with appropriate statements in dhclient.conf(5). For example, if you wanted to use the DNS server at 1.2.3.4 rather than the one(s) the DHCP server provided, add the following:
Additionally, the file /etc/resolv.conf.tail can be used to append information if dhclient(8) does write resolv.conf.supersede domain-name-servers 1.2.3.4;
On the next boot, dhcpd will run and attach to all NICs that have valid configurations in dhcpd.conf(5). You may specify individual interfaces instead by naming them explicitly.# rcctl enable dhcpd
An example /etc/dhcpd.conf file might look like this:# rcctl set dhcpd flags em1 em2
# Home
subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.1.2;
option routers 192.168.1.1;
range 192.168.1.3 192.168.1.50;
}
# Guests
subnet 172.16.0.0 netmask 255.255.255.0 {
option domain-name-servers 209.244.0.3, 8.8.8.8;
option routers 172.16.0.1;
range 172.16.0.2 172.16.0.254;
}
There are two subnets in this example: a home network and a guest network.
Clients will automatically be given an IP address and pointed to the gateway
and DNS servers you specify.
See dhcp-options(5) for more
options.
The following cards support Host-based Access Point (HostAP) mode, permitting them to be used as a wireless access point:
In order to use some wireless cards, you will need to acquire firmware files with fw_update(1). Some manufacturers refuse to allow free distribution of their firmware, so it can't be included with OpenBSD.$ ifconfig ath0 media
Another option to consider: use a conventional NIC and an external bridging wireless access point for your OpenBSD-based firewall. 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.
An example of a hostname.if(5) file for a wireless client might be:
Note that the dhcp keyword should be after the other configuration lines, as the network adapter will not be able to send a DHCP request until it is configured.nwid puffyuberalles wpakey puffyguffy dhcp
To do this, we first activate the two physical ports, then assign them to trunk0.
The wireless interface, however, needs a bit more configuration. It will need to attach to our wireless WPA-protected network:# echo up > /etc/hostname.bge0
Now, our trunk interface is defined like this:$ cat /etc/hostname.iwn0 nwid puffynet wpakey mysecretkey up
The trunk is set up in failover mode, so either interface can be used. If both are available, it will prefer the bge0 port, since that is the first one added to the trunk device.$ cat /etc/hostname.trunk0 trunkproto failover trunkport bge0 trunkport iwn0 dhcp
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) 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.
Then create the vether0 configuration:# echo up > /etc/hostname.vr1 # echo up > /etc/hostname.vr2 # echo up > /etc/hostname.vr3
Configure the bridge interface to contain all the above interfaces:# echo 'inet 192.168.1.1 255.255.255.0 192.168.1.255' > /etc/hostname.vether0
And finally we make the DHCP daemon listen on the vether0 interface:$ cat /etc/hostname.bridge0 add vether0 add vr1 add vr2 add vr3 up
Reboot, and voilà!# rcctl set dhcpd flags vether0
The route(8) command is used to add/change/delete routes in the routing table. The -mpath argument is used when adding multipath routes.
Verify the routes:# route add -mpath default 10.130.128.1 # route add -mpath default 10.132.0.1
In this example we can see that one default route points to 10.130.128.1, which is accessible via the fxp1 interface, and the other points to 10.132.0.1, which is accessible via fxp2.# netstat -rnf inet | grep default default 10.130.128.1 UGS 2 134 - fxp1 default 10.132.0.1 UGS 0 172 - 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.
Lastly, don't forget to activate the use of multipath routes by enabling the proper sysctl(8) variable.$ tail -1 /etc/hostname.fxp1 !route add -mpath default 10.130.128.1 $ tail -1 /etc/hostname.fxp2 !route add -mpath default 10.132.0.1
Be sure to edit sysctl.conf(5) to make the changes permanent.# sysctl net.inet.ip.multipath=1 # sysctl net.inet6.ip6.multipath=1
Now try a traceroute to different destinations. The kernel will load balance the traffic over each multipath route.
For more information about how the route is chosen, please refer to RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".# traceroute -n 154.11.0.4 traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets 1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms 2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms 3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms 4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms # traceroute -n 154.11.0.5 traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets 1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms 2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms 3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms 4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms
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.
In the examples below, various IPv4 address ranges will be mentioned for different use cases:
Using vmctl(8)'s -L flag creates a local interface in the guest which will receive an address from vmm via DHCP. This essentially creates two interfaces: one for the host and the other for the VM.
The following line in /etc/pf.conf will enable Network Address Translation:
Reload the pf ruleset and the VM(s) can now connect to the internet.match out on egress from 100.64.0.0/10 to any nat-to (egress)
Create a vether0 interface that will have a private IPv4 address as defined above. In this example, we'll use the 10.0.0.0/8 subnet.
Create the bridge0 interface with the vether0 interface as a bridge port:# echo 'inet 10.0.0.1 255.255.255.0' > /etc/hostname.vether0 # sh /etc/netstart vether0
Ensure that NAT is set up properly if the guests on the virtual network need access beyond the physical machine. An adjusted NAT line in /etc/pf.conf might look like this:# echo 'add vether0' > /etc/hostname.bridge0 # sh /etc/netstart bridge0
The following lines in vm.conf(5) can be used to ensure that a virtual switch is defined:match out on egress from vether0:network to any nat-to (egress)
switch "my_switch" {
interface bridge0
}
vm "my_vm" {
...
interface { switch "my_switch" }
}
Inside the my_vm guest, it's now possible to assign vio0
an address on the 10.0.0.0/24 network and set the default route to
10.0.0.1.
For convenience, you may wish to set up a DHCP server on vether0.
Create the vether0 interface:
The vether0 interface will be used as the local interface for the host that is managed via DHCP on the host network.# echo 'up' > /etc/hostname.vether0 # sh /etc/netstart vether0
Create the bridge0 interface with the host network interface as a bridge port, along with the newly created vether0 interface. In this example, the host network interface is em0 - you should substitute the interface name that you wish to connect the VM to:
As done in the previous example, create or modify the vm.conf(5) file to ensure that a virtual switch is defined:# echo 'add em0' > /etc/hostname.bridge0 # echo 'add vether0' >> /etc/hostname.bridge0 # sh /etc/netstart bridge0
switch "my_switch" {
interface bridge0
}
vm "my_vm" {
...
interface { switch "my_switch" }
}
The my_vm guest can now participate in the host network as if it
were physically connected.
Note: If the host interface (em0 in the above example) is also configured using DHCP, dhclient(8) running on that interface may block DHCP requests from reaching guest VMs. In this case, you should select a different host interface not using DHCP, or terminate any dhclient(8) processes assigned to that interface before starting VMs, or use static IP addresses for the VMs.
This section will go through the steps for a simple NFS setup. The example details a server on a LAN, with clients accessing NFS on the LAN. It does not cover securing NFS. We presume you have already set up packet filtering or other firewalling protection to prevent outside access.
Then configure the list of filesystems that will be made available.# rcctl enable portmap mountd nfsd
In this example, we have a server with IP address 10.0.0.1. This server will be serving NFS only to clients within its own subnet. This is configured in the following exports(5) file:
The local filesystem /docs will be made available via NFS. The -alldirs option specifies that clients will be able to mount at any point under /docs as well as /docs itself. The -ro option specifies that clients will only be granted read-only access. The last two arguments specify that only clients within the 10.0.0.0 network using a netmask of 255.255.255.0 will be authorized to mount this filesystem.$ cat /etc/exports /docs -alldirs -ro -network=10.0.0 -mask=255.255.255.0
Now you can start the server services.
If you make changes to /etc/exports while NFS is already running, you need to make mountd aware of this:# rcctl start portmap mountd nfsd
# rcctl reload mountd
To mount the /docs filesystem on host 10.0.0.1 to local filesystem /mnt, run:
To have that filesystem mounted at boot, append a line to your fstab(5):# mount -t nfs 10.0.0.1:/docs /mnt
It is important that you use 0 0 at the end of this line so that your computer does not try to fsck(8) the NFS filesystem on boot.# echo '10.0.0.1:/docs /mnt nfs ro,nodev,nosuid 0 0' >> /etc/fstab
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:
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.-rw------- 1 root wheel 0 Dec 31 03:00 _daily.B20143
The user and group that root are mapped to are configurable via the exports(5) file on the NFS server.
$ rpcinfo -p 10.0.0.1
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
There are a few utilities that allow you to see what is happening with NFS.
showmount(8) allows you to view
what is currently mounted by whom.
There is also nfsstat(1), which
shows much more verbose statistics.