# Some connections get blocked



## thegolum35 (May 14, 2013)

Hi,

I have some issues with pf on FreeBSD 9.1-STABLE. Some incoming and outgoing connections are blocked, while they weren't before. 

Here is pf.conf:

```
#Macro

ext_if = "fxp0"
int_if = "lo1"

# Tables

table <flood> persist
table <b> persist
table <tor> persist

# Rules

scrub in all

nat on $ext_if from lo1:network to any -> ($ext_if)

rdr on $ext_if proto tcp from !$ext_if:network to 192.168.1.40 port 22 -> 192.168.50.1 port 22
rdr on $ext_if proto tcp from !$ext_if:network to 192.168.1.40 port 9001 -> 192.168.50.1 port 9001
rdr on $ext_if proto tcp from any to 192.168.1.40 port 445 -> 192.168.50.2 port 445
rdr on $ext_if proto tcp from any to 192.168.1.40 port 139 -> 192.168.50.2 port 139
rdr on $ext_if proto udp from any to 192.168.1.40 port 137 -> 192.168.50.2 port 137
rdr on $ext_if proto udp from any to 192.168.1.40 port 138 -> 192.168.50.2 port 138
rdr on $ext_if proto tcp from $ext_if:network to 192.168.1.40 port 9050 -> 192.168.50.1 port 9050
rdr on $ext_if proto tcp from $ext_if:network to 192.168.1.40 port 3128 -> 192.168.50.4 port 3128

set skip on {lo0 lo1}
block log all # Drop all

block quick on $ext_if from <flood>
block quick on $ext_if to <flood>
block quick on $ext_if from <b>
block quick on $ext_if to <b>

pass quick on $ext_if proto icmp # Allow ping

pass in quick on $ext_if proto tcp from $ext_if:network to 192.168.50.1 port 9050
pass in quick on $ext_if proto tcp from 192.168.1.29 to 192.168.1.40 port ssh
pass in log on $ext_if proto tcp from any to 192.168.50.1 port 22 flags S/SA keep state (max-src-conn 3, max-src-conn-rate 5/60, overload <flood> flush global)

pass in on $ext_if proto tcp from any to 192.168.50.1 port 9001 flags S/SA keep state (max-src-conn 1, overload <tor> ) 

#Samba

pass in on $ext_if proto tcp from any to 192.168.50.2 port {445, 139}
pass in on $ext_if proto udp from any to 192.168.50.2 port {137, 138}

pass out all
```

And here is tcpdump output:


```
19:05:01.082278 rule 0..16777216/0(match): block in on fxp0: 91.121.80.162.36244 > 192.168.50.1.9001: Flags [P.], seq 3893976985:3893977213, ack 1559427037, win 29, options [nop,nop,TS val 917502036 ecr 792671839], length 228
19:05:01.271488 rule 0..16777216/0(match): block out on fxp0: 192.168.1.40.56600 > 91.121.80.162.36244: Flags [S.], seq 1559427036, ack 3893976985, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 792671839 ecr 917499833], length 0
19:05:01.917912 rule 0..16777216/0(match): block in on fxp0: 192.168.1.36.35233 > 239.255.255.250.1900: UDP, length 284
19:05:01.928415 rule 0..16777216/0(match): block in on fxp0: 192.168.1.36.35233 > 239.255.255.250.1900: UDP, length 284
```

Where the network 192.168.50.1/24 is on lo1. It seems to be that this is the 
	
	



```
block log all
```
 rule that's wrong.  And all the tables are empty.

Thank you, Gollum.


----------



## SirDice (May 14, 2013)

thegolum35 said:
			
		

> ```
> 19:05:01.082278 rule 0..16777216/0(match): block in on fxp0: 91.121.80.162.36244 > 192.168.50.1.9001: Flags [P.], seq 3893976985:3893977213, ack 1559427037, win 29, options [nop,nop,TS val 917502036 ecr 792671839], length 228
> ```


I'm guessing there's more than one connection coming in from 91.121.80.162, max-src-conn is set to 1.


> ```
> 19:05:01.271488 rule 0..16777216/0(match): block out on fxp0: 192.168.1.40.56600 > 91.121.80.162.36244: Flags [S.], seq 1559427036, ack 3893976985, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 792671839 ecr 917499833], length 0
> ```


No idea what this is.



> ```
> 19:05:01.917912 rule 0..16777216/0(match): block in on fxp0: 192.168.1.36.35233 > 239.255.255.250.1900: UDP, length 284
> 19:05:01.928415 rule 0..16777216/0(match): block in on fxp0: 192.168.1.36.35233 > 239.255.255.250.1900: UDP, length 284
> ```


This looks like 192.168.1.36 is looking for UPnP/DLNA enabled devices.


----------



## thegolum35 (May 14, 2013)

Thanks for having answered. My server is running a tor relay so max-src-conn is just for having a list of the tor nodes I'm connected to, none rule uses it. Then, the second line you gave is probably a connection to one of these tor nodes.


----------



## kpa (May 14, 2013)

Some of those are very likely just "out of state" traffic. It's the nature of networking that causes some of the packets to be lost and resent and if the state gets torn down before the resent packet arrives it will blocked by the default deny rule.


----------



## thegolum35 (May 14, 2013)

So, is there anything I can do? And does what you said explain the outgoing connection getting blocked too?


----------



## kpa (May 14, 2013)

They are harmless if everything appears to be otherwise working. Ignore them unless you can spot a real problem.


----------

