Chapter 10 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

Internet standards and good engineering practice prohibit us from providing packet forwarding by default in FreeBSD. You can however enable this feature by changing the following variable to YES in rc.conf(5):

    gateway_enable=YES          # Set to YES if this host will be a gateway

This option will put the sysctl(8) variable net.inet.ip.forwarding to 1.

In most cases, you will also need to run a routing process to tell other systems on your network about your router; FreeBSD comes with the standard BSD routing daemon routed(8) or for more complex situations you may want to try GaTeD (available from http://www.gated.org/) which supports FreeBSD as of 3_5Alpha7.

It is our duty to warn you that, even when FreeBSD is configured in this way, it does not completely comply with the Internet standard requirements for routers; however, it comes close enough for ordinary usage.

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 contains a -nat option. If you run ppp with the -nat, set gateway_enable to YES in /etc/rc.conf, and configure your Windows machine correctly, this should work fine.

More detailed information about setting this up can be found in the Pedantic PPP Primer by Steve Sims.

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.

There is a conflict between the cdefs.h file in the distribution and the one shipped with FreeBSD. Just remove compat/include/sys/cdefs.h.

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 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.

Get a laplink cable. Make sure both computer have a kernel with lpt driver support.

    # dmesg | grep lp
    lpt0 at 0x378-0x37f irq 7 on isa
    lpt0: Interrupt-driven
    lp0: TCP/IP capable interface

Plug in the laplink cable into the parallel interface.

Configure the network interface parameters for lp0 on both sites as root. For example, if you want connect the host max with moritz

                     max <-----> moritz
    IP Address    10.0.0.1      10.0.0.2

on max start

    # ifconfig lp0 10.0.0.1 10.0.0.2

on moritz start

    # ifconfig lp0 10.0.0.2 10.0.0.1

Thats all! Please read also the manpages lp(4) and lpt(4) .

You should also add the hosts to /etc/hosts.

    127.0.0.1               localhost.my.domain localhost
    10.0.0.1                max.my.domain max
    10.0.0.2                moritz.my.domain

To check if it works do:

on max:

    # ifconfig lp0
    lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
            inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000
    # netstat -r
    Routing tables
    
    Internet:
    Destination        Gateway          Flags     Refs     Use      Netif Expire
    moritz             max              UH          4   127592       lp0
    # ping -c 4 moritz
    PING moritz (10.0.0.2): 56 data bytes
    64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms
    64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms
    64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms
    64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms
    
    --- moritz ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms

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.

Add netmask 0xffffffff to your ifconfig(8) command-line like the following:

    # ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff

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 this passage from the exports(5) manual page correctly:

Each line in the file (other than comment lines that begin with a #) specifies the mount point(s) and export flags within one local server filesystem for one or more hosts. A host may be specified only once for each local filesystem on the server and there may be only one default entry for each server filesystem that applies to all other hosts.

This is made more clear by an example of a common mistake. If everything above /usr is part of one filesystem (there are no mounts above /usr) the following exports list is not valid:

    /usr/src   client
    /usr/ports client

There are two lines specifying properties for one filesystem, /usr, exported to the same host, client. The correct format is:

    /usr/src /usr/ports  client

To rephrase the passage from the manual page, the properties of one filesystem exported to a given host (world-wide exports are treated like another unique host) must all occur on one line. And yes, this does cause limitation in how you can export filesystems without ugly workarounds, but for most people, this is not an issue.

The following is an example of a valid export list, where /usr and /exports are local filesystems:

    # Export src and ports to client01 and client02, but only
    # client01 has root privileges on it
    /usr/src /usr/ports -maproot=0    client01
    /usr/src /usr/ports               client02
    # The "client" machines have root and can mount anywhere
    # up /exports. The world can mount /exports/obj read-only
    /exports -alldirs -maproot=0      client01 client02
    /exports/obj -ro

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!

For more information, see the Mbone Information Web.

Here is a list compiled by Glen Foster <gfoster@driver.nsta.org>, 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.

The answer to this depends mostly on your rule set and processor speed. For most applications dealing with Ethernet and small rule sets, the answer is, negligible. For those of you that need actual measurements to satisfy your curiosity, read on.

The following measurements were made using 2.2.5-STABLE on a 486-66. IPFW was modified to measure the time spent within the ip_fw_chk routine, displaying the results to the console every 1000 packets.

Two rule sets, each with 1000 rules were tested. The first set was designed to demonstrate a worst case scenario by repeating the rule:

    # ipfw add deny tcp from any to any 55555

This demonstrates worst case by causing most of IPFW's packet check routine to be executed before finally deciding that the packet does not match the rule (by virtue of the port number). Following the 999th iteration of this rule was an allow ip from any to any.

The second set of rules were designed to abort the rule check quickly:

    # ipfw add deny ip from 1.2.3.4 to 1.2.3.4

The nonmatching source IP address for the above rule causes these rules to be skipped very quickly. As before, the 1000th rule was an allow ip from any to any.

The per-packet processing overhead in the former case was approximately 2.703ms/packet, or roughly 2.7 microseconds per rule. Thus the theoretical packet processing limit with these rules is around 370 packets per second. Assuming 10Mbps Ethernet and a ~1500 byte packet size, we would only be able to achieve a 55.5% bandwidth utilization.

For the latter case each packet was processed in approximately 1.172ms, or roughly 1.2 microseconds per rule. The theoretical packet processing limit here would be about 853 packets per second, which could consume 10Mbps Ethernet bandwidth.

The excessive number of rules tested and the nature of those rules do not provide a real-world scenario -- they were used only to generate the timing information presented here. Here are a few things to keep in mind when building an efficient rule set:

• Place an established rule early on to handle the majority of TCP traffic. Do not put any allow tcp statements before this rule.

• Place heavily triggered rules earlier in the rule set than those rarely used (without changing the permissiveness of the firewall, of course). You can see which rules are used most often by examining the packet counting statistics with ipfw -a l.

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 commandline 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 integreated into FreeBSD (or more specifically, ipfw(4)); ALTQ is available for free; Bandwidth Manager from Emerging Technologies is a commercial product.

Probably not. FreeBSD 3.0 and later use a version of BIND that uses a random high-numbered port for outgoing queries. If you want to use port 53 for outgoing queries, either to get past a firewall or to make yourself feel better, you can try the following in /etc/namedb/named.conf:

    options {
            query-source address * port 53;
    };

You can replace the * with a single IP address if you want to tighten things further.

Congratulations, by the way. It is good practice to read your sockstat(1) output and notice odd things!

The Berkeley Packet Filter ( bpf(4)) driver needs to be enabled before running programs that utilize it. Add this to your kernel config file and build a new kernel:

    pseudo-device bpf        # Berkeley Packet Filter

Secondly, after rebooting you will have to create the device node. This can be accomplished by a change to the /dev directory, followed by the execution of:

    # sh MAKEDEV bpf0

Please see the handbook's entry on device nodes for more information on creating devices.

Use the sharity light package in the ports collection.

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.