Scrub problem

Vadym Chepkov vchepkov at gmail.com
Sat Apr 14 14:10:54 UTC 2007


Hi,

I finally figured out the issue, but now I honestly don't know what to do with it.
The problem is with fragmented UDP packets from Amanda server
I have the scrub directive set:

# pfctl -sr | head -1
scrub in all fragment reassemble

These packets are getting out from Amanda server:

08:27:13.259450 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 163: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 121
08:27:13.268607 00:30:48:5c:27:ad > 00:30:48:27:ea:80, ethertype IPv4 (0x0800), length 92: 192.168.160.2.amanda > 192.168.17.2.858: UDP, length 50
08:27:13.269355 00:30:48:5c:27:ad > 00:30:48:27:ea:80, ethertype IPv4 (0x0800), length 129: 192.168.160.2.amanda > 192.168.17.2.858: UDP, length 87
08:27:13.276096 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 92: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 50
08:27:13.277424 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 1514: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 1894
08:27:13.277434 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 456: 192.168.17.2 > 192.168.160.2: udp
08:27:23.529888 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 1514: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 1894
08:27:23.529895 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 456: 192.168.17.2 > 192.168.160.2: udp
08:27:33.527287 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 1514: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 1894
08:27:33.527293 00:30:48:27:ea:80 > 00:30:48:5c:27:ad, ethertype IPv4 (0x0800), length 456: 192.168.17.2 > 192.168.160.2: udp

pf silently (no log entries) drops last packets, because they never reach the client:

08:27:13.259532 00:0e:0c:c3:42:b4 > 00:30:48:43:32:c8, ethertype IPv4 (0x0800), length 163: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 121
08:27:13.268356 00:30:48:43:32:c8 > 00:0e:0c:c3:42:b4, ethertype IPv4 (0x0800), length 92: 192.168.160.2.amanda > 192.168.17.2.858: UDP, length 50
08:27:13.269021 00:30:48:43:32:c8 > 00:0e:0c:c3:42:b4, ethertype IPv4 (0x0800), length 129: 192.168.160.2.amanda > 192.168.17.2.858: UDP, length 87
08:27:13.276140 00:0e:0c:c3:42:b4 > 00:30:48:43:32:c8, ethertype IPv4 (0x0800), length 92: 192.168.17.2.858 > 192.168.160.2.amanda: UDP, length 50

I tried to add no-df option to the scrub rule, but it didn't make any effect
But I am 100% positive this is the issue, since when I turn off scrubbing and add the rule
pass in quick proto udp from $amanda_server fragment
everything works fine.

I am a little confused why size of the first part the fragment is 1514 bytes, since MTU on the interface is 1500, could it be something to do with it?

I suspect this is happenning with some other packets as well, since it's nothing to do with amanda per se, so any help is highly appreciated.

Thank you,
Vadym Chepkov

----- Original Message ----- 
From: "Douglas K. Rand" <rand at meridian-enviro.com>
To: "Vadym Chepkov" <vchepkov at gmail.com>
Cc: <freebsd-pf at freebsd.org>
Sent: Tuesday, April 03, 2007 2:57 PM
Subject: Re: packet filter and amanda


> Vadym> Hello everybody,
> 
> Hello
> 
> Vadym> I have a router with  FreeBSD 6.2-RELEASE-p1 with custom buld kernel:
> 
> Vadym> device          pf              # PF OpenBSD packet-filter firewall
> Vadym> device          pflog           # logging support interface for PF
> 
> Vadym> I am using amanda to backup a client which is behind router
> Vadym> with pf running amanda server - FreeBSD pf - amanda client
> 
> Vadym> I compiled amanda with tcp/udp port ranges but I can get that far.
> 
> We use the knobs in /etc/make.conf to control which ports Amanda uses:
> 
>   AMANDA_PORTRANGE = 50001,50099
>   AMANDA_UDPPORTRANGE = 801,899
> 
> Please note that recent versions of Amanda were not correctly
> respecting the AMANDA_PORTRANGE knob. You need a ports tree that is
> post PR 110687.
> 
> It was unclear to me if you are trying to backup your firewall or
> systems on the other side of your firewall. For backups of the actual
> firewall you need to allow traffic from your Amanda server from any
> arbitrary UDP port to port 10080 on your firewall. You also need to
> allow TCP connections from any port on your Amanda server to your
> firewall in the range defined by AMANDA_PORTRANGE. And lastly, your
> firewall needs to allow UDP traffic originating from port 10080 from
> itself heading back to the Amanda server destined for ports in
> AMANDA_UDPPORTRANGE.
> 
> The reference on Amanda FAQ is at
> 
>   http://amanda.sourceforge.net/cgi-bin/fom?_highlightWords=10080&file=139
> 
> Snippets of our ruleset:
> 
> int_amanda="{ 10.10.10.26/32, 67.134.74.26/32 }"
> amanda_tcp="50000:50100"
> amanda_udp="800:900"
> [...]
> pass  in log quick inet proto tcp  from $int_amanda  to <dmz> port $amanda_tcp flags S/SARF keep state (no-sync)
> pass  in log quick inet proto udp  from $int_amanda  to $int  port amanda                   keep state (no-sync)
> [...]
> pass out log quick on $int inet proto udp  from $int to $int_amanda  port $amanda_udp keep state (no-sync)
> [...]
> pass log quick inet proto udp from <dmz>        port = amanda  to $int_amanda port $amanda_udp
> 
> 
> And on a DMZ host we have:
> 
> amanda="67.134.74.26"
> amandatcpports="50000:50100"
> amandaudpports="800:900"
> [...]
> pass in  log quick inet proto tcp  from $amanda    to $lan port $amandatcpports flags S/SARF keep state
> pass in  log quick inet proto udp  from $amanda    to $lan port amanda                       keep state
> [...]
> pass out log quick inet proto udp  from $lan port amanda to $amanda port $amandaudpports   keep state
> 
> Hope this helps.


More information about the freebsd-pf mailing list