# PF doesn't respond after some time.



## gnumonk (Apr 18, 2013)

Team,

I have a FBSD FreeBSD box (9.1-RELEASE) behind a corporate firewall. I wanted to use PF to restrict access tor my box.

I have the following rules in pf.conf:

`# cat pf.conf`

```
#Macros
my_int = "rl0"
tcp_services = "{ ssh, http, domain, ntp }"
udp_services = "{ domain, ntp}"

# Let's just trust localhost
set skip on lo

#Scrub
scrub in all 

# By default, we will block everyone and everything coming in
block in all
block return

# Keep state for oit 
pass out keep state

# accept ssh sessions
pass in on $my_int proto tcp from any to any port $tcp_services keep state
 
# Outgoing traffic is OK, here we keep state so returning packets
# are accepted too.
pass out on $my_int proto tcp to any port $tcp_services keep state 
pass out on $my_int proto udp to any port $udp_services keep state
```
and rc.conf:

```
#enable firewall
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(8)
pflog_logfile="/var/log/pflog"  # where pflogd should store the logfile
pflog_flags=""                  # additional flags for pflogd st
```

I would like to enable SSH from outside.

This ruleset works but after say seven or nine days I am not able to connect to the box. Once I disable the rules using `pfctl -d` or restart the box, everything works smoothly.

Any idea, or is there an issue in the ruleset?


----------



## kpa (Apr 18, 2013)

Few things:

Leave out pf_flags, pf_rules, pflog_logfile and pflog_flags from /etc/rc.conf, the defaults from /etc/default/rc.conf will be used if you don't specify those.

You default block rules could be just:


```
block return all
```

Keep state is the default so you can always leave it out.

Use the quick keyword to short circuit evalution for packets that do not need any more processing, for example:


```
pass in quick on $my_int proto tcp from any to $my_int port $tcp_services
```

You are already allowing all outgoing connections so why not just say:


```
pass out quick all
```


----------



## gnumonk (Apr 18, 2013)

Thanks, @kpa.

Let me apply those and let you know.


--
gnumonk


----------



## gnumonk (Apr 18, 2013)

Kpa, 

I have applied the rule. This is what [CMD=""]pfctl -s info[/CMD] says:

```
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 0 days 00:52:29           Debug: Urgent

State Table                          Total             Rate
  current entries                        0               
  searches                           27279            8.7/s
  inserts                                0            0.0/s
  removals                               0            0.0/s
Counters
  match                              27279            8.7/s
  bad-offset                             0            0.0/s
  fragment                               0            0.0/s
  short                                  0            0.0/s
  normalize                              0            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                              0            0.0/s
  proto-cksum                            0            0.0/s
  state-mismatch                         0            0.0/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s
```
but no log being captured using tcpdump.

[CMD=""]tcpdump -n -e -ttt -i pflog0 port 22[/CMD]

```
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
```
and [CMD=""]/sbin/ifconfig | grep pflog0[/CMD] says

```
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33200
```

Any idea?
--
gnumonk


----------



## kpa (Apr 18, 2013)

You need to use the log keyword in your rules to get anything in the log. For example:

```
pass in log quick on $my_int proto tcp from any to $my_int port $tcp_services
```


----------



## gnumonk (Apr 18, 2013)

Ah no this is not working, *t*ried with rebooting the system too. *N*o luck.
[CMD=""]tcpdump -vv -n -e -ttt -i pflog0[/CMD]

```
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
```


----------



## kpa (Apr 18, 2013)

Look at what is logged into the logfile itself.

`# /usr/sbin/tcpdump -n -tttt -e  -r /var/log/pflog`


----------



## gnumonk (Apr 18, 2013)

Ah, pf stuck again and I am at a remote location, need to go to my work location to reboot the server or disable the pf. 

It*'*s not ok. 


--
gnumonk


----------



## gnumonk (Apr 23, 2013)

Here is log says

```
2013-04-18 19:16:09.678164 rule 2..16777216/0(match): pass in on rl0: 192.168.1.7.57192 > 192.168.1.5.22: Flags [S], seq 2806091858, win 12800, options [mss 1280,sackOK,TS[|tcp]>
```


----------



## ronjns (May 25, 2013)

Hi @gnumonk,

I'm having exactly the same problem after upgrading from 9.0-RELEASE to 9.1-RELEASE. The box runs as a PF firewall/NAT and router for other machines and has three ethernet ports; one for PPPoE to my ISP and the other two each in different subnets.

Strangely, I can still `ssh` to some machines (i.e. the box is still routing packets) but if I ping the PF box it is reported as down/no route.

When it hangs, it won't let me hook up a keyboard to see what's going own although there's output to the screen. So I had to hard-reboot and there's nothing logged. Not in /var/log/messages and pflog shows that it still filtering packets up to the minute I reboot the box.

BTW, may I know your box specs?


----------



## gkontos (May 25, 2013)

I believe that those problems are related to the rl(4)() driver.


----------



## ronjns (May 25, 2013)

The box does have a Realtek chip for the onboard Gigabit port, default install picked re(4) driver.

Just captured this below, I wonder what keeps CPU 1 busy?


----------

