Freebsd router

How I built the router I use at home, from hardware to configuration.

For one machine to be able to find another over a network,
there must be a mechanism in place to describe how to get
from one to the other. This is called routing
. A «route» is a defined pair of
addresses: a «destination» and a «gateway». The pair
indicates that if you are trying to get to this ,
communicate through this . There are three types of
destinations: individual hosts, subnets, and «default». The
«default route» is used if none of the other routes apply.
We will talk a little bit more about default routes later on.
There are also three types of gateways: individual hosts,
interfaces (also called «links»), and Ethernet hardware
addresses (MAC addresses).

This tutorial explains how to set up a FreeBSD
system that will act as a network router that takes advantage of the ported version of OpenBSD’s PF packet filter. A network router is a system that forwards packets from one interface to another.

1.

Install FreeBSD by using this
tutorial.

Now that you have FreeBSD installed, lets proceed with the next step.

2. FreeBSD Network Configuration

Open /etc/rc.conf in your favorite editor. You need to add a line for each network card present on the system, for example in our case we’ll use two network cards:

### rc.conf

# WAN connection

ifconfig_xl0=»inet 10.0.0.2 netmask 255.255.255.0″

#  If you are using dhcp for WAN connection use ifconfig_xl0=»dhcp»

# LAN connection

ifconfig_xl1=»inet 192.168.0.1 netmask 255.255.255.0″

# Default gateway

defaultrouter=»10.0.0.1″ # Set the gateway

# Enable ip forward

gateway_enable=»YES»

# Hostname

hostname=»freebsd.my.domain»

### end rc.conf

You have to replace xl0, xl1 with the correct device for your cards, and the addresses with the proper ones.

defaultrouter is needed only if you are not using dhpc for WAN connection.

NOTE:
If you configured the network during installation, some lines about the network cards may be already present. Double check /etc/rc.conf before adding any lines.

You will also have to edit /etc/hosts to add the names and the IP addresses of various machines of the LAN, if they are not already there.

127.0.0.1        localhost localhost.my.domain

192.168.0.1    freebsdrouter.my.domain freebsdrouter

Set the DNS in /etc/resolv.conf :

NOTE:
You need to manually set up the nameserver only if you are not using dhcp for WAN connection.

3. Set up DHCP Server

The Dynamic Host Configuration Protocol (DHCP) is a network protocol used by hosts (DHCP clients) to retrieve IP address assignments and other configuration information. Each computer connected to a network must have a unique IP, and without DHCP TCP/IP information must be assigned manually on each computer. D HCP Server (or DHCPd) is the server that provides the DHCP client the information it needed.

# cd /usr/ports/net/isc-dhcp3-server

# make install clean

Next we will configure the DHCP service. Start off by copying a sample configuration file to /usr/local/etc.

# cp /usr/local/etc/dhcpd.conf.sample /usr/local/etc/dhcpd.conf

Then edit /usr/local/etc/dhcpd.conf. (local DNS server,lease time, the network gateway, and the available IP address range).  Below is an example configuration.

### dhcpd.conf

# name server

option domain-name-servers 10.0.0.1;

# lease time

default-lease-time 600;

max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local

# network, the authoritative directive should be uncommented.

authoritative;

# ad-hoc DNS update scheme — set to «none» to disable dynamic DNS updates.

ddns-update-style none;

# Use this to send dhcp log messages to a different log file

# you also have to hack syslog.conf to complete the redirection

log-facility local7;

Enable dhcp to start on boot by modifying /etc/rc.conf.

dhcpd_enable=YES

dhcpd_ifaces=»xl1″ # LAN card

4. Set up FreeBSD Firewall using OpenBSD’s PF packet filter

A firewall (in this context) is a set of rules that allows or denies certain types of network packets from entering or leaving your FreeBSD router. This section deals with building a firewall.

We’ll use one of the example PF configuration files as a basis for our configuration.

This sample file has everything we need for a basic FreeBSD router.

### pf.conf

