List Info

Thread: PF occasionally "losing" packets




PF occasionally "losing" packets
country flaguser name
United States
2008-05-28 08:18:49
Hey Everyone,

I seem to have a problem with PF "losing" packets.
 With PF enabled 
(7.0-RELEASE) allowed traffic will sometimes get through but
more often 
will not.

More specifically, from the logs I can see packets passed
into the 
internal interface, but they often do not trigger the
outbound rule even 
though I allow everything out.

pass out quick log all
pass in quick log on fxp1 proto {tcp,udp} from X.33.195/24
to X.33.10.20 
port 53 keep state

Sometimes BIND requests will get through and I can see both
in/out rule 
trigger and get logged.

More often, I see the following in the logs when the
nslookup fails:

4. 835454 rule 21/0(match): pass in on fxp1:
X.33.195.244.45453 > 
X.33.10.20.53: [|domain]
242279 rule 21/0(match): pass in on fxp1: X.33.195.244.45454
> 
X.33.10.20.53: [|domain]
3. 756975 rule 21/0(match): pass in on fxp1:
X.33.195.244.45455 > 
X.33.10.20.53: [|domain]
242070 rule 21/0(match): pass in on fxp1: X.33.195.244.45454
> 
X.33.10.20.53: [|domain]
7. 756284 rule 21/0(match): pass in on fxp1:
X.33.195.244.45456 > 
X.33.10.20.53: [|domain]

Even though the packets are allowed in, they often never get
to the 
outbound interface. Note that this is not limited to bind
requests.  I 
see the same thing with ssh, ping, etc.

I've checked the routing table, interfaces, etc....   I
can't seem to 
pinpoint the cause.

Has anyone seen this inconsistency?

Thanks in advance for any help.

Louis

_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

Re: PF occasionally "losing" packets
user name
2008-05-28 11:28:39
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

user <userlgkap.com> wrote:
>
> I seem to have a problem with PF "losing"
packets.  With PF enabled
> (7.0-RELEASE) allowed traffic will sometimes get
through but more
> often will not.

Are you certain that the packets are not passing, or are
they simply not
being logged?  You appear to be assuming that every packet
that passes
will be logged via pflog(4).

> pass out quick log all
> pass in quick log on fxp1 proto {tcp,udp} from
X.33.195/24 to X.33.10.20 port 53 keep state

Both of your rules specify that state be established
("keep state" is
now explicit in 7.0).  Packet logging is only performed when
the
rulebase is matched; once that is done, state is established
and packets
matching that state are passed without being logged.

The only way to be sure you are losing traffic is by running
tcpdump on
both the internal and external interface, and comparing
traffic.

- -- 
David DeSimone == Network Admin == foxverio.net
"This email message is intended for the use of the
person to whom
 it has been sent, and may contain information that is
confidential
 or legally protected.  If you are not the intended
recipient or have
 received this message in error, you are not authorized to
copy, dis-
 tribute, or otherwise use this message or its attachments. 
Please
 notify the sender immediately by return e-mail and
permanently delete
 this message and any attachments.  Verio, Inc. makes no
warranty that
 this email is error or virus free.  Thank you." 
--Lawyer Bot 6000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFIPYg3FSrKRjX5eCoRAhoAAKCgj9IB0LY4Iu3AHrXTZPoF+2ramQCf
WeV8
tjLhYkVQ3Tq4FlbnJatf5A0=
=wg8t
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )