Chapter 12 Networking

“Diskless booting” means that the FreeBSD box is booted over a network, and reads the necessary files from a server instead of its hard disk. For full details, please read the Handbook entry on diskless booting

Yes. Please see the Handbook entry on advanced networking, specifically the section on routing and gateways.

Typically, people who ask this question have two PCs at home, one with FreeBSD and one with some version of Windows the idea is to use the FreeBSD box to connect to the Internet and then be able to access the Internet from the Windows box through the FreeBSD box. This is really just a special case of the previous question and works perfectly well.

If you are using dialup to connect to the Internet user-mode ppp(8) contains a -nat option. If you run ppp(8) with the -nat option, set gateway_enable to YES in /etc/rc.conf, and configure your Windows machine correctly, this should work fine. For more information, please see the ppp(8) manual page or the Handbook entry on user PPP.

If you are using kernel-mode PPP or have an Ethernet connection to the Internet, you need to use natd(8). Please look at the natd section of the Handbook for a tutorial.

Yes. See the manual pages for slattach(8), sliplogin(8), ppp(8), and pppd(8). ppp(8) and pppd(8) provide support for both incoming and outgoing connections, while sliplogin(8) deals exclusively with incoming connections, and slattach(8) deals exclusively with outgoing connections.

For more information on how to use these, please see the Handbook chapter on PPP and SLIP.

If you only have access to the Internet through a “shell account”, you may want to have a look at the net/slirp package. It can provide you with (limited) access to services such as ftp and http direct from your local machine.

Yes. If you want to use NAT over a user PPP connection, please see the Handbook entry on user PPP. If you want to use NAT over some other sort of network connection, please look at the natd section of the Handbook.

Please see the PLIP section of the Handbook.

If the alias is on the same subnet as an address already configured on the interface, then add netmask 0xffffffff to your ifconfig(8) command-line, as in the following:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

Otherwise, just specify the network address and netmask as usual:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

You can read more about this in the FreeBSD Handbook.

If you want to use the other ports, you will have to specify an additional parameter on the ifconfig(8) command line. The default port is link0. To use the AUI port instead of the BNC one, use link2. These flags should be specified using the ifconfig_* variables in /etc/rc.conf (see rc.conf(5)).

Certain PC network cards are better than others (to put it mildly) and can sometimes cause problems with network intensive applications like NFS.

See the Handbook entry on NFS for more information on this topic.

Some versions of the Linux NFS code only accept mount requests from a privileged port; try to issue the following command:

# mount -o -P linuxbox:/blah /mnt

Sun workstations running SunOS™ 4.X only accept mount requests from a privileged port; try the following command:

# mount -o -P sunbox:/blah /mnt

The most frequent problem is not understanding the correct format of /etc/exports. Please review exports(5) and the NFS entry in the Handbook, especially the section on configuring NFS.

Try disabling the TCP extensions in /etc/rc.conf (see rc.conf(5)) by changing the following variable to NO:

tcp_extensions=NO

Xylogic's Annex boxes are also broken in this regard and you must use the above change to connect through them.

FreeBSD supports multicast host operations by default. If you want your box to run as a multicast router, you need to recompile your kernel with the MROUTING option and run mrouted(8). FreeBSD will start mrouted(8) at boot time if the flag mrouted_enable is set to YES in /etc/rc.conf.

MBONE tools are available in their own ports category, mbone. If you are looking for the conference tools vic and vat, look there!

Here is a list compiled by Glen Foster <gfoster@driver.nsta.org>, with some more modern additions:

See the answer in the FreeBSD Handbook.

If you have compiled your kernel with the IPFIREWALL option, you need to be aware that the default policy is to deny all packets that are not explicitly allowed.

If you had unintentionally misconfigured your system for firewalling, you can restore network operability by typing the following while logged in as root:

# ipfw add 65534 allow all from any to any

You can also set firewall_type="open" in /etc/rc.conf.

For further information on configuring a FreeBSD firewall, see the Handbook chapter.

Possibly because you want to do network address translation (NAT) and not just forward packets. A “fwd” rule does exactly what it says; it forwards packets. It does not actually change the data inside the packet. Say we have a rule like:

01000 fwd 10.0.0.1 from any to foo 21

When a packet with a destination address of foo arrives at the machine with this rule, the packet is forwarded to 10.0.0.1, but it still has the destination address of foo! The destination address of the packet is not changed to 10.0.0.1. Most machines would probably drop a packet that they receive with a destination address that is not their own. Therefore, using a “fwd” rule does not often work the way the user expects. This behavior is a feature and not a bug.

See the FAQ about redirecting services, the natd(8) manual, or one of the several port redirecting utilities in the Ports Collection for a correct way to do this.

You can redirect FTP (and other service) request with the sysutils/socket port. Simply replace the service's command line to call socket instead, like so:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

where ftp.example.com and ftp are the host and port to redirect to, respectively.

There are three bandwidth management tools available for FreeBSD. dummynet(4) is integrated into FreeBSD as part of ipfw(4). ALTQ has been integrated into FreeBSD as part of pf(4). Bandwidth Manager from Emerging Technologies is a commercial product.

You are running a program that requires the Berkeley Packet Filter (bpf(4)), but it is not in your kernel. Add this to your kernel config file and build a new kernel:

device bpf        # Berkeley Packet Filter

Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as mount_smbfs(8) in the base system.

This is the kernel telling you that some activity is provoking it to send more ICMP or TCP reset (RST) responses than it thinks it should. ICMP responses are often generated as a result of attempted connections to unused UDP ports. TCP resets are generated as a result of attempted connections to unopened TCP ports. Among others, these are the kinds of activities which may cause these messages:

• Brute-force denial of service (DoS) attacks (as opposed to single-packet attacks which exploit a specific vulnerability).

• Port scans which attempt to connect to a large number of ports (as opposed to only trying a few well-known ports).

The first number in the message tells you how many packets the kernel would have sent if the limit was not in place, and the second number tells you the limit. You can control the limit using the net.inet.icmp.icmplim sysctl variable like this, where 300 is the limit in packets per second:

# sysctl -w net.inet.icmp.icmplim=300

If you do not want to see messages about this in your log files, but you still want the kernel to do response limiting, you can use the net.inet.icmp.icmplim_output sysctl variable to disable the output like this:

# sysctl -w net.inet.icmp.icmplim_output=0

Finally, if you want to disable response limiting, you can set the net.inet.icmp.icmplim sysctl variable (see above for an example) to 0. Disabling response limiting is discouraged for the reasons listed above.

This means that some device on your local Ethernet is using a MAC address in a format that FreeBSD does not recognize. This is probably caused by someone experimenting with an Ethernet card somewhere else on the network. You will see this most commonly on cable modem networks. It is harmless, and should not affect the performance of your FreeBSD machine.

Because a packet is coming from outside the network unexpectedly. To disable them, set net.link.ether.inet.log_arp_wrong_iface to 0.

First, see if the error message you are receiving is like the one shown below.

/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found

Errors like these are caused by installing the net/cvsup port on a machine which does not have the Xorg suite. If you want to use the GUI included with CVSup you will need to install Xorg now. Alternatively if you just wish to use CVSup from a command line you should delete the package previously installed. Then install the net/cvsup-without-gui or the net/csup port. If you have a recent FreeBSD release you may use csup(1). This is covered in more detail in the CVSup section of the Handbook.