### macross

## internal and external interfaces

int_if = «xl1»

ext_if = «xl0»

### nat/rdr

# NAT traffic from internal network to external network through external

# interface

nat on $ext_if from $int_if:network to any -> ($ext_if)

# redirect FTP traffic to FTP proxy on localhost:8021

# requires ftp-proxy to be enabled in /etc/inetd.conf

rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021

# allow access to tcp_services on external interface

pass in on $ext_if inet proto tcp from any to ($ext_if) port

$tcp_services flags S/SA keep state

# allow in ping replies

pass in inet proto icmp all icmp-type $icmp_types keep state

# allow all traffic from internal network to internal interface

pass in  on $int_if from $int_if:network to any keep state

pass out on $int_if from any to $int_if:network keep state

# pfctl -n -f /etc/pf.conf

### rc.conf

pf_enable=»YES»                           # Enable PF (load module if required)

pf_rules=»/etc/pf.conf»               # rules definition file for pf

pf_flags=»»                                      # additional flags for pfctl startup

pflog_enable=»YES»                     # start pflogd

pflog_logfile=»/var/log/pflog»  # where pflogd should store the logfile

pflog_flags=»»                                 # additional flags for pflogd startup

pflogd_enable=»YES»

pfsync_enable=»YES»

### end rc.conf

Now you have to reboot the system for the changes to take effect.

# shutdown -r now

When the system comes back up, the LAN clients should be able to access the Internet through this FreeBSD router.

Настройка маршрутизатора на базе FreeBSD сервера (freebsd router firewall nat rip)

  Ключевые слова:   freebsd 
,  router 
,  firewall 
,  nat 
,  rip 
, (  найти похожие документы 
) 
  Date: Mon, 27 Feb 2007 14:31:37 +0000 (UTC)    Subject: Настройка маршрутизатора на базе FreeBSD сервера   
 Список источников 
 
 Глава1: настройка роутинга пакетов из одной сети в другую, firewall 
 
 Глава2: настройка трансляции адресов 
 
 Глава3: настройка доступа к internet через выданный внешней сетью шлюз, для внутренней сети.  Список источников  По адресу  http://procool.ru/interesting/gw_sett.txt  можно скачать текст статьи.
