Consider the simplest cases of Internet distribution within the office network.

Foreword
In the course of work, sometimes you have to connect clients either with the machines present on FreeBSD (a common option is to keep working files on sambas there) or to give them such a solution on request, for the most convenient solution of the client’s pressing problems. The article is intended for a reader extremely weakly acquainted with FreeBSD. I think that people who understand this article will be extremely disgusting - I recommend not to read further and not to injure yourself.




The required set of knowledge is a general familiarity with * nix-like operating systems (any Linux, perhaps a makos), a cold-blooded attitude to the console, and basic ideas about network operation.
The article was glued from the cheat sheet written for our staff and intended for elementary education. Man 5, at least in this writing, at one time learned something, we believe that it has the right to exist.
')
The installation of FreeBSD is already very detailed and even in beautiful pictures is described very well and accessible from other people and we will modestly keep silent about it. In addition, installing FreeBSD for a person who previously installed, say, Debian or FreeBSD (here, smiley) should not be a problem.

After-foreword and answers to your first thoughts
- yes, I know about the existence of pfnat, ipnat, ng_nat - if you also know such words, please do not read further (see above again)
- yes, I know that pf is faster but I do not consider it appropriate to use it with streams of less than 50-60 Mbit
- no, we will not proceed from the tasks set in the heading to build a full balancing on a round robin
- No, not Linux - because the article is not about him.
- and not makos - although yes, you can ... probably.
- once again - about pf but on faster things we'll talk next time
- yes, based on the experience of nuclear ipfw nat faster by 20 percent, it is very easy to switch to using it after the notion of working with natd
- No, and we will keep silent about 2850
- yes, I really think ipfw is quite flexible. Seriously.
- no, I don't like squid, polipo, privoxy - then I will explain why

So, we begin to deal directly with the solution of the tasks posed, and consider a spherical network of spontaneous layouts in a vacuum.



What we want to do:
• Trivial and practical minimum - the circulation of our network on the Internet
• We will assume that the Internet is looking at the network card rl0 with the address 10.10.10.1 and into our internal network of the network card fxp0 with the address 192.168.0.1 and one more not plugged network card xl0 (hereinafter we may know why we can use it)

We will need:
1. Machine with FreeBSD installed
2. a little time
3. 2 cups of coffee

To begin with, we assemble and install the kernel, because IPFIREWALL and IPDIVERT are not included in the GENERIC box that comes out of the box, which we need right now, but it doesn’t include many things. In principle, the process of building the kernel has already been described many times and there is no point in repeating it, but I feel that this step-by-step and accessible manual is written requires this routine.

So the kernel build:

#cd / usr / src / sys / i386 / conf
# cp GENERIC MYROUTER
#vim MYROUTER

We rule the kernel configuration for our minimum well or optional minimum needs (read separately):

MYROUTER ident
options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_FORWARD
options DUMMYNET
options IPDIVERT
options HZ = 1000
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT = 100

and collect:
#config MYROUTER
#cd ../compile/MYROUTER
#make depend
#make

Backing up the old kernel if something scary happens:

#cp –R / boot / kernel / boot / good

and install the new kernel

#make install

Note - if we are going to natit on an external piece of iron or another host, and then only control the utilization of the channel, then IPDIVERT is completely unnecessary, you can freely dispense with the ipfw module loading and do without reassembling the kernel.

We start playing with NAT, for the sake of which all this was started:

we put in /etc/rc.conf

defaultrouter = "10.10.10.2" # default gateway
ifconfig_rl0 = "inet 10.10.10.1 netmask 255.255.255.0"
ifconfig_fxp0 = "inet 192.168.0.1 netmask 255.255.255.0"
gateway_enable = "YES" # yes, we will
firewall_enable = "YES" # cut in ipfw
firewall_script = "/ etc / firewall.conf" # from here our ipfw should take the rules
natd_enable = "YES" # cut in natd
natd_interface = "rl0" # and tell him where we will natit (network card looking to the Internet)

