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" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, April 14, 2007 3:41 PM
Subject: Re: Scrub problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vadym Chepkov <[EMAIL PROTECTED]> 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 == [EMAIL PROTECTED]
"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-----
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
