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 PC's at home, one with FreeBSD and one with Win95; the idea is to use the FreeBSD box to connect to the Internet and then be able to access the Internet from the Windows95 box through the FreeBSD box. This is really just a special case of the previous question.

... and the answer is yes! In FreeBSD 3.X, 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.

If you are using kernel-mode PPP, or have an Ethernet connection to the Internet, you will have to use natd(8). Please look at the natd section of this FAQ.

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.

If you have a local subnet (one or more local machines), but have been allocated only a single IP number from your Internet provider (or even if you receive a dynamic IP number), you may want to look at the natd(8) program. natd(8) allows you to connect an entire subnet to the Internet using only a single IP number.

The ppp(8) program has similar functionality built in via the -nat switch. The alias library ( libalias(3)) is used in both cases.

Please see the PLIP section of the Handbook.

Because they aren't necessary. In the Berkeley networking framework, network interfaces are only directly accessible by kernel code. Please see the /etc/rc.network file and the manual pages for the various network programs mentioned there for more information. If this leaves you totally confused, then you should pick up a book describing network administration on another BSD-related operating system; with few significant exceptions, administering networking on FreeBSD is basically the same as on SunOS 4.0 or Ultrix.

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

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

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

Sun workstations running SunOS 4.X only accept mount requests from a privileged port; try

    # 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 thru them.

Multicast host operations are fully supported in FreeBSD 2.0 and later by default. If you want your box to run as a multicast router, you will need to recompile your kernel with the MROUTING option and run mrouted(8). FreeBSD 2.2 and later 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 <[email protected]>, with some more modern additions:

You will probably find that the host is actually in a different domain; for example, if you are in foo.example.org and you wish to reach a host called mumble in the example.org domain, you will have to refer to it by the fully-qualified domain name, mumble.example.org, instead of just mumble.

Traditionally, this was allowed by BSD BIND resolvers. However the current version of bind (see named(8)) that ships with FreeBSD no longer provides default abbreviations for non-fully qualified domain names other than the domain you are in. So an unqualified host mumble must either be found as mumble.foo.example.org, or it will be searched for in the root domain.

This is different from the previous behavior, where the search continued across mumble.example.org, and mumble.edu. Have a look at RFC 1535 for why this was considered bad practice, or even a security hole.

As a good workaround, you can place the line

    search foo.example.org example.org

instead of the previous

    domain foo.example.org

into your /etc/resolv.conf file (see resolv.conf(5)). However, make sure that the search order does not go beyond the ``boundary between local and public administration'', as RFC 1535 calls it.

If you have compiled your kernel with the IPFIREWALL option, you need to be aware that the default policy as of 2.1.7R (this actually changed during 2.1-STABLE development) 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 section.

Please see the Handbook's Firewalls section, specifically the section on IPFW Overhead & Optimization.

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 socket package, available in the ports tree in category ``sysutils''. 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 (or more specifically, ipfw(4)); ALTQ is available for free; Bandwidth Manager from Emerging Technologies is a commercial product.

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

    pseudo-device bpf        # Berkeley Packet Filter

After rebooting, create the device node. This can be accomplished by going to the /dev directory and running:

    # sh MAKEDEV bpf0

Please see the Handbook entry on device nodes for more information on creating devices.

Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as net/smbfs in the ports collection, or in the base system as of 4.5-RELEASE and later.

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.

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 XFree86 suite. If you want to use the GUI included with CVSup you will need to install XFree86 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 port. This is covered in more detail in the CVSup section of the Handbook.