Date: Tue, 30 Nov 2004 16:27:53 +0200 From: mzk <mzk@anti-offline.net> To: <freebsd-pf@freebsd.org> Subject: Re: PF strange problem. Message-ID: <20041130162753.312353@mzk> In-Reply-To: <200411292002.10067.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>=A0On Sunday 28 November 2004 22:51, mzk wrote:
>>=A0First sorry my English and sorry my other mistakes, but that is
>>=A0my first post in mailing list ever. :-) Today i understood my pf
>>=A0doesn't work properly. For each host of my network i have 4
>>=A0rules, 2 out (from int_if) and 2 in like:
>>
>>=A0pass out quick on $int_if from <peering>=A0to $host queue
>>=A0peering_host_in pass out quick on $int_if from any to $host queue
>>=A0host_in pass in quick on $int_if proto { tcp, udp } from $host to
>>=A0<peering>=A0port $ports
>>=A0pass in quick on $int_if proto { tcp, udp } from $host to any
>>=A0port $ports
>>
>
>=A0Okay, first of all some generic notes:
>=A01) Consider stateful rules. It will not only make the firewall
>=A0faster but will also make sure that all outgoing traffic of a
>=A0"connection" is enqueued to the same queue. This simplifies the
>=A0ruleset a lot.
>=A02) Use "$pfctl -vv -tpeering -Ttest [someip]" to verify that the
>=A0table really contains what you think it does.
I tried these notes, thanks!
1) stateful rules should speed up my firewall
2) i understood my peering table (pf actually) works correctly
>
>>=A0The problem is, that the first `peering` rule works like the
>>=A0second one ->=A0it pass everything from anyone using the
>>=A0peering_host_in queue. If i comment it, the second rule works,
>>=A0but that's not the idea. So my international connection (the
>>=A0second rules) is overloaded and i could not make good QoS. I am
>>=A0using GENERIC with these options, added by me ->
>>
>
>=A0I don't really get what you are saying here. Sorry. Can you try to
>=A0rephrase, please? Maybe you can also include the rules in question
>=A0with match-counters: "$pfctl -vvsr" and the queue stats: "$pfctl -
>=A0vsq" Both are also good tools for debugging the ruleset.
The upper supposition is almost wrong. I found the problem, which was: my=
peering table consist of hundreds of networks. One of these networks is=
mine. When ftp-proxy is running (so i can run ftp for my users), it is with=
`peering` ip (ip of the internal interface or some another router interface=
ip), so client of my network does not actually download from ftp host=
somewhere in the net, it downloads from the router's internal interface ip.=
For the router's internal ip i have no queue definitions, no shape.=
Therefore everybody can download without speed limit from ftp sites. ;).
>
>=A0I hope these pointers help, and am really sorry that I don't fully
>=A0understand what the problem is.
These pointers were very very useful for me! Thank you! I have to get some=
English courses ;)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041130162753.312353>