Custom kernel for NAT and PF ?

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives.Â Â Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

krad

2016-05-12 07:13:37 UTC

Agreed

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives. Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

Damien Fleuriot

2016-05-12 10:19:38 UTC

Post by krad
Agreed

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives. Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

While GENERIC works, one can definitely argue in favour of a custom kernel,
what does one even need audio for on a server anyways ;)

At the very least, you get shorter compilation times for your upgrade
sessions so, that's that...

Chris, if you can be bothered, do go for a custom, lightweight kernel.
Typical use scenarios have you remove support for audio, wifi, bluetooth,
usb printers, isa cards...

Find below the configuration file I use on our 10.x production firewalls.
I would not claim it is perfect, but it does the job for us.

Do pay attention to the enabled NICs and storage device controllers which
are tailored to our hardware !
Do also note we have commented some options, for example UFS_ACL since we
do not use the extended features.

== BEGIN ==

cpu HAMMER
ident DAM

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support

options SCHED_ULE # ULE scheduler
options PREEMPTION # Enable kernel thread preemption
options INET # InterNETworking
options INET6 # IPv6 communications protocols
options TCP_OFFLOAD # TCP offload
options SCTP # Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
#options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options UFS_GJOURNAL # Enable gjournal-based UFS journaling
options QUOTA # Enable disk quotas for UFS
options MD_ROOT # MD is a potential root device
options NFSCL # New Network Filesystem Client
options NFSD # New Network Filesystem Server
options NFSLOCKD # Network Lock Manager
#options NFS_ROOT # NFS usable as /, requires NFSCL
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS # Pseudo-filesystem framework
options GEOM_PART_GPT # GUID Partition Tables.
options GEOM_RAID # Soft RAID functionality.
options GEOM_LABEL # Provides labelization
options COMPAT_FREEBSD32 # Compatible with i386 binaries
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options STACK # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed.
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4)
options AUDIT # Security event auditing
options CAPABILITY_MODE # Capsicum capability mode
options CAPABILITIES # Capsicum capabilities
options PROCDESC # Support for process descriptors
options MAC # TrustedBSD MAC Framework
options KDTRACE_FRAME # Ensure frames are compiled in
options KDTRACE_HOOKS # Kernel DTrace hooks
options DDB_CTF # Kernel ELF linker loads CTF data
options INCLUDE_CONFIG_FILE # Include this file in kernel
options RACCT # Resource accounting framework
options RACCT_DEFAULT_TO_DISABLED # Set kern.racct.enable=0 by default
options RCTL # Resource limits

# Debugging support. Always need this:
options KDB # Enable kernel debugger support.
options KDB_TRACE # Print a stack trace for a panic.

# Make an SMP-capable kernel by default
options SMP # Symmetric MultiProcessor Kernel

# CPU frequency control
device cpufreq

# Bus support.
device acpi
options ACPI_DMAR
device pci

# ATA controllers
device ahci # AHCI-compatible SATA controllers
device ata # Legacy ATA/SATA controllers
options ATA_STATIC_ID # Static device numbering

# SCSI Controllers
device mpt # LSI-Logic MPT-Fusion
device mps # LSI-Logic MPT-Fusion 2
device mpr # LSI-Logic MPT-Fusion 3

# ATA/SCSI peripherals
device scbus # SCSI bus (required for ATA/SCSI)
device da # Direct Access (disks)
device pass # Passthrough device (direct ATA/SCSI access)

# RAID controllers
device mfi # LSI MegaRAID SAS

# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller
device atkbd # AT keyboard
device kbdmux # keyboard multiplexer

device vga # VGA video card driver

device splash # Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device sc
options SC_PIXEL_MODE # add support for the raster text mode

# vt is the new video console driver
device vt
device vt_vga
device vt_efifb

device agp # support several AGP chipsets

# Serial (COM) ports
device uart # Generic UART driver

# PCI Ethernet NICs.
device em # Intel PRO/1000 Gigabit Ethernet Family
device igb # Intel PRO/1000 PCIE Server Gigabit Family
device ix # Intel PRO/10GbE PCIE PF Ethernet
device ixv # Intel PRO/10GbE PCIE VF Ethernet

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device miibus # MII bus support
device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet
device bfe # Broadcom BCM440x 10/100 Ethernet
device bge # Broadcom BCM570xx Gigabit Ethernet
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139