Процесс установки и базовую настройку системы я опущу, так как
она не входит в данный раздел.
Предположим, что эти действия уже произведены, система поставлена,
но не настроена под шлюз.  CHAPTER 1. Let me describe the problem: Set up a simple gateway designed to route packets from one network to another. Let's assume that we have two networks, and network cards on the gateway, respectively: rl0: 10.10.10.0/24 rl1: 192.168.0.0/16
First, we need to configure the local network on the rl0 and rl1 interfaces in
in accordance with the specified TOR. To do this, use the ifconfig program:
Let's assign the first addresses from these subnets to these interfaces, assuming that they
free:  /sbin/ifconfig rl0 10.10.10.1 netmask 255.255.255.0 /sbin/ifconfig rl0 192.168.0.1 netmask 255.255.0.0 To be sure, you should make sure that both interfaces see the network. About it
can be judged by the status of the interface "active" with positive and "no carrier"
with a negative outcome of this question when viewed through the utility
You can also check the existence of the network by sending several ICMP requests
known servers raised in these networks, for example, the ping utility. Wherein
make sure that such packets are accepted by trusted servers used
for testing.
If the devices are up and ICMP packets do not reach, then the network may
is faulty, but there is also a high probability that the server they
sent - blocks them and does not respond. Perhaps the same as on our gateway
there is already a firewall and does not allow access to send these packets. Often in the last
case, you can see a message about the impossibility of sending the package due to the lack of
access.
In order for the computer to be used as a router, in the kernel
you need to allow packet forwarding between interfaces. In FreeBSD for this
you need to run the command:
Now, it's worth setting up routing between the rl0 and rl1 interfaces.
Putting the gateway on the subnet 192.168.0.0/16 machine with ip address
10.10.10.1 computers from the 10.10.10.0/24 network will be able to access the network
192.168.0.0/16, and, in turn, computers on the subnet 192.168.0.0/16,
having set a machine with an ip address of 192.168.0.1 as a gateway, they will be able to contact
subnet 10.10.10.0/24, which is what we wanted.
The network setup was done manually and at the first reboot of the system -
will lose its power. Therefore, I recommend making it possible for it to be automatic.
installation at system startup. You can write a sh script in which you can simply specify all the
programs, but
The FreeBSD system is a standards system, it is designed so that if
another administrator came to your gateway - it became clear to him what was where and why,
and there were no further questions. This is part of the ideology of this system, and therefore I
I think it's worth sticking with.
It is customary to specify network interface settings in the boot file
/etc/rc.conf Looks like this:  ifconfig_rl0="inet 10.10.10.1 netmask 255.255.255.0" ifconfig_rl1="inet 192.168.0.1 netmask 255.255.0.0" Simply by adding these lines to the config.
You can allow packet forwarding between interfaces by adding to the same file
entry:  gateway_enable="YES" # Set to YES if this host will be a gateway.  By the way, in most Linux distributions, the same thing can be achieved by by specifying in the /etc/sysconfig/network file:
To apply the settings made in /etc/rc.conf, you can call the program
netstart:  FIREWALL Actually, the theme of the fiery wall cannot be missed in this section - as
no basic protection of the system from external influences, attacks, hacks. And not
only systems, but also the network that stands behind our gateway, i.e. it is not
just about the firewall on this machine - we are talking about the firewall on the entire subnet!
There are many types of firewalls - for example iptables, IpFilter, PF(Pocket Filter) -
by the way, a very good system, generally accepted in OpenBSD and ported to
FreeBSD.
Here we will focus on the ipfw firewall as the most simple and convenient,
easy to set up and reliable, stable and fast tool that
works at the kernel level and is the default firewall of the system for now
many years.
In order for ipfw to work, you must enable its support in the kernel.
You can go the easy way and dynamically load the required ipfw.ko module
using the kldload system utility:
To automate this process when the system is rebooted, you can
use the means of its loader,
namely, the configuration file /boot/loader.conf by writing there:
The second option is to rebuild the kernel with support for the above module. This is a more reliable and correct method in my opinion.
Before rebuilding the kernel, its configuration file should include the options
firewall support:  optionsIPFIREWALL Here, with faith in the future and awareness of the present - think - perhaps
you later want to set up address translation on the server (NAT -
Network Address Translation)? If so, then enable this support in advance:  options IPDIVERT There are many ways to rebuild the kernel. I use the simplest one:  cd /usr/src make kernel It is also recommended to edit the kernel config in another file, so as not to accidentally
mess up the default GENERIC config. To do this, copy the existing GENERIC into a separate file, let's call it
MYCONF and build it from it:
If it's scary to build and install the kernel in one line (the last one in
the above listing), - it can be divided into two:  make buildkernel KERNCONF=MYCONF make installkernel KERNCONF=MYCONF Can be done by handbook, via /usr/sbin/config MYCONF
But don't forget to define the MYCONF variable in /etc/make.conf :  cd /usr/src/sys/i386/conf /usr/sbin/config MYCONF cd ./compile/MYCONF (cd ././compile/MYKERNEL for FreeBSD versions prior to 5.0) make depend make make install  - but in my opinion all this is redundant work. Read more about building the kernel - not here. Read the handbook if interested.
After building the kernel (or during), or after raising the module if you still
decided to go this way, in the configuration file /etc/rc.conf is
define firewall loading with the following entry:
Here you can also define the type of firewall.
Several types are available, such as open, closed, and preset
through a file.
The open type (open) is when everything is allowed by default, in other words  allow all from any to any; This rule is placed at the end of all others, and it can be preceded by several
exceptions covering what is required.
The second type is the reverse of the first. The closed (close) type of firewall is more secure in
in terms of system security (but more dangerous in terms of illiteracy of its
settings, especially if the setting is remote) - the idea is to open
only what is required, and close everything else.
Here the last rule is the following: deny all from any to any;
Depends on kernel configuration, but profiled by default in freebsd
closed type.
Firewall type from file - This is when all the necessary rules are set
by the user from a file that is read when the system boots. It should be remembered that to all read rules after rereading the file,
one more will join - prohibiting everything, as in the closed type.
The firewall type is specified as follows in /etc/rc.conf:
Where the type open, close, or path to the file correspond to the types described above.
In the first two cases, you can write some kind of shell script that itself
will set the required rules, but we will go the other way. We will use a rules file in which we first write allow all
from any to any to satisfy any request first.
So, let's add a rule to the configuration file, let's call it /etc/firewall.conf :
Add a firewall type to /etc/rc.conf:
If we compiled the kernel, then we boot the system, if we loaded the module, then we try  CHAPTER 2. In this chapter, I propose to consider the configuration of the already configured by us
packet router between networks
as a gateway from one network to another, taking into account address translation.
This topic may be needed by those who seek to configure the gateway for
small network on the Internet, and wants to hide behind it the computers of his internal
networks.
We set the initial conditions: internal network: rl0: 10.10.10.1/24 external network: rl1: 192.168.0.1/16,
Task: Based on the initial conditions, configure the address translation system so that
so that the internal network can see and can access any address of the external network,
on behalf of (ip) the gateway we are configuring, and the external network, in turn, could not
determine from which internal network address the request comes from, and respond
back to the gateway, which would translate the addresses back.
Let's also assume that we have a routing system configured, an ipfw firewall configured,
the routed daemon is up.
There are many systems that allow you to translate ip addresses of various subnets from
your name.
The particular most popular cases are natd and ipnat.
natd is a very good system, but it has one major drawback. All connections opened in the system go through a separate natd daemon,
which can heavily load the system with large amounts of traffic.
ipnat does not suffer from this problem, as it is built into the system kernel, because
I suggest using it.
To configure ipnat, you need to create the appropriate configuration file with
settings - the rules by which this system will work. Let's call it: /etc/ipnat.rules
And add the following lines there:  map rl1 from 10.10.10.0/24 to 192.168.0.0/16 -> 192.168.0.1/32 proxy port ftp ftp/tcp map rl1 from 10.10.10.0/24 to 192.168.0.0/16 -> 192.168.0.1/32 Explanation of the first entry:
rename the outgoing address of the packet going through the external rl1 interface with
address belonging to the subnet 10.10.10.0/24 to the network 192.168.0.0/16 - to the address
"192.168.0.1" - the rule is valid for all ftp connections. The latter is a special assumption made within the framework of the use of ftp
protocol.
Decryption of the second entry:
rename the outgoing address of the packet going through the external rl1 interface with
addresses belonging to the subnet 10.10.10.0/24 into the network 192.168.0.0/16 - to the address "192.168.0.1" - the rule is valid for everyone compounds that do not fall under the previous rule.
After the action, you should load the ipl.ko module:
ipl - IP packet log device, after which the device will become available
/dev/ipnat needed for ipnat to work:`
Next, reread the ipnat-a config with the following command:  /sbin/ipnat -CF -f /etc/ipnat.rules   - o flag ownership see man ipnat for details; Let's check the rules that have come into circulation with the command:
The result of execution should be something like this:  List of active MAP/Redirect filters: map rl1 from 10.10.10.0/24 to 192.168.0.0/16 -> 192.168.0.1/32 proxy port ftp ftp/tcp map rl1 from 10.10.10.0/24 to 192.168.0.0/16 -> 192.168.0.1/32 List of active sessions: To enable ipnat support, the following lines can be added to /etc/rc.conf:  ipnat_enable="YES" ipnat_program="/sbin/ipnat -CF -f" ipnat_rules="/etc/ipnat.rules" ipnat_flags=""   FIREWALL In general, it is recommended to set up a firewall to secure the internal network and
restrictions on connections to it from an external network. How to do it - I can
I will write later, but at this stage you can do without it :)  CHAPTER 3. Task: Based on the installed system, configure access to the global network through gateway issued by the external network, for the internal network. IP address of the gateway dedicated in the external network: 192.168.10.10
This task is not easy, but very easy!
It is enough to define the default route to which all
packets addressed to subnets not related to ours (neither internal nor
to the outer one).
After that, you will need to configure ipnat to translate addresses also there, and
our task will be completed.
The first part is easy to make - you just need to add a route by
the default is "default" (0.0.0.0), and this can be done with the route program:  /sbin/route add default 192.168.10.10 Here we have indicated as the next point - issued to us by an external network
server 192.168.10.10.
If a packet arrives at our gateway whose destination address is not related to
to any of the networks defined on our interfaces ( rl0 rl1 ), then this
our gateway will send the packet to the "external gateway" - and he will figure it out himself
what to do with him. In theory, he will transfer it to a higher level, and so the package will be
be transmitted from gateway to gateway until it reaches the target.
To automate the process of setting the default router - you can
write an entry about it in the same notorious configuration file  /etc/rc.conf: defaultrouter="192.168.10.10" And then, when the system boots, the route will take effect. You can view it using the netstat utility by passing the "r" parameter to it, which
it would show the routing table in the system:
Now, let's add lines to /etc/ipnat.rules in order to teach our gateway
broadcast through itself packets passing to the global network. You can do this in the image and likeness of the previous entries:  map rl1 from 10.10.10.0/24 to 0.0.0.0/0 -> 192.168.0.1/32 proxy port ftp ftp/tcp map rl1 from 10.10.10.0/24 to 0.0.0.0/0 -> 192.168.0.1/32 or shorter:  map rl1 10.10.10.0/24 -> 192.168.0.1/32 proxy port ftp ftp/tcp map rl1 10.10.10.0/24 -> 192.168.0.1/32  - so like, even prettier :) Naturally, for this setting, it is also recommended to configure somehow
firewall to protect incoming connections.
regards, procool@ 
 

Automatic failover of the uplink

Once I no longer live on 3G:
Use link aggregation
to seamlessly failover from ethernet to 3G and back.

Complete and publishable configuration

I want to have all the configuration in ansible
(using my BSDops
) and thereby make it completely trivial to reproduce my setup. That is not quite the case yet.

Software

I chose to use FreeBSD and configure it as a router “by hand”. If you’d prefer to use a ready-made solution which can be configured using a web interface, but still has the full power of FreeBSD underneath, pfSense
is a great option.

6
Troubleshooting

Sometimes, there is a problem with routing propagation,
and some sites are unable to connect to you. Perhaps the
most useful command for trying to figure out where routing
is breaking down is the

command. It
is equally useful if you cannot seem to make a connection
to a remote machine (i.e.
fails).

The

command is
run with the name of the remote host you are trying to
connect to. It will show the gateway hosts along the path
of the attempt, eventually either reaching the target host,
or terminating because of a lack of connection.

3 Dual Homed
Hosts

There is one other type of configuration that we should
cover, and that is a host that sits on two different
networks. Technically, any machine functioning as a gateway
(in the example above, using a PPP connection) counts as a
dual-homed host. But the term is really only used to refer
to a machine that sits on two local-area networks.

In one case, the machine has two Ethernet cards, each
having an address on the separate subnets. Alternately, the
machine may only have one Ethernet card, and be using

aliasing. The
former is used if two physically separate Ethernet networks
are in use, the latter if there is one physical network
segment, but two logically separate subnets.

Either way, routing tables are set up so that each
subnet knows that this machine is the defined gateway
(inbound route) to the other subnet. This configuration,
with the machine acting as a router between the two
subnets, is often used when we need to implement packet
filtering or firewall security in either or both
directions.

If you want this machine to actually forward packets
between the two interfaces, you need to tell FreeBSD to
enable this ability.

IPv6

I need to get IPv6 connectivity (via an OpenVPN tunnel, as my provider doesn’t offer native IPv6) and then also enable IPv6 on my wifi.

 pkg wireguard
wireguard-go wg0# generate keys0777
wg genkey private
wg genkey < private public# send public to ungleich :-) (or whoever :D)# configure the interface 

2 Default
Routes

When the local system needs to make a connection to a
remote host, it checks the routing table to determine if a
known path exists. If the remote host falls into a subnet
that we know how to reach (Cloned routes), then the system
checks to see if it can connect along that interface.

If all known paths fail, the system has one last option:
the «default» route. This route is a special type of
gateway route (usually the only one present in the system),
and is always marked with a c
in
the flags field. For hosts on a local area network, this
gateway is set to whatever machine has a direct connection
to the outside world (whether via PPP link, DSL, cable
modem, T1, or another network interface).

If you are configuring the default route for a machine
which itself is functioning as the gateway to the outside
world, then the default route will be the gateway machine
at your Internet Service Provider’s (ISP) site.

Let us look at an example of default routes. This is a
common configuration:

The hosts Local1
and Local2
are at your site. Local1
is connected to an ISP via a dial up
PPP connection. This PPP server computer is connected
through a local area network to another gateway computer
through an external interface to the ISPs Internet
feed.

The default routes for each of your machines will
be:

A common question is «Why (or how) would we set the
T1-GW to be the default gateway for Local1, rather than the
ISP server it is connected to?».

Remember, since the PPP interface is using an address on
the ISP’s local network for your side of the connection,
routes for any other machines on the ISP’s local network
will be automatically generated. Hence, you will already
know how to reach the T1-GW machine, so there is no need
for the intermediate step of sending traffic to the ISP
server.

As a final note, it is common to use the address X. X. X.1
as the gateway address for your
local network. So (using the same example), if your local
class-C address space was 10.20.30

and your ISP was using 10.9.9
then
the default routes would be:

SCION!

Make SCION
runnable on FreeBSD and become one of the first households with native SCION connectivity.

Notes to self:

• add zfs-periodic
• backups via zfs-send
• run SCION with runit
• check that the SCION web UI is read-only and if yes, make it accessible over the network
• add runit and run things like my homemade thermostat

Hardware

I used a PCEngines APU3
, because PCEngines hardware is great, because it is passively cooled, because it has all the connectivity/expansion I want, and because the cases look awesome (see above).

I also got one of their wireless modules and a pair of antennas + pigtails, and the nice aluminium case. I added a 3rd party SSD and a 3G modem.

If you don’t need a large SSD, it is possible (and cheaper) to boot from an SD card.

You really shouldn’t bother with 3G unless you know you want to.

Because my wireless card is 11g only, I actually only need one antenna for WiFi. I decided to use the other antenna for 3G, because, conveniently, it is there. I will replace it with a proper 3G antenna (so, 2.1GHz instead of the WiFi’s 2.4) once I get one. In the meantime, this setup works surprisingly well.

• In case only one antenna is used for wireless, it should be connected to the first connector (so, 0 if they are labelled 0 and 1, or 1 if they are labelled 1 and 2).
• This 3G modem has 3 antenna connectors, and according to its datasheet these are ‘M’ for “main”, ‘G’ for GPS, and ‘A’ for “auxiliary” (¯\_(ツ)_/¯). The antenna should be connected to “main”.

Installation

Booting the installation image

I used a USB stick (FreeBSD-12.0-RELEASE-amd64-mini-memstick.img). Booting it over network also works.

1. The APU’s baud rate is 115200 ( PCEngines
   ).
2. One of the many options for opening a serial console: cu -l /dev/ttyUSB0 -s 115200
   .
3. At boot menu, press 3 to escape to loader prompt. Don’t mind the messed up screen, we’ll fix that now. Set up serial by typing:

    set comconsole_speed="115200"
   set console="comconsole" 

4. Avoid an annoying race condition by typing

    kern.cam.boot_delay="10000" 

5. Then type boot
   to boot.

Installation options

I got a 500GB mSATA SSD because it was kinda cheap and I want to do more than just routing. Therefore, I installed with root-on-ZFS because it shouldn’t eat that much RAM with just one disk and ZFS is awesome. After installation and with everything set up, I am using only about 400M of memory and a quick dd conv=sync
test shows write speed of 280MB/s, so it appears that the system is happy with ZFS.

I checked all security options besides the ones that would interfere with debugging (the reasoning being that I want to be able to debug any problems and otherwise I can afford to enable everything.)

Post-installation config

After the installation finished, I opened a shell to immediately configure a few things:

• /etc/sshd/sshd_config
  : set PermitRootLogin without-password
  so I can ssh in
• add my SSH key to the root account
• configure serial console, so that it’s there: in /boot/loader.conf
  :

   console="comconsole"
  comconsole_speed="115200" 

5 Routing
Propagation

We have already talked about how we define our routes to
the outside world, but not about how the outside world
finds us.

We already know that routing tables can be set up so
that all traffic for a particular address space (in our
examples, a class-C subnet) can be sent to a particular
host on that network, which will forward the packets
inbound.

When you get an address space assigned to your site,
your service provider will set up their routing tables so
that all traffic for your subnet will be sent down your PPP
link to your site. But how do sites across the country know
to send to your ISP?

There is a system (much like the distributed DNS
information) that keeps track of all assigned
address-spaces, and defines their point of connection to
the Internet Backbone. The «Backbone» are the main trunk
lines that carry Internet traffic across the country, and
around the world. Each backbone machine has a copy of a
master set of tables, which direct traffic for a particular
network to a specific backbone carrier, and from there down
the chain of service providers until it reaches your
network.

It is the task of your service provider to advertise to
the backbone sites that they are the point of connection
(and thus the path inward) for your site. This is known as
route propagation.

Things it can do + how

3G modem

This Just Works (TM) with the default configuration file.
(My SIM card has no PIN.)

(In case something needs to be changed, the settings live in /etc/ppp/ppp.conf
.)

To start ppp on boot, enable it in /etc/rc.conf
:

 ppp_enable="YES"
ppp_profile="u3g"
ppp_mode="ddial" # brings the link up if it is dropped 

Modems are evil and might not work after a reboot because they haven’t been sufficiently power-cycled. Mine does that. Workaround: Pull out the power cable for a few seconds instead of a soft reboot.

Idea (NOT working for me yet):

 # Power off the 3G modem before shutting down
usbconfig -d `usbconfig | grep -i huawei | cut -d: -f1` power_off 

Basic router setup (gateway + NAT for v4)

I used dhcpd
as my DHCP server ( pkg install dhcpd
).

Files that need editing:

• /etc/rc.conf
  :
  add:

   gateway_enable="YES"
  ipv6_gateway_enable="YES"
  pf_enable="YES"
  dhcpd_enable="YES" 

• /usr/local/etc/dhcpd.conf
  :

   option domain-name "home.kamila.is"
  option domain-name-servers 9.9.9.9 # or use local DNS, e.g. with unbound
  default-lease-time 86400;
  max-lease-time 604800;
  subnet 192.168.0.0 netmask 255.255.0.0 { range 192.168.0.100 192.168.0.200; option routers 192.168.0.1;
  } 

• /etc/pf.conf
  :
  Here’s a minimal and too permissive config:

   ##### Macros ################################################################
  int_net = "192.168.0.0/16"
  ext_if = "tun0"
  ##### Tables ################################################################
  ##### Options ###############################################################
  set skip on lo
  ##### Traffic normalization #################################################
  scrub in all
  ##### Queueing ##############################################################
  ##### Translation ###########################################################
  nat log on $ext_if inet from $int_net to any -> ($ext_if)
  ##### Packet filtering ######################################################
  block log all
  # this should probably block more
  pass in from $int_net
  pass out on $ext_if all
  pass inet proto icmp from $int_net # allow some ICMP for troubleshooting
  ##### Packet filtering overrides ###########################################
  pass quick inet proto icmp all icmp-type echoreq # always allow ping
  pass quick proto tcp from any to any port ssh # always allow ssh 

You probably also need to add ifconfig
lines for your wired interfaces, and probably bridge some things. I didn’t bother, as none of my usual devices have an Ethernet port, so if I end up using those wired NICs, I’ll configure them separately.

Wireless AP

• in /etc/rc.conf
  :

   wlans_ath0="wlan0"
  # replace CH with your country code to select
  # the right regulatory domain for wireless transmission
  create_args_wlan0="wlanmode hostap country CH"
  # use 11n if you have it; pick a reasonable channel;
  # experiment with txpower to find the lowest that works for you
  ifconfig_wlan0="inet 192.168.0.1/16 mode 11g channel 3 txpower 7"
  hostapd_enable="YES" 

• /etc/hostapd.conf
  :

   interface=wlan0
  debug=1
  ctrl_interface=/var/run/hostapd
  ctrl_interface_group=wheel
  ssid=<SSID>
  wpa=2
  wpa_passphrase=<PASSPHRASE>
  wpa_key_mgmt=WPA-PSK
  wpa_pairwise=CCMP 

1 An
Example

  %    netstat -r   Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 

The first two lines specify the default route (which we
will cover in the next section
) and the
localhost
route.

The interface ( Netif
column)
that this routing table specifies to use for localhost
is lo0
, also known as the loopback device.
This says to keep all traffic for this destination
internal, rather than sending it out over the LAN, since it
will only end up back where it started.

The next thing that stands out are the addresses
beginning with 0:e0:
. These are
Ethernet hardware addresses, which are also known as MAC
addresses. FreeBSD will automatically identify any hosts
( test0
in the example) on the local
Ethernet and add a route for that host, directly to it over
the Ethernet interface, ed0
.
There is also a timeout ( Expire

column) associated with this type of route, which is used
if we fail to hear from the host in a specific amount of
time. When this happens, the route to this host will be
automatically deleted. These hosts are identified using a
mechanism known as RIP (Routing Information Protocol),
which figures out routes to local hosts based upon a
shortest path determination.

FreeBSD will also add subnet routes for the local subnet
( 10.20.30.255
is the broadcast
address for the subnet 10.20.30
,
and example.com
is the domain name
associated with that subnet). The designation link#1
refers to the first Ethernet card in
the machine. You will notice no additional interface is
specified for those.

Both of these groups (local network hosts and local
subnets) have their routes automatically configured by a
daemon called routed
. If this is
not run, then only routes which are statically defined
(i.e. entered explicitly) will exist.

The host1
line refers to our
host, which it knows by Ethernet address. Since we are the
sending host, FreeBSD knows to use the loopback interface
( lo0
) rather than sending it
out over the Ethernet interface.

The two host2
lines are an
example of what happens when we use an

alias (see
the section on Ethernet for reasons why we would do this).
The =>
symbol after the lo0
interface says that not only
are we using the loopback (since this address also refers
to the local host), but specifically it is an alias. Such
routes only show up on the host that supports the alias;
all other hosts on the local network will simply have a link#1
line for such routes.

The final line (destination subnet 224
) deals with multicasting, which will be
covered in another section.

Finally, various attributes of each route can be seen in
the Flags
column. Below is a short
table of some of these flags and their meanings:

4
Building a Router

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

This option will set the

variable net.inet.ip.forwarding
to 1
. If you should need to stop routing
temporarily, you can reset this to 0
temporarily.

Even when FreeBSD is configured in this way, it does not
completely comply with the Internet standard requirements
for routers. It comes close enough for ordinary use,
however.

Up next

Things I haven’t done yet but want to in the future.