Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Apr 2007 16:08:54 -0700
From:      Drew Tomlinson <drew@mykitchentable.net>
To:        Max Laier <max@love2party.net>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: Bacula and pf
Message-ID:  <4612DE86.2000706@mykitchentable.net>
In-Reply-To: <200704031812.00089.max@love2party.net>
References:  <46117263.3060203@mykitchentable.net> <200704031812.00089.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4/3/2007 9:11 AM Max Laier wrote:
> On Monday 02 April 2007 23:15, Drew Tomlinson wrote:
>   
>> I run Bacula v1.38 on my home network.  Ever since I moved from ipfw2
>> to pf, backups fail intermittently on my router due to "broken network
>> pipes" usually after somewhere around 10 MB - 12 MB has been
>> transfered.  Thus small incremental backups are successful but larger
>> full backups are not.  I do not have this problem when I disable pf on
>> the router, nor do I have problems when completing backups with other
>> machines on my internal network.  My setup looks like this:
>>
>> bacula director --------- router (client)
>> 192.168.1.4 (fxp0)        192.168.1.2 (dc0)
>>
>> Communication takes place on ports 9102 and 9103.  I captured this
>> output from pflog0 after starting a backup:
>>
>> blacksheep# tcpdump -netttti pflog0 "( host blacksheep or blacklamb )
>> and ( port 9102 or port 9103 )"
>> 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 96 bytes
>> 2007-04-02 13:57:21.021122 rule 7/0(match): pass in on dc0:
>> 192.168.1.4.52295 > 192.168.1.2.9102: S 2822997678:2822997678(0) win
>> 65535 <mss 1460,nop,wscale 1,[|tcp]>
>> 2007-04-02 13:57:23.532037 rule 13/0(match): pass out on dc0:
>> 192.168.1.2.64955 > 192.168.1.4.9103: S 2265048451:2265048451(0) win
>> 65535 <mss 1460,nop,wscale 1,[|tcp]>
>> 2007-04-02 13:57:23.532323 rule 7/0(match): pass in on dc0:
>> 192.168.1.4.9103 > 192.168.1.2.64955: S 3452777266:3452777266(0) ack
>> 2265048452 win 65535 <mss 1460,nop,wscale 1,[|tcp]>
>>
>> And the rules are:
>>
>> @7 pass in log on dc0 inet proto tcp from 192.168.1.0/24 to any
>> modulate state queue(std_out, ack_out)
>>     
>
> This rule should have "flags S/SA" on it.
>   

In my attempts to get ALTQ queuing working, I have found that adding 
flags here breaks it.  However I am sure I am not approaching queuing 
correctly.  I posted a bit about the problem here:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=4242+9504+/usr/local/www/db/text/2007/freebsd-pf/20070225.freebsd-pf

After getting no response (which made me think my approach was way off), 
I attempted to redo my rule set and asked for help here:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=87780+93096+/usr/local/www/db/text/2007/freebsd-pf/20070401.freebsd-pf

This post received one response regarding "keep state" and flags as 
well.  I think I understand the concept about stateful inspections but I 
do not understand how to get queuing to work only on packets sent from 
my router to machines over the Internet.  Seems that when I make "keep 
state" rules on inbound connections, the return traffic matches the 
state rules and thus never gets queued.  I would LOVE to understand this 
better and would really appreciate any links to suggested reading.

>> @13 pass out log on dc0 inet all
>>
>> Any ideas why Bacula would have such a problem?  Other things to check?
>>     
>
> Can you turn on pf debugging via "pfctl -xm" and watch the console while 
> doing the backup?  Also monitor "pfctl -si" for increasing counters - 
> esp. state-mismatch.
>   
OK, I tried this and it's obvious to me that my pf configuration is not 
correct.  I see tons of messages such as these:

Apr  3 15:49:42 blacksheep kernel: pf_map_addr: selected address 
66.205.146.210
Apr  3 15:49:46 blacksheep kernel: pf: BAD state: TCP 
140.105.134.102:54934 140.105.134.102:54934 192.168.1.4:25 [lo=836336158 
high=836336204 win=33304 modulator=0] [lo=1850627322 high=1850660626 
win=46 modulator=0] 4:4 PA seq=836336158 ack=1850627322 len=185 
ackskew=0 pkts=4:5 dir=in,fwd
Apr  3 15:49:46 blacksheep kernel: pf: State failure on: 1       |   

However in searching the logs for messages containing the IP address of 
the router (192.168.1.2) while running a full backup that errored out 
after just 2.2 MB of data transfer, I found these entries:

Apr  3 15:50:19 blacksheep kernel: pf: BAD state: TCP 192.168.1.2:50083 
192.168.1.2:50083 192.168.1.4:9103 [lo=1243881036 high=1243914340 
win=33304 modulator=0] [lo=3549637128 high=3549637922 win=33304 
modulator=0] 4:4 A seq=3549637128 ack=1243881036 len=1448 ackskew=0 
pkts=1081:1727 dir=out,rev
Apr  3 15:50:19 blacksheep kernel: pf: State failure on: 1       |   
Apr  3 15:50:19 blacksheep kernel: pf: BAD state: TCP 192.168.1.2:50083 
192.168.1.2:50083 192.168.1.4:9103 [lo=1243881036 high=1243914340 
win=33304 modulator=0] [lo=3549638576 high=3549639370 win=33304 
modulator=0] 4:4 A seq=3549638576 ack=1243881036 len=1448 ackskew=0 
pkts=1082:1728 dir=out,rev

I didn't monitor "pfctl -si" as you suggested.  Obviously the counters 
would be increasing dramatically.  So apparently state failure is my 
problem, likely caused by my misunderstanding of how to create a proper 
pf ruleset to achieve my goals.  I've been through OpenBSD's pf FAQ 
numerous times.  I've read Peter Hansteen's tutorial many times.  
However I still can't seem to get it through my thick head how to write 
a proper ruleset to get queuing to work the way I want.

Thanks for any suggestions,

Drew

-- 
Be a Great Magician!
Visit The Alchemist's Warehouse

http://www.alchemistswarehouse.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4612DE86.2000706>