Some connections get blocked

T

thegolum35

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:
Code: 
#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:

Code: 
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
Code: 
block log all
rule that's wrong. And all the tables are empty.

Thank you, Gollum.
 
thegolum35 said:
Code: 
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
Click to expand...
I'm guessing there's more than one connection coming in from 91.121.80.162, max-src-conn is set to 1.
Code: 
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
Click to expand...
No idea what this is.

Code: 
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
Click to expand...
This looks like 192.168.1.36 is looking for UPnP/DLNA enabled devices.
 
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.
 
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.
 
They are harmless if everything appears to be otherwise working. Ignore them unless you can spot a real problem.
 
You must log in or register to reply here.
Back
Top