Here it is recommended everywhere. Personally, I am accustomed to letting natd not on the interface but on a specific ipishka with a specific port for a diverta. You can do this for example from the same /etc/firewall.conf in the form / sbin / natd -u -p 8671 -a 10.10.10.1 (Why it's so convenient to do this, too, consider in the case of PBR)

Next, create the above /etc/firewall.conf

In many manuals that I came across, it is offered in the simplest form like this:

#! / bin / sh
FwCMD = "/ sbin / ipfw -q"
$ {FwCMD} -f flush
$ {FwCMD} add divert natd from rl0
$ {FwCMD} add 65535 allow

divert from any to any via in general an ugly option, we go further, if we do something, we will do it more beautifully:

#! / bin / sh
/ sbin / natd -u -p 8671 -a 10.10.10.1
FwCMD = "/ sbin / ipfw -q"
$ {FwCMD} -f flush

# Networks define
$ {FwCMD} table 2 add 192.168.0.0/24
$ {FwCMD} table 9 add 10.10.10.8/32
#internet natting and preserving
$ {FwCMD} add 1799 divert 8671 ip from table \ (2 \) to not table \ (9 \) out via rl0
$ {FwCMD} add 2099 divert 8671 ip from any to 10.10.10.1 in via rl0

For the future, we remember that in table (2) we have networks or hosts that we will natit, and in table (9) those hosts that we don’t want to NAT to. As an example, we mentioned a host on 10.10.10.8 there that is on the 10.10.10 / 24 network and let's say it performs the functions of our office% service_name%. Accordingly, in order for us to reach him from the 192.168 / 24 network, you need to drive a static routing call to 10.10.10.1

So back to the task and set the execution rights.

#chmod a + x /etc/firewall.conf

Then you can look at the sky, cross and reboot.
#reboot

After downloading, there is a chance that we will see a working NAT and our users will be able to see the suffering Internet, registering ipishki from 192.168.0.0/24 range and specifying the default gateway 192.168.0.1 plus Provider DNS (we have not yet raised our own).

Checking the operation of the nat method
#ipfw show

As a result, we should see something like

1265581 168080800 divert 8671 ip from table (2) to not table (9) out via rl0
769868437 668041277852 divert 8671 ip from any to 10.10.10.1 in via rl0

It is clear that we missed a lot, for example, throwing away trash from GENERIC, tuning kernel options to ensure human performance during sessions and a huge stream, cutting any garbage on the interfaces, but more on that next time if you want.

Let's go further in the real tasks that can suddenly stand in front of us.

Quite often there is the task of providing different bandwidth to different hosts.
For example, Svetlana Denisovna doesn’t need a very fast Internet connection during her work, and her bosses want her channel to look like a symmetrical 256 Kbps. OK no problem:

ipfw pipe 10256 config bw 256Kbit / s queue 32Kbytes
ipfw pipe 20256 config bw 256Kbit / s queue 32Kbytes
ipfw add 10000 pipe 10256 ip from 192.168.0.6 to not table \ (9 \) via fxp0 in
ipfw add 10000 pipe 10256 ip from not table \ (9 \) to 192.168.0.6 via fxp0 out

After verifying that it’s working, you can duplicate all this in /etc/firewall.conf. Having never tested another rule, even the most obvious, do not add it to the config - you will always have a way to access without unnecessary nerves.
If the speed needs to be cut on the entire network, or else somehow on the mask, it would be more logical to do, let's say, like this:

$ {FwCMD} pipe 9999 config bw 512Kbit / s queue 64Kbytes mask dst-ip 0xffffffff
$ {FwCMD} pipe 9998 config bw 512Kbit / s queue 64Kbytes mask dst-ip 0xffffffff
$ {FwCMD} add 5000 pipe 9999 ip from table \ (2 \) to not table \ (9 \) via fxp0 in
$ {FwCMD} add 5000 pipe 9998 ip from not table \ (9 \) to table \ (2 \) via fxp0 out

Turning the mask in the pipe we can do either “this is the speed at all” or “this is the speed for everyone” as indicated in the example.

What else would I like to do after that? Very much to be honest.

1. Configure DHCP
2. Raise your DNS
3. I would like to shoot realistic statistics of traffic walking on interfaces using snmp and draw beautiful graphics using cacti
4. Have the ability to limit the traffic on users within the network
5. Have detailed statistics on who and what traffic is spent on.
6. Set up backup channels if there is another provider (and forgot about xl0)
7. Learn how to arrange traffic between multiple channels using ipfw

How do you want everything to look in the final?
At least like this:


These 7 points in conjunction with the accelerated installation of billing (picture above) I would like to consider in the next article if someone will be interested and karma after today's pressing the “publish” button will allow;)

PS and yes - my Russian has not improved since the previous post was published. I sincerely apologize.