# Pseudo devices.
device loop # Network loopback
device random # Entropy device
device padlock_rng # VIA Padlock RNG
device rdrand_rng # Intel Bull Mountain RNG
device ether # Ethernet support
device vlan # 802.1Q VLAN support
device tun # Packet tunnel.
device md # Memory "disks"
device gif # IPv6 and IPv4 tunneling
device faith # IPv6-to-IPv4 relaying (translation)
device firmware # firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device bpf # Berkeley packet filter

# USB support
options USB_DEBUG # enable debug msgs
device uhci # UHCI PCI->USB interface
device ohci # OHCI PCI->USB interface
device ehci # EHCI PCI->USB interface (USB 2.0)
device xhci # XHCI PCI->USB interface (USB 3.0)
device usb # USB Bus (required)
device ukbd # Keyboard

# VirtIO support
device virtio # Generic VirtIO bus (required)
device virtio_pci # VirtIO PCI device
device vtnet # VirtIO Ethernet device
device virtio_blk # VirtIO Block device
device virtio_scsi # VirtIO SCSI device
device virtio_balloon # VirtIO Memory Balloon device

# Custom options from hi-media
device carp # Common Address Redundancy Protocol /
virtual IPs
device lagg # Link Aggregation / 802.3ad
device vlan # VLAN tagging / 802.1Q
device pf # Packet Filter
device pflog # PF logging
device pfsync # PF state sync

# QoS / queueing / shapping options
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_PRIQ
options ALTQ_NOPCC

# ISCSI initiator
device iscsi_initiator
#options ISCSI_INITIATOR_DEBUG=9

options DEVICE_POLLING

== END ==

Shane Ambler

2016-05-13 04:34:55 UTC

Post by krad
Agreed

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives. Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

Well 15 years ago that was pretty normal, if you only had 8MB RAM then
you trimmed your kernel as much as you could to save some RAM.

These days using the generic kernel isn't an issue. We have enough RAM
that a few MB saved in the kernel is not noticed.

Now you only need to compile a custom kernel if you want to use newer
features. dtrace was an option previously but now is available in
generic, ipsec is a current feature you need a custom kernel for, which
is planned to be available in generic for 11.0

If you have a look through a recent /boot/kernel you will find that the
kernels nowadays are only about 20MB with another ~450MB in loadable
modules that don't do anything unless they are loaded for the hardware
or features you want.

Don't want sound? - don't add snd_hda_load="YES" to your loader.conf.

You may argue that disabling things can speed up the kernel, I don't
believe a non-loaded module adds any execution time. And how often are
your cpu's at 100% capacity that the small saving you can get in the
kernel makes a noticeable difference to performance?

So yes you can save some compile time and a few MB of disk space. Your
saving what, maybe 10-20 mins? Not like you just sit there doing nothing
until the compile finishes.

--
FreeBSD - the place to B...Software Developing

Shane Ambler

Damien Fleuriot

2016-05-13 08:17:41 UTC

Post by Shane Ambler

Post by krad
Agreed

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives. Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

Well 15 years ago that was pretty normal, if you only had 8MB RAM then
you trimmed your kernel as much as you could to save some RAM.
These days using the generic kernel isn't an issue. We have enough RAM
that a few MB saved in the kernel is not noticed.
Now you only need to compile a custom kernel if you want to use newer
features. dtrace was an option previously but now is available in
generic, ipsec is a current feature you need a custom kernel for, which
is planned to be available in generic for 11.0
If you have a look through a recent /boot/kernel you will find that the
kernels nowadays are only about 20MB with another ~450MB in loadable
modules that don't do anything unless they are loaded for the hardware
or features you want.
Don't want sound? - don't add snd_hda_load="YES" to your loader.conf.
You may argue that disabling things can speed up the kernel, I don't
believe a non-loaded module adds any execution time. And how often are
your cpu's at 100% capacity that the small saving you can get in the
kernel makes a noticeable difference to performance?
So yes you can save some compile time and a few MB of disk space. Your
saving what, maybe 10-20 mins? Not like you just sit there doing nothing
until the compile finishes.

You make cogent arguments Shane, however I am of a different mind.

See, trimming your kernel has many advantages, small ones certainly but
they do add up :
- smaller compile times
- smaller memory footprint
- less chance of being affected by bugs
- reduced attack surface

In the context of a firewall, I'd rather go for the (much) reduced attack
surface.

Less drivers and options built-in means less attack venues for remote
threats.

Polytropon

2016-05-13 12:53:35 UTC

Post by Shane Ambler

Post by krad
Agreed

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives. Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

Well 15 years ago that was pretty normal, if you only had 8MB RAM then
you trimmed your kernel as much as you could to save some RAM.
These days using the generic kernel isn't an issue. We have enough RAM
that a few MB saved in the kernel is not noticed.
Now you only need to compile a custom kernel if you want to use newer
features. dtrace was an option previously but now is available in
generic, ipsec is a current feature you need a custom kernel for, which
is planned to be available in generic for 11.0
If you have a look through a recent /boot/kernel you will find that the
kernels nowadays are only about 20MB with another ~450MB in loadable
modules that don't do anything unless they are loaded for the hardware
or features you want.
Don't want sound? - don't add snd_hda_load="YES" to your loader.conf.
You may argue that disabling things can speed up the kernel, I don't
believe a non-loaded module adds any execution time. And how often are
your cpu's at 100% capacity that the small saving you can get in the
kernel makes a noticeable difference to performance?
So yes you can save some compile time and a few MB of disk space. Your
saving what, maybe 10-20 mins? Not like you just sit there doing nothing
until the compile finishes.

You make cogent arguments Shane, however I am of a different mind.
See, trimming your kernel has many advantages, small ones certainly but
- smaller compile times
- smaller memory footprint
- less chance of being affected by bugs
- reduced attack surface
In the context of a firewall, I'd rather go for the (much) reduced attack
surface.
Less drivers and options built-in means less attack venues for remote
threats.

That is a very valid point of view. While it doesn't matter to the
usual desktop PC, a "small footprint appliance" does definitely benefit
from this approach. For example, on a security-related installation
where you build from source anyway (because security updates are in
SVN earlier than they appear as binary upgrades), you often have a
custom kernel and a restrictive src.conf, just to make sure you can
exactly define that "footprint" (in terms of what the system consists
of) as close as possible. You don't include what you don't need, so
there are less "moving parts" in case something would break.

Hardware limitations aren't the only reason for the "small footprint"
concept. :-)

--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

krad

2016-05-13 14:31:09 UTC

Strictly speaking you are not correct in the compile times as simply
altering the kernel options doesnt stop the the relevant code being
compiled, it just stops it being linked. The various modules are still
built when you do a buildkernel. Playing with the src.conf could get you
faster compile times though. However this is all off topic of the OP 8)

Post by Shane Ambler

Post by krad
Agreed

Post by Chris Hale
I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
some
NAT directives. Would I need a custom kernel for NAT if I took out
all of
the ALTQ references?

The generic kernel is all you need for NAT with pf.

Well 15 years ago that was pretty normal, if you only had 8MB RAM then
you trimmed your kernel as much as you could to save some RAM.
These days using the generic kernel isn't an issue. We have enough RAM
that a few MB saved in the kernel is not noticed.
Now you only need to compile a custom kernel if you want to use newer
features. dtrace was an option previously but now is available in
generic, ipsec is a current feature you need a custom kernel for, which
is planned to be available in generic for 11.0
If you have a look through a recent /boot/kernel you will find that the
kernels nowadays are only about 20MB with another ~450MB in loadable
modules that don't do anything unless they are loaded for the hardware
or features you want.
Don't want sound? - don't add snd_hda_load="YES" to your loader.conf.
You may argue that disabling things can speed up the kernel, I don't
believe a non-loaded module adds any execution time. And how often are
your cpu's at 100% capacity that the small saving you can get in the
kernel makes a noticeable difference to performance?
So yes you can save some compile time and a few MB of disk space. Your
saving what, maybe 10-20 mins? Not like you just sit there doing nothing
until the compile finishes.

Doug McIntyre

2016-05-13 19:10:39 UTC

Post by Shane Ambler
Now you only need to compile a custom kernel if you want to use newer

features.

...

Unfortunately, I have two situations where that isn't true.

For the first, I wish that just loading the PPS drivers enabled the
PPS_SYNC option in the kernel, but it doesn't seem to. (if there is
a way to enable 'option PPS_SYNC' with a generic kernel I'd like to know,
but my experients didn't lead me that working. I still have to compile
the kernel for my GPS connected NTP servers. Which makes me wonder why
the PPS drivers are a kernel loadable object.

The second is that the username handling is still limited to 32-bytes,
which really cramps my logins for '***@somesillydomainname.com'
so I have to build a custom kernel with longer usernames patched for
the systems that need to deal with system logins like that.

Shane Ambler

2016-05-14 04:28:56 UTC

Post by Doug McIntyre