Hi All,
Here's my config I'm using on my apu2 on my home network:
[apu2@apu2.domain.local:~]$ doas cat /etc/pf.conf
doas (apu2@apu2.domain.local) password:
# $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
# Macros
ext_if = "em0"
wifi_if0 = "athn0"
wifinet0 = "$wifi_if0:network"
tcp_out = "{www,https}"
icmp_types = "echoreq"
# Tables
table <dns_servers> {8.8.8.8,8.8.4.4}
table <ntp_servers> {216.239.35.12}
# Options
set skip on lo
set loginterface $ext_if
set limit states 100000
# ftp proxy rules
anchor "ftp-proxy/*"
pass in quick on !ext_if inet proto tcp from !$ext_if to any port
ftp divert-to 127.0.0.1 port 8021
# traffic normalization
match in all scrub (no-df random-id max-mss 1440)
# queueing
queue rootq_ext on $ext_if bandwidth 9M max 9M
queue sshq on $ext_if parent rootq_ext bandwidth 1M
queue ssh_prioq on $ext_if parent sshq bandwidth 200K min 200K
queue ssh_bulkq on $ext_if parent sshq bandwidth 800K min 800K
queue ackq on $ext_if parent rootq_ext bandwidth 2M min 500K
queue dnsq on $ext_if parent rootq_ext bandwidth 1M min 500K
queue webq on $ext_if parent rootq_ext bandwidth 4M min 4M max 8M
burst 7M for 300ms
queue defq on $ext_if parent rootq_ext bandwidth 1M min 500K default
queue rootq_wifi0 on $wifi_if0 bandwidth 100M max 100M
queue sshq on $wifi_if0 parent rootq_wifi0 bandwidth 10M
queue ssh_prioq on $wifi_if0 parent sshq bandwidth 2M min 1M
queue ssh_bulkq on $wifi_if0 parent sshq bandwidth 8M min 5M
queue ackq on $wifi_if0 parent rootq_wifi0 bandwidth 10M min 5M
queue dnsq on $wifi_if0 parent rootq_wifi0 bandwidth 10M min 5M
queue webq on $wifi_if0 parent rootq_wifi0 bandwidth 60M min 60M
max 90M burst 90M for 300ms
queue defq on $wifi_if0 parent rootq_wifi0 bandwidth 10M min 5M
default
# translation/NAT
match out on $ext_if inet from !$ext_if to any nat-to ($ext_if)
# packet filtering rules
block log all
pass out quick
antispoof quick for {lo $wifi_if0 $ext_if}
match inet proto tcp from any to any port ssh set queue (ssh_bulkq,
ssh_prioq)
match inet proto {tcp,udp} from any to any port {domain,ntp} set
queue (dnsq, ackq)
match inet proto tcp from any to any port $tcp_out set queue (webq,
ackq)
match inet proto tcp from any to any port ftp set queue (webq, ackq)
pass in quick on !$ext_if inet proto tcp from !$ext_if to any port
ssh
pass in quick on !$ext_if inet proto {tcp,udp} from !$ext_if to any
port domain rdr-to <dns_servers> port domain
pass in quick on !$ext_if inet proto {tcp,udp} from !$ext_if to any
port ntp rdr-to <ntp_servers> port ntp
#pass in quick on !$ext_if inet proto tcp from !$ext_if to any port
www divert-to 127.0.0.1 port 8080 # uncomment when using relayd transparent
proxy; remove 'www' from tcp_out macro...
pass in quick on !$ext_if inet proto tcp from !$ext_if to any port
$tcp_out
pass in quick on !$ext_if inet proto icmp from !$ext_if to any
icmp-type $icmp_types
Regards,
Glenn
On Sat, Apr 8, 2017 at 4:10 PM, Stuart Henderson <s...@spacehopper.org>
wrote:
> On 2017-04-05, Marko CupaÄ <marko.cu...@mimar.rs> wrote:
> > I still haven't found a way to throttle down queues to desired values
> > without using fixed min and max values.
>
> I haven't done very well with this either. I've had better luck with
> kernels built with higher HZ but haven't been really happy with it (and
> what I really want is to be able to limit bandwidth per-ip - with a
> limited amount of v4 space you can just about manage this with a lot of
> queue and assignment rules, but that's impossible for ipv6, and even
> with ipv4 makes it hard to use a decent amount of address space to
> mitigate against DHCP exhaustion attacks e.g. on public wifi).
>
> > Adding NAT to the mix
> > complicates things further. What about queueing of traffic inside GRE
> > tunnels in transport mode protected with IPSEC? Where to read about it?
>
> The queue is assigned to the PF state, based on the queue name.
> You can either do this in a "pass" rule or a "match" rule. NAT is easy
> to cope with using "match" when you take the following into account:
>
> : Translation
> : Translation options modify either the source or destination address and
> : port of the packets associated with a stateful connection. pf(4)
> : modifies the specified address and/or port in the packet and
> recalculates
> : IP, TCP, and UDP checksums as necessary.
> :
> : Subsequent rules will see packets as they look after any addresses and
> : ports have been translated. These rules will therefore have to filter
> : based on the translated address and port number.
>
> So you can simply do your queue assignment with a "match..queue" rule
> before the nat-to rule, then the queue rule will be evaluated while the
> packet still has the pre-NAT address.
>
> Also, if you're queueing in both directions (internet->local as well as
> local->internet) make sure the queues on the different interfaces have
> the same name, so you can just assign to e.g. "fast". I've often seen
> examples where people try to use two different names depending on the
> direction (e.g. "fast_in" and "fast_out") and run into problems when
> they try to assign to queues.
>
> > Optimistic me believes that devs are too busy making stuff work and
> > have no time to explain it to us poor admins (by means of manpages,
> > faqs or howtos). But how can I know how to use it if I can't read about
> > it anywhere?
>
> Queues never had the best documentation, I've tried improving it before
> but didn't manage to write anything that really helped. I think the most
> useful that I saw was in Jacek Artymiak's "building firewalls" book -
> but that was for altq and not relevant to newer PF/queues.
>
> If someone reading has a queue config that they're happy with, it would
> be nice to see pf.conf snippets!
>
> > Pessimistic me starts to notice that less and less free knowledge can be
> > found around the 'net.
>
> That's exactly the opposite of what OpenBSD is trying to do.
>
> > If I want answers to my questions, is the
> > best way to start saving money for paying OpenBSD consultants hourly
> > rates for tuition?
>
> Where the documentation leaves you with questions, I think the best
> way is to look at the code, mailing list posts and commit logs and try
> things out. If you can make any specific suggestions to improve docs,
> that would be really helpful.
