Scrub problem

[Vadym Chepkov]

I see server packets on server interface and on incoming pf interface
none of fragments  reach pf dmz interface and client.
Loud shows these:

Apr 15 18:35:12 gateway kernel: pf_normalize_ip: reass frag 13479 @ 0-1480
Apr 15 18:35:12 gateway kernel: pf_normalize_ip: reass frag 13479 @ 
1480-2023
Apr 15 18:35:12 gateway kernel: pf_reassemble: 2023 < 2023?
Apr 15 18:35:12 gateway kernel: pf_reassemble: complete: 0xc4e72d00(2043)
Apr 15 18:35:22 gateway kernel: pf_normalize_ip: reass frag 13735 @ 0-1480
Apr 15 18:35:22 gateway kernel: pf_normalize_ip: reass frag 13735 @ 
1480-2023
Apr 15 18:35:22 gateway kernel: pf_reassemble: 2023 < 2023?
Apr 15 18:35:22 gateway kernel: pf_reassemble: complete: 0xc5305400(2043)
Apr 15 18:35:32 gateway kernel: pf_normalize_ip: reass frag 13991 @ 0-1480
Apr 15 18:35:32 gateway kernel: pf_normalize_ip: reass frag 13991 @ 
1480-2023
Apr 15 18:35:32 gateway kernel: pf_reassemble: 2023 < 2023?
Apr 15 18:35:32 gateway kernel: pf_reassemble: complete: 0xc4f13100(2043)

----- Original Message ----- 
From: "David DeSimone" <fox at verio.net>
To: <freebsd-pf at freebsd.org>
Sent: Saturday, April 14, 2007 3:41 PM
Subject: Re: Scrub problem


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vadym Chepkov <vchepkov at gmail.com> wrote:
>>
>> The problem is with fragmented UDP packets from Amanda server
>> I have the scrub directive set:
>>
>> scrub in all fragment reassemble
>>
>> 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
>
> Did you notice that not neither the larger nor the smaller segment of
> the fragmented packets are arriving at the client?  Is it possible that
> the fragments are not being transmitted on the sending side?  You did
> not say whether the trace you took was on the inside or the outside
> interface of the PF router.
>
>> I tried to add no-df option to the scrub rule, but it didn't make any 
>> effect
>
> None of your packets have DF set, so there is no DF flag to be cleared
> by such a rule.
>
>> 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?
>
> No, 1514 is just the physical size of the IP datagram when transmitted
> via ethernet.  Ethernet adds 6 bytes each for src mac, dst mac, and 2
> bytes for ethertype ipv4.  1500 + 6 + 6 + 2 = 1514.
>
>> pf silently (no log entries) drops last packets, because they never
>> reach the client:
>
> Maybe PF does not log the packets via pflog0 interface, but does it log
> anything via dmesg?  Did you try setting a higher debug level via 'pfctl
> - -x loud' for example?
>
> - -- 
> David DeSimone == Network Admin == fox at verio.net
>  "It took me fifteen years to discover that I had no
>   talent for writing, but I couldn't give it up because
>   by that time I was too famous.  -- Robert Benchley
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFGIS5UFSrKRjX5eCoRAt2oAJ9GFQ9lH4T6oIRkyWdI70UOO1lZvACfTLia
> y4Oy/ip00P6djB4s9f5QM4U=
> =vA8k
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"