Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 02 May 2017 11:31:45 +0430
From:      "Babak Farrokhi" <farrokhi@FreeBSD.org>
To:        Max <maximos@als.nnov.ru>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: Similar entries in source tracking table
Message-ID:  <C22C7217-CE09-4C3B-89CC-8EA52E892C38@FreeBSD.org>
In-Reply-To: <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru>
References:  <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello,

Here it is:

# pfctl -vvsS
No ALTQ support in kernel
ALTQ related functions disabled
192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s )
   age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0
192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s )
   age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0

# pfctl -vvss
No ALTQ support in kernel
ALTQ related functions disabled

I am running 11-STABLE r317643. Please note that this is only reproducibl=
e when you reload your pf configuration and tables.

=E2=80=94
Babak


On 2 May 2017, at 10:41, Max wrote:

> Hello,
> Can you show "pfctl -vsS" output? And what version of FreeBSD are you r=
unning?
>
>
> 01.05.2017 17:59, Babak Farrokhi =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>> Hello,
>>
>> I was running an experiment with pf in which I encountered an unusual =
case.
>>
>> In a nat setup, is this okay to have multiple similar entries in sourc=
e tracking table?
>>
>> # pfctl -sS
>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s =
)
>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s =
)
>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s =
)
>>
>> There are actually three similar binding stuck in source tracking tabl=
e.
>> vmstat output also confirms separate memory allocation for three entri=
es in
>> source tracking table:
>>
>> #  vmstat -z | egrep 'ITEM|^pf'
>> ITEM                   SIZE  LIMIT     USED     FREE      REQ FAIL SLE=
EP
>> pf mtags:                48,      0,       0,       0,       0,   0,  =
 0
>> pf states:              296, 8000005,       0,    1313,    2279,   0, =
  0
>> pf state keys:           88,      0,       0,    2655,    4558,   0,  =
 0
>> pf source nodes:        136, 1500025,       3,     142,       7,   0, =
  0
>> pf table entries:       160, 800000,       4,     121,      47,   0,  =
 0
>> pf table counters:       64,      0,       0,       0,       0,   0,  =
 0
>> pf frags:               112,      0,       0,       0,       0,   0,  =
 0
>> pf frag entries:         40, 100000,       0,       0,       0,   0,  =
 0
>> pf state scrubs:         40,      0,       0,       0,       0,   0,  =
 0
>>
>>
>> I can reproduce this behavior by reloading pf.conf and running traffic=
 through
>> the box and get a new entry added to source tracking table.
>>
>> Here is the nat rule:
>>
>> # pfctl -vsn
>> nat on em0 inet from <internal-net> to any -> <external-net> round-rob=
in sticky-address
>>    [ Evaluations: 368       Packets: 50        Bytes: 2084        Stat=
es: 0     ]
>>    [ Inserted: uid 0 pid 6418 State Creations: 28    ]
>>
>> and timers:
>>
>> # pfctl -st
>> tcp.first                    10s
>> tcp.opening                  10s
>> tcp.established            4200s
>> tcp.closing                  10s
>> tcp.finwait                  15s
>> tcp.closed                   10s
>> tcp.tsdiff                   30s
>> udp.first                    60s
>> udp.single                   30s
>> udp.multiple                 60s
>> icmp.first                   20s
>> icmp.error                   10s
>> other.first                  60s
>> other.single                 30s
>> other.multiple               60s
>> frag                         30s
>> interval                     30s
>> adaptive.start                0 states
>> adaptive.end                  0 states
>> src.track                  3600s
>>
>> Any ideas if this behavior is expected?
>>
>> =E2=80=94
>> Babak
>
> _______________________________________________
> freebsd-pf@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"

--=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCABmBQJZCC7ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMDgxNUY4ODYxQkYyREVBRjI2MUU5QzE2
QjI2N0FEODVENjMyRTlBAAoJEGsmethdYy6aw1QP/RkVIASAvKKmaUp+n5rPNs7l
DXhi6PPp0IGrUb5bjwselgUucze/bt7S4yRgQIx2kgJs15Ao4M/3Bx63HveqZQRF
ESf9AlwRsbh6DTp5fda33i4S4opXSisZdXf+5rhFBegfl85Mg8HoHP0XqghBIHsF
A28F0ucEUBxvN+xNZQ/3XFE7HFQh16xjfvDtBF+gW8l6ECLLjKwB5uyrLLQqZYVk
F7mERMbuoFDXaZSMEtxXTWPzNwJzTRgxsHd7xW42fVR6DIxosaWkSg9q4TaQIXI8
671tbjqKyAvZJNnDE+Jkh3+Bji3f2U6hZ4LzbRRJL572LVBv/lhuCAVo0+oUwqzO
kwM2lRvbJmjHMUwqv2Plgx7vMFXcUASSOHeKHsWTf4yUlm4Sh3OSauXtLHLxW26R
LHFAkQxmoRJbQcKUzOdtlFta9+/u2VfhVvZ+QYqH7OTIOZ3shbrXdlZHO4SgmaTJ
lLzINMH8okCy1Sov3Nr9tvHF6M9vuypnkA1pH9Tl/buYtSN/dcy4rXK8MJ/uSIV8
6+g8SpaKtY2PB1Oa3oY5JusBE7VD2/PXNnNU8MsDADPWk2TqFSyp0seGUYJYUFW1
QxLGFQvmXmGu0zmnJqC2JMfTpJ/rDiKSA5FuJW6oJ9QXo9vTRxGasp8I5CKVCMRL
0O55hakSHrYrnF/jwkoW
=bhE3
-----END PGP SIGNATURE-----

--=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_=--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C22C7217-CE09-4C3B-89CC-8EA52E892C38>