FreeBSD Firewalls

Frank Shute frank at
Sat Dec 10 02:24:32 UTC 2016

On Thu, Dec 08, 2016 at 04:44:43PM -0500, James B. Byrne via freebsd-questions wrote:
> With these rules in effect when I run gvim from the sh -X session on
> the FreeBSD host I get this error:
> gvim /etc/pf.conf
>   backupdir=~/.vim/tmp
> E233: cannot open display
> Press ENTER or type command to continue
> If the firewall is not enabled then the gvim X-window opens on my
> remote desktop (gnome2) without error.
> What ports, besides 22, is gvim trying to open?  Why is this traffic
> not passed (tunnelled) along the established ssh connection?
> Thanks,

My advice: don't use gvim as root and over ssh, use vim instead. With the
latter not using X, you avoid a pile of permission problems and it will be
a lot quicker whether you're on a crappy link or not.

With regards pf, there are a few resources I've found useful. The OpenSBD
FAQ for a start:

One thing to note, is that some features of pf are not built into the GENERIC
kernel. For example, to enable tables, you need to stick some lines in your
kernconf to build altq(4). So in my kernconfig, I've got these lines:

options ALTQ

options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ

There's some options above that I don't and possibly will never use but
for the minimal performance hit they may cause, it saves me possibly doing
a buidkernel/world cycle in the mysterious future.

Of course, by building your own kernel it means you can no longer use
freebsd-update(8) and have to use: make buildworld/installworld procedure
as documented in the Handbook and /usr/src/UPDATING

When expressing blocks of addresses, pf uses CIDR format:

Something that I was completely ignorant about; it was all class a/b/c
with netmasks 32/24/16/8 when I was a lad....

One of the first things you will want to do is write a rule for all the
muppets who try to persistently log on to 22 without a key and hence fill
up your logs:

When creating your rules use "log" liberally. When a rule is behaving
itself, then you can remove the "log" keyword from the rule.

You can see what's going on with tcpdump(1) and a useful utility in ports:
sysutils/pftop, which I tend to keep running 24/7 in an xterm so I can
keep an eye on any possible irregularities and addresses I need to add to
my <scum> table/file.




More information about the freebsd-questions mailing list