# PF.conf help?



## Vladimir Sanguinati (Nov 5, 2016)

This is what I have come up with so far.
It does work but I question how protected I am....

Should I be filtering the output also???

Is there a gui front end for PF?

Thanks!!



```
# Set some variables for use later
ext_if="fxp0"
int_if="xl0"
icmp_types="echoreq"

# Skip all loopback traffic
set skip on lo

# Scrub all traffic
scrub in

# Perform NAT on external interface
nat on $ext_if from $int_if:network -> ($ext_if:0)

# Define default behavior
block in log(all)
pass out keep state

# Allow inbound traffic on internal interface
pass quick on $int_if

# Protect against spoofing
antispoof quick for { lo $int_if }
```


----------



## aragats (Nov 6, 2016)

Vladimir Sanguinati said:


> Is there a gui front end for PF?


I'm not an expert in *pf*, but very happy with my router I've built with pfSense which has a nice web GUI.
So you can download it and take a look, it's de facto a customized FreeBSD.


----------



## kpa (Nov 6, 2016)

If you still decide to stick to FreeBSD I have couple of observations:

The nat rule is better this way:


```
nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if:0) port 1024:65535
```


This should be the first filter rule on your ruleset after the nat rule, also I would have ext_if there instead of int_if and drop the loopback as well. Any potential spoofing is more likely to be on the WAN side.


```
antispoof quick for $ext_if
```

The log(all) in your default deny rule will generate huge amounts of log entries over the time, consider using just:


```
block in log
```

Keep state is the default behaviour of PF if not specified. You can also short circuit rule evaluation for outgoing connections at this point with quick:


```
pass out quick
```


----------



## Vladimir Sanguinati (Nov 7, 2016)

Thanks for the feedback kpa!!
I have made the changes you suggested.  I know that logging file will become huge in time but at this early stage I guess I just want to be sure it is blocking everything.
I wish there was a way to get a web interface like PFSense has that shows you blocked connections easily.
For now I just run `tcpdump -e -tttt -q -i pflog0` to monitor it live.


----------



## mickey (Nov 8, 2016)

Vladimir Sanguinati said:


> I know that logging file will become huge in time but at this early stage I guess I just want to be sure it is blocking everything.
> I wish there was a way to get a web interface like PFSense has that shows you blocked connections easily.
> For now I just run `tcpdump -e -tttt -q -i pflog0` to monitor it live.



You could use net/wireshark to monitor blocked traffic if you prefer something more graphical.


----------



## Vladimir Sanguinati (Nov 8, 2016)

mickey said:


> You could use net/wireshark to monitor blocked traffic if you prefer something more graphical.




Does that require running some sort of KDE Gnome etc on the server box to see it?
or is it web based?


----------



## mickey (Nov 8, 2016)

Vladimir Sanguinati said:


> Does that require running some sort of KDE Gnome etc on the server box to see it?
> or is it web based?


AFAIK it's X11 based, so I guess a minimal install will require at least some X11 libraries to be present. As with all X11 based programs you could of course have it display on a remote computer running some form of X11 server.


----------



## SirDice (Nov 8, 2016)

You can use some tricks to pipe the output of a tcpdump(1) on one machine, over an SSH connection, to another machine running wireshark. It's a bit tricky to set up but works surprisingly well.


----------



## Vladimir Sanguinati (Nov 8, 2016)

SirDice said:


> You can use some tricks to pipe the output of a tcpdump(1) on one machine, over an SSH connection, to another machine running wireshark. It's a bit tricky to set up but works surprisingly well.


working on that now with tshark installing... Thanks for the idea


----------



## SirDice (Nov 8, 2016)

No need for tshark(1), it'll work with tcpdump(1) too.


----------



## Vladimir Sanguinati (Nov 9, 2016)

yup it sure did man!

here is what I came up with...maybe you can expound on it?


run on windows box: "c:/plink.exe" -ssh -pw xxxxxx xxxxxx@192.168.0.xxx "tcpdump -i pflog0 -s 0 -tttt -q -w - not port 22" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -

x's are to protect the innocent...

now to figure out the wireshark filtering system so I don't see things like 
25    250.946161    192.168.0.xxx    216.58.192.78    TLSv1.2    139    [block xl0/0] Encrypted Alert


----------



## Oko (Nov 9, 2016)

Vladimir Sanguinati said:


> This is what I have come up with so far.
> It does work but I question how protected I am....
> 
> Should I be filtering the output also???
> ...


Yes absolutely!!! You should filter both egress and ingress. There is no GUI for editing
pf.conf. File is trivial to edit and PF is extremely well documented with a caveat. FreeBSD uses obsolete version of PF with obsolete syntax. There are two turnkey appliances built around PF with nice GUI. Older non-free (Apache 2 license) pfSense and its for OPNsense. Both use FreeBSD as a starting point which means that they are based of obsolete version of PF.


----------

