Re: Routing VPNs through a second interface.
On Wed, Aug 20, 2008 at 07:02:28AM -0700, Jeff Simmons wrote: ike passive esp from $lan_net to $remote_lan_net peer $remote_gw_addr ike passive esp from $T1-2_addr to $remote_gw_addr do you totally want passive, or is that just an artifact of trying to get things work reliably? pass in quick on $T1-2_if reply-to ($T1-2_if $T1-2_gw) proto 50 from any to $T1-2_addr keep state pass in quick on $T1-2_if reply-to ($T1-2_if $T1-2_gw) proto udp from any to $T1-2_addr port 500 so you want something like: if ([ $proto -eq $udp ] [ $port -eq $isakmp ]) || [ $proto -eq $esp ]; then use T1-2 else use T1-1 fi does traffic from $remote_ipsec_peer to you already end up coming in T1-2 on its own, or does it come into T1-1? if yes, is that already only for ipsec-related traffic, or do they currently send everything to your T1-2 iface as-is? -- jared
Re: proper syntax for label on rdr rule
On Thu, May 22, 2008 at 03:42:45PM -0400, Chris Smith wrote: Are there some limitations to what rules can apply labels? I'm trying to add a label to a rdr rule but keep getting a syntax error. when i have this question, i search from the bottom of the pf.conf manpage up (the grammar section) for whatever keyword i want. doing so for label shows the following can take labels: - antispoof - filteropt so then i check for 'filteropt' and see that it is valid in 'filteropt-list', which is only valid in: - pf-rule so nope; no label on rdr :( -- jared
Re: binat question
On Mon, May 12, 2008 at 11:44:29PM -0700, Trevor Talbot wrote: You might also need to use the static-port option for udp nat rules: nat pass log on $ext_if proto udp from $funshine port $COH_ports to any - 85.200.10.151 static-port yeah, i was gonna say static port too, but trevor beat me binat might do that implicitly. i know for certain asheron's call needs static port; tons of games suck at the internet. -- jared
Re: Fair distribution of borrowed bandwidth with a lot of users
On Tue, Apr 24, 2007 at 09:49:32AM +0200, Federico Giannici wrote:
jared r r spiegel wrote:
On Tue, Apr 24, 2007 at 01:42:26AM -0400, jared r r spiegel wrote:
On Mon, Apr 23, 2007 at 10:12:56AM +0200, Federico Giannici wrote:
How can I make a single queue don't borrow ALL the traffic?
upperlimit
OK, my question was badly expressed.
I have already written the problem a few times: the question is not to
put an upper limit to a queue but to don't make it monopolize all the
bandwidth because of its great amount of traffic, leaving queues with
low traffic with ALL packets dropped (as you van see in the pftop
snapshot I sent).
I already explained it with the following example:
Both users A and B have an assigned bandwidth of 1 bps.
User A currently requires 4 bps.
User B currently requires 100 bps.
There are currently available 10 bps.
I'd like that the 10 bps would be equally distributed to both users (as
they have the same assigned bandwidth), so both had potentially 5 bps.
User A uses 4 bps and leaves 1 bps to user B that so uses 6 bps.
This is the fair bandwidth assignment I'd like to implement.
Indeed it seems that, as user B requires 25 times more bandwidth of user
A, then it is assigned almost ALL bandwidth, and user A is not able to
use more then it's committed 1 bps, and so 3 out of 4 bits are dropped!
in this case it is probably not super important to see your
whole pf.conf, but without seeing the service curves you're
applying to the queues, it's a bit of flying blind.
it seems to me that what you want to do is feasible with HFSC.
posting your altq section would be helpful in trying to
resolve the problem you're seeing.
Attached is the part of the pf.conf files that defines that part of
queues. As you can see it's pretty simple. (Only wh1_i has an upperlimit
because all the others have a limit in their router.)
how did wh10_i get to be 527KB/s if wdsl_i is capped out at 1650Kb/s?
queue wdsl_i bandwidth 1650Kb { wdsl_hi_i wdsl_low_i }
queue wdsl_hi_i bandwidth 99% { wh1_i wh2_i wh3_i wh4_i wh5_i wh6_i
wh7_i wh8_i wh9_i wh10_i wh11_i wh12_i wh13_i wh14_i wh15_i wh16_i wh17_i
wh18_i wh19_i wh20_i wh21_i wh22_i wh23_i wh24_i wh25_i wh26_i wh27_i wh28_i
wh29_i wh30_i wh31_i wh32_i wh33_i wh34_i wh35_i wh36_i wh37_i wh38_i wh39_i
wh40_i wh41_i wh42_i wh43_i }
queue wh1_i bandwidth 6400b hfsc( linkshare 6400b
upperlimit 2048Kb )
queue wh2_i bandwidth 6400b hfsc( linkshare 6400b )
queue wh3_i bandwidth 6400b hfsc( linkshare 6400b )
queue wh4_i bandwidth 2000b hfsc( linkshare 2000b )
queue wh5_i bandwidth 2000b hfsc( linkshare 2000b )
snip
i've never used HFSC without explicitly defining realtime scs.
when i pass your queues through pfctl -nvvf after the following
edits:
- i took only the first 12 whX_i queues
- put in the missing 'altq on'
- added wdsl_low_i, and made it default
i see:
[/home/jrrs] $ pfctl -nvvf pf.test
altq on em0 hfsc bandwidth 8Mb tbrsize 6000 queue { wdsl_i }
queue wdsl_i bandwidth 1.65Mb { wdsl_hi_i wdsl_low_i }
queue wdsl_low_i bandwidth 1% hfsc( default )
queue wdsl_hi_i bandwidth 99% { wh1_i wh2_i wh3_i wh4_i wh5_i wh6_i wh7_i wh8_i
wh9_i wh10_i wh11_i wh12_i }
queue wh1_i bandwidth 6.40Kb hfsc( upperlimit 2.05Mb )
queue wh2_i bandwidth 6.40Kb
queue wh3_i bandwidth 6.40Kb
queue wh4_i bandwidth 2Kb
queue wh5_i bandwidth 2Kb
queue wh6_i bandwidth 2Kb
queue wh7_i bandwidth 2Kb
queue wh8_i bandwidth 2Kb
queue wh9_i bandwidth 2Kb
queue wh10_i bandwidth 6.40Kb
queue wh11_i bandwidth 6.40Kb
queue wh12_i bandwidth 2Kb
the first thing that strikes me is that there are no HFSC specific
declarations there for the subqueues, only 'bandwidth'.
in my experience with HFSC, the bandwidth keyword has very little to
do with anything other than it having to be set low enough so that
the sum of all the child queues' bandwidth doesn't exceed the parent.
i guess that the rest of the parameters are not present (in my pfctl output)
because the ones in the queue declarations in pf.conf equate to what
the defaults would be. changing the linkshare a bit seems to corroborate
this.
my first guesses would be to define a realtime explicitly (as 6400b for
one of your 6400b queues is certainly not the default, as it shows up
in pfctl -nvvf output if you explicltly say it) and/or to use an actual
sc for linkshare (define m1 and d) instead of a static number (which then
equates to having only defined m2).
from what i understand of HFSC, the service curves are where the real magic
happens -- if you're not using them in a curve fashion at all, it seems
that you end up with something not very different from regular CBQ.
it may also help, if the interface these queues hang off of has more
bandwidth (say, link of 100Mb?) than you're trying to limit
people to (in the popular
Re: Fair distribution of borrowed bandwidth with a lot of users
On Tue, Apr 24, 2007 at 01:42:26AM -0400, jared r r spiegel wrote: On Mon, Apr 23, 2007 at 10:12:56AM +0200, Federico Giannici wrote: How can I make a single queue don't borrow ALL the traffic? upperlimit in this case it is probably not super important to see your whole pf.conf, but without seeing the service curves you're applying to the queues, it's a bit of flying blind. it seems to me that what you want to do is feasible with HFSC. posting your altq section would be helpful in trying to resolve the problem you're seeing. -- jared
Re: sample of bandwidth limit per source IP
On Wed, Mar 07, 2007 at 02:36:35PM +0800, Edy wrote: Hi, I am wondering if anyone has sample config on limiting bandwidth per source IP? For example, limiting an IP 192.168.1.2 for service http to 30Kb/sec if you want to limit outgoing bandwidth per incoming source IP, you need to assign the outgoing traffic to a queue unique to that IP. so in the example there, you'd need a CBQ or HFSC queue that your ruleset only referenced with respect to that individual host. block inet proto tcp from any to port 80 pass on $ext inet proto tcp from any to port 80 keep state queue q_others pass on $ext inet proto tcp from 192.168.0.0/16 to port 80 keep state queue q_internal pass on $ext inet proto tcp from 192.168.1.2 to port 80 keep state queue q_192_168_1_2 pass on $ext inet proto tcp from 192.168.1.3 to port 80 keep state queue q_192_168_1_3 and then you set up each of those queues in the altq section however you want, which means you can hit the number of individual defined queues limit if you want to do this on a large scale. i don't remember offhand what the limits are, but i think you can find them somewhat easily in the .c or .h files. something like 64 or 256 last i recall... if 192.168.1.2 in your situation is a host behind the pf(4) firewall, and you want to limit *incoming* bandwith from the world... that's a whole other discussion that's all over the archives, but basically you need to queue outbound on the interface on the firewall that is facing the host in question, instead of the world facing one, and the caveat is that of course you don't have control over the rate the world sends data to the firewall, but rather, only over the rate at which the firewall forwards it to the internal host. i think i made a big post at one time giving an analogy about this using an animal shelter and the rate at which people want to drop puppies off at the shelter versus the rate that the shelter gives them out to other people, or something like that.. search the misc@ archives for puppies, probably find it... -- jared
Re: arpresolve: can't allocate llinfo
On Tue, Feb 27, 2007 at 04:37:27PM -0600, Travis H. wrote: I am not sure if this is pf-related, but has anyone seen this error message, and what condition actually causes it? Incomplete arp table? Out of memory? Something else? i've seen it in the situation where something happens that tries to perform a route lookup with XYZ IP addr as the next hop, but XYZ is not on any connected interface and the box cannot derive what the XYZ IP's enet addr should be. for instance, if you had a route-to/reply-to rule that specified a certain nexthop addr that really isn't something you're connected to via an enet iface (eg, if you can ping it, but then you check output of arp(8), you would never expect to see an entry for that host's enet addr). that's not the only context (pf route-to/reply-to) that it can happen, but perhaps the general principle could still apply -- jared
Re: PF Table Size - Sanity Check
On Wed, Nov 08, 2006 at 12:22:19AM +0100, Michiel van Baak wrote:
On 22:12, Tue 07 Nov 06, C?dric Berger wrote:
There is no way it can work on a 32-bit i386 system.
This kind of pointer limitation is the first reason why
ppl move to 64-bit systems, so that might be worth testing
on a (maybe tuned) amd64 kernel.
How about the core 2 duo and xeon intel stuff ?
Those are EMT64.
hope this one is not too old to reply to.
working on a project to put a pair of dell 1950s in as a
failover spamd(8)/greylist pair ( the secondary will just pass traffic
and not greylist ) in front of our MXs.
we have ~1.2M unique IPs hit our MXs ( customer relays counted
seperately ) accounting for 37M connections to the MX cluster per day
( well, at least on nov.27th ).
on the plate is a desire to take any of the RBLs we currently use
to refuse mail by (eg, the matching hosts talk to the real MX but the
real MX has 0 intent of relaying any mail for them) and put as much
of that as we can also in the spamd table.
i'll put dmesg at the bottom. one of the questions i have is whether
we ought to be running i386 or amd64 on this guy. currently i have amd64 on
there as i386 either stalled indefinately at boot or had a pause that
was longer than i was willing to wait - but that's besides the point,
i have to make a proper report for that one first.
anyway, amd64 boots.
here's an attempt (looks ok) to load the CBL (the _cbl.zone file i just
stripped all the non-table-friendly content out of) into a table.
first, set 'limit table-entries' to 8M in pf.conf, then:
In use 4835K, total allocated 5688K; utilization 85.0%
# vmstat -m | grep -e '^pf' -e ^In
pfiaddrpl120803 1 0 1 1 0 80
pfrulepl 720 240 11 5 0 5 5 0 81
pfstatepl392 1950 194 1 0 1 1 0 10000
pfaltqpl 144 280 14 2 0 2 2 0 80
pfpooladdrpl 88603 1 0 1 1 0 80
pfrktable 1296 62830 6277 3 0 3 3 0 3341
pfrkentry216300 1 0 1 1 0 23 0
pfosfpen 112 6960 34812 21010 0 80
pfosfp40 4160 208 3 0 3 3 0 80
In use 4837K, total allocated 5688K; utilization 85.0%
# ls -l _cbl.zone; wc -l _cbl.zone
-rw-r--r-- 1 root wheel 54702696 Nov 28 17:31 _cbl.zone
3899399 _cbl.zone
# vmstat -m | grep -e '^pf' -e ^In
pfiaddrpl120803 1 0 1 1 0 80
pfrulepl 720 240 11 5 0 5 5 0 81
pfstatepl392 1950 194 1 0 1 1 0 10000
pfaltqpl 144 280 14 2 0 2 2 0 80
pfpooladdrpl 88603 1 0 1 1 0 80
pfrktable 1296 62860 6280 3 0 3 3 0 3341
pfrkentry216 38994020 3899399 2166340 216634 216634 0 23
216633
pfosfpen 112 6960 34812 21010 0 80
pfosfp40 4160 208 3 0 3 3 0 80
In use 4838K, total allocated 872220K; utilization 0.6%
# pfctl -t cbl -Ts | wc -l
pfctl: Table does not exist.
0
# echo table cbl persist file _cbl.zone | pfctl -vf- -Tl
table cbl persist file _cbl.zone
# pfctl -sT
cbl
spamd-white
# pfctl -t cbl -Ts | wc -l
3899399
# vmstat -m | grep -e '^pf' -e ^In
pfiaddrpl120803 1 0 1 1 0 80
pfrulepl 720 240 11 5 0 5 5 0 81
pfstatepl392 1950 194 1 0 1 1 0 10000
pfaltqpl 144 280 14 2 0 2 2 0 80
pfpooladdrpl 88603 1 0 1 1 0 80
pfrktable 1296 62950 6288 3 0 3 3 0 3340
pfrkentry216 77988010 3899399 2166340 216634 216634 0 23 0
pfosfpen 112 6960 34812 21010 0 80
pfosfp40 4160 208 3 0 3 3 0 80
In use 827367K, total allocated 872224K; utilization 94.9%
so tried it again (now that i am remembering persist) few more times (using a
new table name so as to keep adding stuff) but it runs out of memory now.
tried flushing the tables ('-FT') and then running around to the other
RBLs we have, here's one weighing in at 6199567 entries.
this syntax of the following is invalid because i just made a quickie cutup
of the big long commandline that i actually ran - the content is the same,
just
the EOLs and '\'s are bogus:
# pfctl -FT ; \
echo
table poop
Re: PF+ALTQ+HFSC
On Sun, May 07, 2006 at 03:31:22PM +0700, sugeng riadi wrote: i want shaping trafik to client by port or aplication, but my config not runing properly, the ftp package canot over from gw any one help me please..!!?? this my config does the config load correctly? 'pfctl -nvf /etc/pf.conf' has no complaints? block in on $int_if all ... block out on $int_if all change those to: block in log on $int_if all and block out log on $int_if all then tcpdump on 'pflog0' interface. pflogd will be running by default unless you turned it of with rc.conf/rc.conf.local, as long as pf=YES also during startup. after you start the tcpdump, attempt FTP again. if your ruleset is blocking you, it will show up in pflog. it should give you an idea of what kind of rule you would need to add. also, is there a chance that this is all you need? : http://openbsd.rt.fm/faq/pf/ftp.html -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
Re: nat issue
On Tue, Feb 28, 2006 at 11:22:48PM -0500, Yasholomew Yashinski wrote: I'm not sure what changed, as I haven't made any changes in the past 48 hours that I recall other than a portupgrade, however when I got home this afternoon my NAT was hosed. I'm using tun0 (PPPoE over hme0) on FreeBSD 6.0 sparc64. this wouldn't relate to your situation given the lack of changes, but any time i've had translation rules not _function_ (match/apply) and i spent an hour+ pulling my hair out to figure out why, it's because i got the bright idea to put a 'set skip on $the_iface_where_my_rdrs_are_broke_now' in there... the other one is where i forget ip.forwarding=1 and no packets even attempt to come out the other side ( different from them being not NAT'ted ), but that's not your case. from pf.conf: anon_gw=206.248.137.44 nat_net=192.168.1.0/28 tun_if=tun0 nat on $tun_if from $nat_net to any - $anon_gw # pfctl -sn nat on tun0 inet from 192.168.1.0/28 to any - 206.248.137.44 rdr inet proto tcp from spamd to any port = smtp - 127.0.0.1 port 8025 from sysctl: net.inet.ip.forwarding: 1 on the firewall/gateway: # tcpdump -i rl0 port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 18:00:18.000470 IP 192.168.1.8.33243 www.fark.com.http: S 3062197018:3062197018(0) win 5840 mss 1460,sackOK,timestamp 10515598 0,nop,wscale 0 18:00:20.998748 IP 192.168.1.8.33243 www.fark.com.http: S 3062197018:3062197018(0) win 5840 mss 1460,sackOK,timestamp 10518598 0,nop,wscale 0 18:00:26.997008 IP 192.168.1.8.33243 www.fark.com.http: S 3062197018:3062197018(0) win 5840 mss 1460,sackOK,timestamp 10524598 0,nop,wscale 0 # tcpdump -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes 21:26:11.22 IP mail.yashy.com 0.0.0.0: pfsync 452 21:26:11.255089 IP mail.yashy.com.51821 dns.pppoe.ca.domain: 16429+ [1au] PTR? 44.137.248.206.in-addr.arpa. (56) 21:26:11.306036 IP dns.pppoe.ca.domain mail.yashy.com.51821: 16429 1/2/3 PTR[|domain] 21:26:11.310112 IP mail.yashy.com.51821 dns.pppoe.ca.domain: 58322+ [1au] PTR? 0.0.0.0.in-addr.arpa. (49) 21:26:11.360753 IP dns.pppoe.ca.domain mail.yashy.com.51821: 58322 NXDomain* 0/1/1 (99) 21:26:12.364075 IP mail.yashy.com 0.0.0.0: pfsync 228 21:26:12.366593 IP mail.yashy.com.51821 dns.pppoe.ca.domain: 29161+ [1au] PTR? 22.154.248.206.in-addr.arpa. (56) 21:26:12.418296 IP dns.pppoe.ca.domain mail.yashy.com.51821: 29161 1/2/3 PTR[|domain] 21:26:13.421003 IP mail.yashy.com 0.0.0.0: pfsync 452 21:26:14.425044 IP mail.yashy.com 0.0.0.0: pfsync 452 21:26:15.429063 IP mail.yashy.com 0.0.0.0: pfsync 228 21:26:16.467022 IP mail.yashy.com 0.0.0.0: pfsync 452 21:26:17.712070 IP mail.yashy.com 0.0.0.0: pfsync 452 21:26:19.074030 IP mail.yashy.com 0.0.0.0: pfsync 452 21:26:20.433105 IP mail.yashy.com 0.0.0.0: pfsync 228 So I can see the requests going out on rl0 (but getting no reply), but it's not showing up on tun0/hme0 at all. I'm running bind on the fw/gw machine as well, so that is why the client is able to resolve www.fark.com (which makes me wonder why it's querying dns.pppoe.ca as I'm not trying to resolve anything that shouldn't be in the dns cache already..). Are all of these pfsync logs to 0.0.0.0 normal? if you have no pfsync interfaces 'UP'/configured, i would think not. i tried one and it doesn't send pfsync packets until i give it a 'syncdev'. i don't know if things are different at all in freebsd, but using/enabling pfsync is definately not compulsory. i'd guess/hope it wasn't much different there. On this linux client: $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.100.0.0.0 UG0 0 0 eth0 does it matter in your case that the netmask is a /24 there but a /28 in your nat line above? nah.. probably not if the linux host is .10 or .8? that 'gateway 0.0.0.0' thing confuses the hell out of me. i see it on the machines at work and always need the linux guys to explain to me the output of the routing table while i bitch about route(8) not working or making sense to me :( From the client machines, I'm getting an IP via dhcpd from the fw/gw. I can ping the fw/gw as well as ssh to it etc. If I ssh to the fw/gw, I can get out from it no problem. I just can't get through the fw/gw from the client machines. this might be slightly crackassed, but if you throw up a reject route on the firewall, do lan clients get an appropriate unreachable when trying to talk to it? eg: [firewall] $ sudo route add -host 86.75.30.9 $default_gateway -reject when i do
Re: Performance problems with queueing
On Sat, Apr 29, 2006 at 09:49:18AM +, Michal Soltys wrote:
But
If I change altq line and set bandwidth to something smaller - like 10Mb
- problems show up. Throughput on ftp drops brutally to around 150 - 250 Kb
Also if I use for example cbq in the following way (regardless if
bandwidth is or isn't explicitely set, and to what value):
altq on $int_if bandwidth whatever cbq queue {std, ftp, pri, ack}
queue std bandwidth 2Mb priority 1 cbq(default)
queue ftp bandwidth 4Mb priority 2 cbq
queue pri bandwidth 2Mb priority 3 cbq
queue ack bandwidth 2Mb priority 4 cbq
Transfers on ftp are around the same - 150 - 250 Kb, instead of what
they should be - around 4 Mb
just to be clear, you're definately not confusing b with B, right?
eg, when altq/cbq is 4Mb, 'pfctl -vvsq' is saying Kb/s and not Mb/s ?
not to say it is the cause, but in the case of testing/debugging cbq,
i'd suggest tossing the priority lines. let them all rock the default of '1'.
after you're done and things work as you want, sure, put them back in
on the 'pri' queue, or all of them if you fancy.
if i setup the following queues (i have HFSC in my ruleset normally,
naming them like this allowed me to not disturb the rest of my rules) :
---
altq on $e cbq bandwidth 100Mb queue {q-nfs q-yp q-smb q-bulk q-ack}
queue q-nfs bandwidth 2Mb cbq
queue q-yp bandwidth 4Mb cbq
queue q-smb bandwidth 2Mb cbq
queue q-bulkbandwidth 2Mb cbq(default)
queue q-ack bandwidth 2Mb cbq
---
and then add the following to bottom of pf.conf
---
pass on $e inet proto tcp from any to $TESTHOST port keep state queue(
q-yp q-ack )
---
and then do a 'nc -l /dev/zero' on the test-host, and 'nc $TESTHOST
/dev/null'
from another machine on the LAN, i see (take note of the bytecount to tell
you how long
it ran) :
---
queue root_fxp0 bandwidth 100Mb priority 0 cbq( wrr root ) {q-nfs, q-yp, q-smb,
q-bulk, q-ack}
[ pkts: 39135 bytes: 57231354 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 294.5 packets/s, 3.46Mb/s ]
queue q-nfs bandwidth 2Mb
[ pkts: 2 bytes:872 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 0.0 packets/s, 9.24 b/s ]
queue q-yp bandwidth 4Mb
[ pkts: 38623 bytes: 57125390 dropped pkts: 0 bytes: 0 ]
[ qlength: 9/ 50 borrows: 0 suspends: 11443 ]
[ measured: 291.8 packets/s, 3.45Mb/s ]
queue q-smb bandwidth 2Mb
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 0.0 packets/s, 0 b/s ]
queue q-bulk bandwidth 2Mb cbq( default )
[ pkts:509 bytes: 105014 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 2.8 packets/s, 4.95Kb/s ]
queue q-ack bandwidth 2Mb
[ pkts: 1 bytes: 78 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 0.0 packets/s, 0.83 b/s ]
---
tested changing altq bw to 12Mb, still OK:
---
queue root_fxp0 bandwidth 12Mb priority 0 cbq( wrr root ) {q-nfs, q-yp, q-smb,
q-bulk, q-ack}
[ pkts: 47780 bytes: 69563473 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 300.4 packets/s, 3.51Mb/s ]
...
queue q-yp bandwidth 4Mb
[ pkts: 41537 bytes: 61442702 dropped pkts: 0 bytes: 0 ]
[ qlength: 10/ 50 borrows: 0 suspends: 12342 ]
[ measured: 293.7 packets/s, 3.48Mb/s ]
---
added '(borrow)' to 'q-yp's cbq parameter:
---
queue root_fxp0 bandwidth 12Mb priority 0 cbq( wrr root ) {q-nfs, q-yp, q-smb,
q-bulk, q-ack}
[ pkts: 46407 bytes: 68365421 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 747.3 packets/s, 8.81Mb/s ]
...
queue q-yp bandwidth 4Mb cbq( borrow )
[ pkts: 46171 bytes: 68317896 dropped pkts: 0 bytes: 0 ]
[ qlength: 3/ 50 borrows: 45802 suspends: 0 ]
[ measured: 743.7 packets/s, 8.80Mb/s ]
---
$TESTHOST is a ppro/200 with not much using it.
if you don't have the luxury of using another unix host for
the test ( i find the netcat method to be delightful when testing/debugging
altq ), you might be able to get away with opening up chargen in
inetd.conf on the obsd host and then just telnetting to it from the
windows machine. as long as your telnet client doesn't suck eggs,
you should be able to get a not-terribly-bad rendition of the
netcat /dev/zero||/dev/null stuff.
use that to make sure you have your queues setup right and believe
your config -- then move over to seeing how the real client app
behaves and twiddle as needed.
hth
--
jared
[
Re: PF inadequacy: queue download
On Sat, Apr 29, 2006 at 05:10:40PM +0200, Stanislaw Halik wrote: I can speak for myself - I can't afford both the hardware and the electricity bill for a separate machine. Maybe downstream limiting isn't very robust, but IMO is the biggest thing pf/altq lacks. i queue the incoming downstream on the outbound-towards-my-LAN side. works just as good as it possibly could if pf had a download queue mechanism, if not better. if you are in a colo situation and you can't afford a little soekris ( or somethin' ) to drop in between and do this -- well... kudos on finding so inexpensive a colo that you can afford that but not a little 1 time ~250 USD or so for the investment on soekris/whatever -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
Re: PF inadequacy: queue download
[EMAIL PROTECTED] wrote: works just as good as it possibly could if pf had a download queue mechanism, if not better. This works adequetly (How could it be better? Sounds like zealot speak to me. to answer that, i believe there's no room for discussion there, then. if the boxes only function is NAT, but if it also runs external services queueing inbound traffic if the machine's only function is NAT it does not run external services. if i have an external service which i want to have jurisdiction over the input traffic on, i run it behind the LAN side. if i have an external service that i don't care about getting download traffic control over, i run it where it makes the most sense to me. perhaps you don't have the same liberty of convenience. -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
Re: IP alias with OpenBSD
On Mon, May 01, 2006 at 05:55:42AM -0700, Gnat wrote:
I need some help on setting up IP aliasing with NAT. The need is to
create static NAT entries for some users due to a limit of 4 sessions
per Public IP Address for a VPN server. I have 5 addresses from my ISP
and wanted to use these to get around this 4 sessions per WAN IP. Any
examples would be greatly appreciated.
did you try something based on:
ext=fxp0
int=fxp1
my5addrs=1.2.0.1 1.2.0.2 1.2.0.3 1.2.0.4 1.2.0.5
nat on $ext - { $my5addrs }
i've never dealt personally with multiple egress IPs, but that
syntax passes the parser
--
jared
[ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
Re: OpenBGPD PF
On Thu, Jan 05, 2006 at 01:33:42PM +0059, Claudio Jeker wrote: On Thu, Jan 05, 2006 at 06:46:54AM -0500, jared r r spiegel wrote: bgpd has (should have?) enough info from its config to know if it should send an addr_remove (i think this is the one) to pf based upon what addr it is thinking about removing, what table it is removing it from, and whether another peer who writes to that table has already put that addr in the same pftable - but the actual behaviour might be hard to get Just Right. The main problem with the using one pftable over mutliple sessions is that bgpd does not track what is added or removed. The idea is to dump all prefixes of a neighbor into one table. In the end the pf table and the routes of that neighbor are in sync. If you are using multiple neighbors as source for a table it is easy to get out of sync. What I'm wondering is why to use a pftable in that case. It is far easier to use a route label and let pf decide on the route label. The route label tracks the current active routes and so never gets out of sync. Instead of pass in from IX ... you can use pass in from route IX btw, this works like a dream lately. we *do* get messages to ring buffer of: -- invalid address type: 4 -- whenever pf parses one of the route rules in pf.conf (one host is 3.8 stable, one is 3.9-current from mar.19). that isn't causing issues for us and i am thinking it might be my fault for not having a nuance right somewhere. primarily my purpose in replying to this thread is to say that for anyone using pftables in pf/bgpd like i was using them, switch to route labels. it makes your life easier. -- jared [ openbsd 3.9-current GENERIC ( mar 15 ) // i386 ]
Re: OT: VPN + default route - how?
On Sun, Feb 12, 2006 at 01:43:45AM -0600, Travis H. wrote: I got a VPN set up but I'm wondering how to make all traffic go over the VPN to the remote end, which is a gateway to the internet. If I mess with my default route, my traffic stops flowing at all. if you want all traffic to go to the VPN peer instead of to the normal gateway, you will (most likely) need to change your default route. it would've been good in this case to have posted the output of your routing tables prior to the 'messing' and then after, which could've shown why things didn't work. 'route change' seems a bit harder to use than deleting and then readding a route with the differences in place, but it could be that i misunderstand the intent of route change. anyway, since it's all guesses as to what your setup is, i'll guess that your (usual) default gateway is on the same subnet as your external iface, and that your VPN peer is not on the same subnet. in that case i would set the destination for my default route to be the tunnel (assuming you're using tunnel) IP of the remote host, and then a regular host route with a destination of that VPN peer's regular IP and a gateway of what your default gateway originally was. Related to this, what is the normal way of setting up static routes? $ sudo route add -- jared [ openbsd 3.9-beta GENERIC ( jan 30 ) // i386 ]
Re: ssh bruteforce attempts and timeout of table w/ persist keyword
Tr0go wrote: table bruteforce persist ... BUT, surprisingly at some time the table self cleaned nahh, you reloaded pf :) that's how this happens to everyone i've run across, myself included. persist keyword should keep all those enemys' IP until next reboot, isn'it ? no. you are not the first one to think 'persist' means 'immutable no matter what'. that bit me in the ass a few times. all 'persist' does is makes that table stay populated even if there is no rule that makes reference to the table. it's pretty clear when you go back and read the manpage... :/ in my case, i had read about 'persist', put it in as a rule of thumb, and not had to worry about it; since i never really needed to use it for its intended purpose, i believe my perception of the meaning of 'persist' mutated to be what i wanted it to really mean; which is what you thought up there too.. so far, i've seen people populate tables from a file which they write to however often to keep it up to date, and i've seen people write 'reload-pf' scripts who take certain tables, copy the contents out to $WHATEVER, reload the ruleset, and then repopulate the tables after the pfctl -f is done. -- jared [ openbsd 3.9-beta GENERIC ( jan 30 ) // i386 ]
Re: UDP to port 0
On Sat, Feb 04, 2006 at 12:59:41AM +0100, Jonas Davidsson wrote: Pf does not seem to allow UDP packets destined for port 0 out, TCP packets to the same port pass without problems. If nothing else, this breaks nmaps os-detection mode. with 'pass quick on em0' [send_ip] sendto: No route to host with 'set skip on em0': ICMP Port Unreachable from ip=192.168.1.10 Is this intentional and if so, why? there are a couple 'uh.uh_dport == 0' tests in net/pf.c as to why? a little googling around and the most appropriate post i could find was a netbsd post from itojun [1] in which he asks about the behaviour of dest port 0 being interpreted as undefined. don't know if this is a good match for the reason, but it seems plausible. might find some info in libsa/net.c too, but it's a bit too rich for my blood in there. [1] - http://mail-index.netbsd.org/tech-net/2000/01/08/.html -- jared [ openbsd 3.9-beta GENERIC ( jan 30 ) // i386 ]
Re: OpenBGPD PF
On Thu, Jan 05, 2006 at 03:18:22AM +0100, Sylwester S. Biernacki wrote:
On Thursday, January 5, 2006, at 01:15:00, jared r r spiegel wrote:
- establish session with A and learn about 1.2.3.4/30; 1.2.3.4/30 is
written to pftable IX
- establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is
written to pftable IX, but it's already there, who cares; or maybe
it isn't written because it's already there
either way, pftable IX still has 1.2.3.4/30 in it.
In both cases
above no prefixes shouldn't deleted from pftable IX
nod was just additions up to that point
- A loses its route for 1.2.3.4/30 and thus you lose it out of the
session.
with A, bgpd removes 1.2.3.4/30 from pftable IX
it's still valid via B, but it got removed when A lost it.
It may be - however command to remove prefix from pftable comes from
bgpd not pf, right ?
i think so; pftable.c (bgpd) has ioctl functions that seem to be named
such that they imply they do just what i think they would G.
bgpd has (should have?) enough info from its config
to know if it should send an addr_remove (i think this is the one)
to pf based upon what addr it is thinking about removing, what table
it is removing it from, and whether another peer who writes to that table
has already put that addr in the same pftable - but the actual behaviour
might be hard to get Just Right.
i use a unique pftable per BGP peer ( and then just reference
each table in my pf rules in { braces } ) to avoid that
well... who knows the limit of rules in { braces } ? If you peer in IX
where you have ~50 peerings that's not a hard work to do it, but what
about 150 peerings (without route-servers) or more ?
might not make as big an impact as you could be thinking; as they
just expand to individual rules:
$ unset RULES
$ RULES=$RULES\ntable first persist { 1.2.3.4/30 }
$ RULES=$RULES\ntable second persist { 2.2.3.1/32 }
$ RULES=$RULES\npass on lo0 inet from { first second } to any
$ echo $RULES | pfctl -nvf-
table first persist { 1.2.3.4/30 }
table second persist { 2.2.3.1 }
pass on lo0 inet from first to any
pass on lo0 inet from second to any
$
my first reaction is that anything you're going to run BGP/pf on
in a ~50-~150+ scenario isn't going to care about whether pf.conf
works out to be 20 lines or 20,000 ( well, maybe 20,000 you'd notice
a little effect :).
could be this is fixed already and one of my peers is an old version?
( 3.8 stable; 3.8 current dec.16; 3.8 current from oct.2 )
I've already checked that and it seems to have this behaviour on all
peerings, no matter if there is Cisco IOS, JunOS, Quagga or OpenBGPD,
so that's not that case.
i was probably unclear; sorry about that. i don't believe the nature
of the BGP process i'm peering with has anything to do with the cause;
but rather that i see that behaviour across each of the hosts of those
different revisions, so they all use the 'unique bgp table' method.
--
jared
[ openbsd 3.8 GENERIC ( dec 16 ) // i386 ]
Re: OpenBGPD PF
On Wed, Jan 04, 2006 at 09:42:44PM +0100, Sylwester S. Biernacki wrote:
What do you think about it? Any ideas what to look for?
one - if you are reloading pf ( pfctl -f /etc/pf.conf ), that will
clear the table; but that's probably not your issue.
two - if you have two peers, A and B, and both of them write to the
same pf table IX, i believe the following scenario is true:
- establish session with A and learn about 1.2.3.4/30; 1.2.3.4/30 is
written to pftable IX
- establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is
written to pftable IX, but it's already there, who cares; or maybe
it isn't written because it's already there
either way, pftable IX still has 1.2.3.4/30 in it.
- A loses its route for 1.2.3.4/30 and thus you lose it out of the session
with A, bgpd removes 1.2.3.4/30 from pftable IX
it's still valid via B, but it got removed when A lost it.
i use a unique pftable per BGP peer ( and then just reference
each table in my pf rules in { braces } ) to avoid that
could be this is fixed already and one of my peers is an old version?
( 3.8 stable; 3.8 current dec.16; 3.8 current from oct.2 )
--
jared
[ openbsd 3.8 GENERIC ( dec 16 ) // i386 ]
Re: inbound queueing question
On Fri, Dec 02, 2005 at 12:27:53AM +, Karl O. Pinc wrote:
I thought the queues were tied to the interfaces, so that, for
instance, queue on the LAN interface could not borrow bandwidth
from a queue on the DMZ interface. So then you either need to
partition your WAN bandwidth between the LAN and the DMZ, radically
reducing the total bandwidth available to either (as far as
the net is concerned), or you run the
risk of losing all your queueing when you fill the WAN link
because datagrams will get dropped on the far side of the WAN link.
altq is tied to an interface, and then queues are tied to altq;
as opposed to queues being tied to the interface directly
( i think )
we never got around to using this config, but as a test i made
the queueing section as:
---
# ALTQ
altq on $e cbq bandwidth $adsl_up queue { q_top q_hi q_med q_lo q_bt }
altq on $i cbq bandwidth $adsl_down queue { q_top q_hi q_med q_lo q_bt }
queue q_top bandwidth 10% priority 7 cbq(borrow)
queue q_hibandwidth 10% priority 5 cbq(borrow)
queue q_med bandwidth 10% priority 3 cbq(borrow default)
queue q_lobandwidth 10% priority 1 cbq(borrow)
queue q_btbandwidth 10% priority 0 cbq(borrow)
---
and it parses OK. ( pretty much each rule in the conf that can
have a queue declaration does, after that point ).
still would be interested to see that in practice, but the machine
we're planning on doing that config on hasn't been cut over
to openbsd yet
--
jared
[ openbsd 3.8 GENERIC ( oct 30 ) // i386 ]
Re: Problem with altq cbq queuing.. please assist?
Queuing doesn't make sense inbound anyway; once you've received the packet, it has already consumed your bandwidth, and thus queuing won't change anything. queueing could delay ACK reply being sent and then whole connection would get throttled. it works really fine with freebsd's ipfw, i had no problems regarding queueing incoming packets. What you propose can be compared to repetitively telling a ADHD child to behave, or try to ignore him. Either way, your fucked. If he does listen to you however, he probably don't have ADHD. Good for you. ;) As long as you don't control the the remote host, or a router close to it, you have no real control over the bandwidth throttling from that host to your gateway(or whatever). be careful to distinguish between two situations. 1) maliciously sent incoming data meant to flood your connection 2) non-malicious incoming data that is part of a stream destined for a LAN host behind the firewall. inbound queueing has no jurisdiction over situation 1, but it *does* create the potential for usefulness in situation 2. if you are throttling the rate at which data is forwarded back to a host behind the firewall, you can provide benefit to yourself; i do this to make it very unlikely that LAN hosts consume my entire downstream ( from ISP ) bandwidth capacity. if i'm eating all my download, my latency goes from ~11ms between me and my default gateway to about 400-600ms. -- jared [ openbsd 3.8 GENERIC ( oct 15 ) // i386 ]
Re: no scrub reassemble tcp from foo to bar
On Tue, Oct 18, 2005 at 11:50:41AM -0400, Jon Hart wrote: What I'd like is to disable scrub's tcp reassembly on per host/port/protol basis, something along the lines of: scrub all no-df random-id fragment reassemble reassemble tcp no scrub inet proto tcp from any to $SAN_NET port 3260 reassemble tcp I'll bring up a test system to see if this is possible, but my question is will this get me what I want? I want to do full scrubbing on all of my traffic except I don't want to do tcp reassembly on port 3260/tcp for a specific host. flip the order, no scrub first (normalization is like translation, first match). other than that, looks fine. -- jared [ openbsd 3.8 GENERIC ( oct 15 ) // i386 ]
Re: optimizing pf firewall
On Thu, Oct 06, 2005 at 03:48:17PM -0400, Dave wrote:
My second problem, i'm trying to do mpd vpn, which relies on gre. I've
got a natted vpn server at 192.168.1.3 but when an external connection
happens, that is one outside my firewall from a windows box i get an error
619, which after googling and asking, have determined that gre isn't
natting to the box. Does anyone have this working?
1)
meaning is anyone successfully natting on gre iface?
i am.
in order to allow BGP to function over the VPN group i'm in, we've
setup gre ifaces that ride on the IPsec tunnel. IPsec establishes
ESP flows from one /32 to another, and then we put the GRE ifaces
riding on those /32s ( the GREs have their own /32s also ). then
we run BGP peering between those GRE /32s, and advertise the normal
lan subnets.
on my endpoint, i run nat on the GRE iface if the destination is
an IP i've learned via BGP, and the source is the IP of the
GRE iface in question, rewriting the source to be the IP of the LAN
iface of the endpoint.
---
i = sis0
table HK4801VPN persist { 172.17.7.0/24 172.18.7.0/24 }
table bgp_p54c persist { }
table bgp_ub3rgeek persist { }
table bgp_commodore persist { }
nat on gre inet from HK4801VPN to { bgp_p54c bgp_ub3rgeek bgp_commodore
} - ($i:0)
---
those bgp tables are populated with 'set pftable blahblah' in bgpd.conf; i use
a different table for each peer (even tho they ultimately usually have
the same IPs in them) after noticing that if peer A has a valid route to subnet
X,
populates the table, and then peerB has a valid route to subnet X, but then
loses
the route to subnet X, bgpd removes subnet X from the table regardless of
whether
peer A has a valid route to it or not.
without this nat line, traffic leaves my endpoint's gre iface as being from the
172.1[78].7.???
IP of the gre iface, if destined for any host in a remote subnet; which is not
necessarily chill since only the actual VPN endpoints should be using those IPs
( per our policy ). a default route on a remote LAN host would work if it also
happens to point to that remote subnet's endpoint, but it's crappy because of
having to put more IPs in more configs.
anyway , that's all probably unrelated to your scenario
or
2)
you say 'gre isn't natting to the box', so do you mean that outgoing traffic
is not having its source address rewritten, or that incoming is not having
its destination address rewritten? literally, those are both translating
network addresses, but in the scope of pf, nat==outgoing, rdr==incoming.
is the gre iface actually on the obsdbox, or are the gre-proto packets
supposed to traverse the bsd box and be decapsulated by the host on the LAN ?
if the latter, i think maybe you will be successful with either a
rdr or binat ( binat groks proto and src/dest addrs, just not ports )
jared
--
[ openbsd 3.8 GENERIC ( sep 27 ) // i386 ]
Re: Trouble with 2-digit carp interfaces
On Wed, Oct 05, 2005 at 02:23:29PM -0700, Zack Lawson wrote: As soon as I add a carp interface with more than one digit (ie carp10, carp11 or carp23), the backup host (with the higher advskew value) starts switching between MASTER and BACKUP on seemingly random carp interfaces. The fact that I have two firewalls fighting over master status on public NAT'd IP's represents a clear problem. The IP's related to the carp interfaces become completely inaccessible. maximally, i have 4 carp ifaces and a few other interfaces with multiple digits and they're working OK, fwiw. sep 27 snapshots: 4801a $ ifconfig | grep ^[^[:blank:]] lo0: flags=8149UP,LOOPBACK,RUNNING,PROMISC,MULTICAST mtu 33224 sis0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 sis1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 sis2: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=0 mtu 1348 enc0: flags=41UP,RUNNING mtu 1536 gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280 gre70129: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1450 gre70196: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1380 gre70222: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1380 gre7024: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1476 gre704: flags=9011UP,POINTOPOINT,LINK0,MULTICAST mtu 1476 carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 carp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 carp21: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 carp22: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 jared -- [ openbsd 3.8 GENERIC ( sep 27 ) // i386 ]
Re: PF - problem with NAT policy based rules
On Fri, Sep 23, 2005 at 03:00:12PM -0400, Chad M Stewart wrote:
nat on $ext_if tagged LAN_INET tag LAN_INET_NAT - ($ext_if)
The problem is that pfctl complains about a syntax problem with that
line.
[/home/jrrs] $ echo nat on em0 tagged 1 tag 2 - (em0) | pfctl -nvf-
stdin:1: syntax error
[/home/jrrs] $ echo nat on em0 tag 2 tagged 1 - (em0) | pfctl -nvf-
nat on em0 all tag 2 tagged 1 - (em0) round-robin
seems consistent with:
--[pf.conf(5)]--
nat-rule = [ no ] nat [ pass [ log [ ( logopts ) ] ] ]
[ on ifspec ] [ af ]
[ protospec ] hosts [ tag string ] [ tagged string ]
[ - ( redirhost | { redirhost-list } )
[ portspec ] [ pooltype ] [ static-port ] ]
---
jared
--
[ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
Re: VPN hfsc
On Wed, Sep 14, 2005 at 01:26:12PM -0400, Brandon Mercer wrote: What I was figuring is that I need to shape the general bandwidth on the interface, i.e. give the VPN say 512Kb/512Kb and if that isn't in use let it be used by the other services that will be connecting to that interface. Then within the VPN I need to allow 72Kb per phone, but give that bandwidth back up when it's not in use. And I have to prioritize packets... so probably use hfsc. what comes to mind intially, is to take the real outgoing external iface, and setup queues on that such that there is one queue who will be used for outgoing esp, and then a queue used for outgoing everything-else. create children of the everything-else queue for your cleartext traffic as needed (eg, if you wanted simple basic ACK prio, make two of them under the everything-else queue) queue all outbound esp on the external iface equally. then setup altq on enc0 for the queue in the VPN stuff, with an altq bandwidth equal to the same size you set up for the esp-only queue on the external iface. for all the queues on enc0, set those up as you want for the VPN queueing and just run from there. i'm thinking that traffic will come in, be queued out enc0 per the 'altq on enc0' into esp. that stream of esp is already interiorly queued as it goes out the external iface, and then as encapsulated esp, has to obey the rules of the vpn only queue on the external. then, of course, make sure you don't prioritize traffic on the external such that the cleartext stuff ends up beating out the VPN-only traffic and mooting the queueing you did on enc0, relative to the big picture. if that's consistent with how altq/pf works wrt to the enc0 and actual interfaces, it would seem to be just a matter of imagining up how to divvy the queues. jared - [ openbsd 3.7 GENERIC ( sep 1 ) // i386 ]
Re: IP accounting
On Sat, Sep 03, 2005 at 09:48:16PM -0400, Peter Matulis wrote: ipfm does not seem to be maintained anymore (since 2002). one thing that sometimes works, for your own use, is to find a newer release (distfile wise, from the main project page), bump that up in the makefile, do a make fetch, make makesum, and then see if it builds/works. doesn't look like ipfm has a patches/ dir, so that might not stand in your way. My next stop is symon. i think the closest granularity you'll be able to get with symon is that it can monitor individual altq queues now (symon v2.71). otherwise, i think of labels on rules and pfctl -vsl. you could make a process to dump those into rrd files based on label name. jared - [ openbsd 3.7 GENERIC ( aug 29 ) // i386 ]
Re: setting source ip on multiple aliases
On Tue, Aug 02, 2005 at 11:34:55PM -0500, Kevin wrote: You can solve this by using tags: nat on $ext_if inet from any to any tagged aramith - 69.13.34.94 . . . pass out from any to any user aramith tag aramith please remember to specify tcp/udp when doing 'user' or 'group'. unless the behaviour has changed (which i admit, maybe it has), this rule (^pass out.*) can/should be considered to be equivalent to the following 5 rules: pass out inet all keep state tag aramith block out inet proto tcp all block out inet proto udp all pass out inet proto tcp all user aramith keep state tag aramith pass out inet proto udp all user aramith keep state tag aramith manpage still has: --- Only TCP and UDP packets can be associated with users; for other protocols these parameters are ignored. --- looks like some time betwen jun.25 and jul.12 things changed such that one doesn't need to explicity say 'keep state' to tag something. jared - [ openbsd 3.7 GENERIC ( jul 12 ) // i386 ]
Re: ftp-proxy vs. ftpsesame
On Mon, Jul 18, 2005 at 12:10:41PM -0400, Daniel T. Staal wrote: I'm not to interested in exact rules at this point; I can figure those out. I'm just looking for what people think is the best way to use the tools to do the job: least ports opened, least hassle, least resources, etc. From a scan of the man pages, ftpsesame looks to be able to handle just about everything except active client connections, and ftp-proxy seems to be able to handle everything major, but requires a lot of ports open. as far as Just Work, i'ven't had any issues with ftp-proxy over the past years. i use just two rules in pf.conf (one for the rdr, the other because i don't rdr pass). the 'pass on...' rule is specific to 'inet proto tcp blahblah user proxy'. i use '-M' and '-m' to limit the range of ports that the proxy will attempt to use, but in actuality that doesn't provide me much value, so i'm going to get rid of that after i send this out (was one of those things i twiddled early on because i thought i had some reason to do it)... i also use '-n'. active and passive both work. took me a little bit to digest the practical meaning of '-n', and i didn't know of ftpseasame prior to getting ftp-proxy to work. ftpseasame has come up several times on the lists, but in my topology, if don't have any compelling reason to convert from a util in base to a util in ports, it's easier to just leave good-enough alone. one less thing to worry about. jared - [ openbsd 3.7 GENERIC ( jun 25 ) // i386 ]
Re: ALTQ on PF for gaming
On Tue, Jun 28, 2005 at 04:52:17PM +0100, Bob wrote: I thought the problem was that you needed to limit incoming traffic as well as outgoing traffic. i've found that limiting incoming data by queueing on the internal LAN-facing interface can be very beneficial if configured correctly. for instance, RTT to my default gateway is normally 12ms. the highest download bandwidth i can realize is roughly 2650 Kb/s. if i am downloading without queueing incoming, pings to the gateway under full-tilt download hover at around 500-700ms. if i set pf to queue incoming at an altq bandwidth of around 2500 Kb/s, i do not find that i lose much in the way of potential download throughput, however under a full-tilt download, the RTT only goes to about 180-300. cutting the altq bandwidth down to about 2400 brings that down further, yielding around a 40-60ms RTT. in a situation where one is trying to use queueing to achieve a high- quality RTT across the circuit to your ISP, queueing on incoming data also could be a very important factor. naturally, a hidden factor would be whether there is a bandwidth shortage leaving the DSLAM/HeadEnd you terminate at, or any other bandwidth shortages further up the food-chain as you traverse your ISPs network. ( eg - if you are provisioned at 3Mb, but there are only a 2 T1s leaving the remote unit, and there are 40 other people on there, it is probably a good idea to be a bit more conservative... in any case, one could run pings to whatever hop on the ISP's network is most applicable, graph them (or whatever) and look. spend a day or two without being involved in large data transfers ) jared - [ openbsd 3.7 GENERIC ( jun 25 ) // i386 ]
Re: Keep state + bridge weirdness
On Jun 6, 2005, at 9:27 AM, Jason Dixon wrote: .. Try the following rule: pass on rl0 keep state i've a limited experience with a bridge so far, but what about, say: --bridgename.bridge0-- add rl0 add rl1 rule pass in on rl0 tag rl0 rule pass in on rl1 tag rl1 up -- --pf.conf-- pass out tagged rl0 keep state --- which would essentially create a state entry based on the packet leaving rl1. a friend of mine setup a bridge recently, and we had increased success by tagging in on each component iface with a unique tag, and then keeping pf.conf only concerned with tags and not concerned with 'on iface' anythings. jared - [ openbsd 3.7 GENERIC ( may 29 ) // i386 ]
Re: Need help in per user basis bandwidth sharing
On Thu, May 26, 2005 at 09:09:59AM +0200, Peter N. M. Hansteen wrote:
Porkodi [EMAIL PROTECTED] writes:
Please help me in per user basis bandwidth sharing.
Is there any way in pf with altq?
authpf with per user rules which assign the user's traffic to queues
should be possible.
the authpf idea is very slick for when the users are not local
to the machine (as otherwise the user is 'unknown').
if you're trying to do it for users who actually are logged into
the machine, something like:
--
e = fxp0
altq on $e hfsc bandwidth 100Kb queue{ 1000 1001 1002 }
queue 1000 on $e bandwidth 20% priority 6 hfsc( upperlimit
100Kb )
queue 1001 on $e bandwidth 20% priority 1 hfsc( upperlimit
100Kb default )
queue 1002 on $e bandwidth 20% priority 0 hfsc( upperlimit
100Kb )
pass on $e inet proto {tcp udp} all user 1000 keep state queue 1000
pass on $e inet proto {tcp udp} all user 1001 keep state queue 1001
pass on $e inet proto {tcp udp} all user 1002 keep state queue 1002
--
would work. ( in that context, the hfsc is really kinda like priq,
i believe )
you can't effectively use a macro for this as macros do not expand
when used for a queue declaration, and if you put two macros on a line
you get AA AB BA BB and not just AA BB.
if you want to queue both for users on the local machine and authpf
users, you can do a combination.
on the home LAN, i do a similar thing on a per-LANhost basis.
the ruleset is not terribly long due a cute way of using a shitload
of tags and macros with the $srcaddr $dstaddr stuff.
eg, pftop looks like this on the external iface in the queue view:
---
QUEUE
root_fxp0
exthi
extlo
extLAN
u192.168.7.X
u192.168.7.Xd
u192.168.7.Xa
u192.168.7.1
u192.168.7.1d
u192.168.7.1a
u192.168.7.2
u192.168.7.2d
u192.168.7.2a
u192.168.7.17
u192.168.7.17d
u192.168.7.17a
u192.168.7.18
u192.168.7.18d
u192.168.7.18a
u192.168.7.19
u192.168.7.19d
u192.168.7.19a
---
where i make a queue for each host i care about and then
a catch-all queue ( the X ones ) for hosts i lump together.
( each host gets data/ack prioritized in its own subqueues,
the queues are all HFSC. )
you could hit the max queue declaration pretty quick, if you
try to get real complex; but if you just do it per host like
that, but without data/ack prio you'll probably be fine for
most home-use cases.
jared
--
[ openbsd 3.7 GENERIC ( may 17 ) // i386 ]
Re: pfctl_altq.c ,realtime 80%
On Wed, May 04, 2005 at 07:42:17PM +0200, DarkT wrote:
altq on $iface hfsc bandwidth 1Mb queue { 1 2 3 }
queue 1 hfsc(default realtime 50Kb linkshare 100Kb upperlimit 100Kb)
queue 2 hfsc( realtime 300Kb linkshare 400Kb upperlimit 400Kb )
queue 3 hfsc( realtime 400Kb linkshare 500Kb upperlimit 500Kb ) { 3a 3b }
queue 3a hfsc( realtime 150Kb linkshare 250Kb upperlimit 300Kb)
queue 3b hfsc( realtime 150Kb linkshare 250Kb upperlimit 300Kb)
this is only example :)
now the important thing, if you pfctl it it says that realtime is over 80%
of Iface bandwidth and get error , but it is real exceded ? ,the
childrens are in parent 3 so shouldn`t admission control function dont sum
them as already
summed parent queue ? i think it summ all queues on iface and dont check
if it is parent or childrens of some parent.
i believe the realtimes of child queues don't get nested/encapsulated/
recursed within the realtime of their parent, but rather that the
realtimes are considered flat against the interface? (or maybe
the child queues are added to the parent for realtime?)
not really sure if that came out right, but if i change
your 'queue 3' to have a realtime of 350Kb, the parse error
about 80% goes away; or if i change 3a and 3b to have a realtime
that adds up to = 15%, but leave queue 3 at 400Kb, it goes away too.
jared
btw, i think you still might need to specify a bandwidth on
each HFSC queue line, even if it is much less than what is
going to really be there (don't go stupidly small, but like
(100/# of queues)-(10% of iface bw) might be reasonableish
--
[ openbsd 3.7 GENERIC ( apr 27 ) // i386 ]
Re: explanation of blocked packets
On Wed, Mar 30, 2005 at 09:51:07PM -0500, [EMAIL PROTECTED] wrote: Why are the following packets being blocked? I know that I have flags S/SA modulate state, and that F or FP do not match S/SA, but does that matter since its in state? if you didn't get to solve this yet, is it perhaps a situation where they're being blocked outside the window of when the state was torn down? like, after the first(?) FIN or RST are seen, and the state gets torn down, and then more packets get sent over the wire which are/were part of that connection, but pf has torn it down by that point? i know i'm explaining it poorly; , what if you set optimization to conservative?, if it doesn't happen then, that's what i'm trying to say. jared -- [ openbsd 3.7 GENERIC ( mar 18 ) // i386 ]
Re: Good HFSC explanation
On Fri, Feb 11, 2005 at 15:39 +, Bob wrote: Preferably that apply directly to PF which uses three SC types, not two. meaning also using an sc on the upperlimit directive? i'm still just using upperlimit as a hard number, and not using a curve for that. On Wed, Feb 16, 2005 at 01:01:44AM +0300, Mike Belopuhov wrote: Search the archives of this list for ``Specific HFSC questions'' thread. Jared did a lot of work, thanks. trevor talbot has helpful clarifications throughout the archives too. -- [ openbsd 3.6 GENERIC ( jan 13 ) // i386 ]
Re: Can't even do an ls on a FTP server located on the WAN
On Wed, Feb 16, 2005 at 08:41:57AM +0100, Nicolas wrote: [FTP CLIENT]--[DEBIAN]--[OBSD BASTION]-WAN[FTP SERVER] The Debian machine does ftp masquerading, but I don't see anything anormal on that machine. The error message on the bastion, in /var/log/daemon, is: ftp-proxy[18326]: connect() failed (No route to host) What host is that? From the bastion, there're no problem at all with routes to the Debian machine or the FTP server... don't know what host the destination was, but source was certainly [OBSD BASTION], so should be on the pflog on the bastion machine. could watch a tcpdump on the pflog0 iface while you try again and duplicate a failure; should show the blocked addr/port pair that ends up being reported to /var/log/daemon. -- [ openbsd 3.6 GENERIC ( jan 13 ) // i386 ]
Re: Good HFSC explanation
On Fri, Feb 11, 2005 at 03:39:17PM +, Bob wrote: Is there a clear HFSC explanation somewhere, with real simple examples? Preferably that apply directly to PF which uses three SC types, not two. I've found plenty of documents, but they're all high-level overview slideshows that are a bit hard to fathom. i myself am still learning about HFSC, and experimenting, however if you search pf list archives for 'jared hfsc', you can see a lot of posts by me or in re: to me about HFSC. of note: http://marc.theaimsgroup.com/?l=openbsd-pfm=105691519510241w=2 http://marc.theaimsgroup.com/?l=openbsd-pfm=107936788832658w=2 http://marc.theaimsgroup.com/?l=openbsd-pfm=110488079304643w=2 jared -- [ openbsd 3.6 GENERIC ( jan 13 ) // i386 ]
Re: altq fishiness
On Thu, Feb 10, 2005 at 07:59:31PM +, Bob wrote: I couldn't get CBQ to use up all of the bandwidth. Even when only one queue had any traffic, the bandwidth was never getting saturated. ... Possibly (probably) it was something I was doing wrong. But I've changed to HFSC now, and my broadband line is saturated with traffic. So I'm happy. remove 'red' and see if it saturates the bandwidth of the queue. red is something i liked the sound of, but stopped using because i think i didn't understand fully its implications on a bandwidth-queue. afaict, if red is on a cbq(/hfsc?) queue which is designed as a bandwidth partition, the bandwidth consumed by the queue will never reach the cap, but will be reduced with some calculus asymptote lines or something as it approaches it. could be way wrong too - i'm going on my interpretation of the effect it had on queues as i watched/tested them. I have to admit, though, that I couldn't find any simple explanation of HFSC with regard to PF, so I had to guess my way through setting it up. hfsc has a very steep learning curve, but i believe that is partially its nature. for me it seems it demands you get your head around it, rather than trying to be a bit easier to understand and missing a bit of the picture. the crossbow site is excellent for this, but seems to take several reads through to sink in fully. jared -- [ openbsd 3.6 GENERIC ( jan 13 ) // i386 ]
Re: Can't even do an ls on a FTP server located on the WAN
On Tue, Feb 15, 2005 at 07:58:05PM +0100, Nicolas wrote: Post your pf.conf. Unfortunately, the floppy disk is broken on my bastion. Since the pf.conf is around 15ko, I'll avoid typing it... ;-) can you ftp/scp it off and just post on the www somewhere? that sometimes seems to fly for things very large. Feb 15 19:57:10.770100 rule 0/0(match): block in on ep0: 213.246.62.4.36105 192.168.14.26.113: S 3830247271:3830247271(0) win 5840 mss 1420,sackOK,timestamp[|tcp} (DF) Feb 15 19:57:13.768532 rule 0/0(match): block in on ep0: 213.246.62.4.36105 192.168.14.26.113: S 3830247271:3830247271(0) win 5840 mss 1420,sackOK,timestamp[|tcp] (DF) that looks like they're pulling an ident lookup on you. $ grep 113 /etc/services auth113/tcp authentication tap ident don't know offhand if that's where it is dying., given the timestamps, i don't think so, as they pull an indent on you upon the initial connection, not upon your LIST. Here's what appear on the screen, also: Feb 15 19:58:36 bastion ftp-proxy[28303]: connect() failed (No route to host) so if ftp-proxy can talk to 213.246.62.4:21 from 192.168.11.26... Here's what written in /var/log/daemon: Feb 15 19:57:10 bastion ftp-proxy[28303]: accepted connection from 192.168.11.26:34681 to 213.246.62.4:21 Feb 15 19:58:36 bastion ftp-proxy[28303] connect() failed (No route to host) i'm wondering why it is trying to make a connection out on a different socket pair? i'm thinking that however pf is setup, it is probably allowing out the first connection from ftp-proxy; that it is failing on that second part makes me wonder about what connection really was blocked; would have to be an outgoing one from ftp-proxy to somewhere. if it was incoming, and was blocked, ftp-proxy wouldn't know. try to see if there's something in the /var/log/pflog you skipped? Here's a line for ftp-proxy in /etc/inetd.conf: 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy frp-proxy -n -D 3 for active mode connections, you would need to allow in pf, say, 'from tcp remote ftp IP port 20 to $intIf:network user proxy'., but that rule is only for active connections, doesn't matter for passive. However, here's the rule I added for the FTP: pass in quick on $name_itf_ext inet proto tcp from port 20 to ($name_itf_ext) user proxy flags S/SA keep state ok, that's that.. are you blocking everything by default on bastion, not just inbound? is there a chance that the connection from ftp-proxy back to your LAN was blocked? jared -- [ openbsd 3.6 GENERIC ( jan 13 ) // i386 ]
Re: VPN client cannot connect through OpenBSD router/firewall
On Mon, Jan 17, 2005 at 02:48:07PM -0600, Rick Barter wrote: Michael Erdely wrote: You're doing a block all and then aren't allowing esp traffic out. Try adding the following with your tcp, udp and icmp pass out rules: pass out $log_flg on $ext_if proto esp all keep state When troubleshooting something like this, it may be useful to to add log to your default block rule so you'll at least see what's being dropped. Thank you very much for the advice. This worked like a charm. How did you know, or better yet, how could I have known that I needed to pass out the esp protocol? By seeing what was dropped? yup. by seeing what was dropped. i _always always always_ keep block return log all as the first real rule in my pf.conf. whether or not you want to return or drop is of course a matter of taste ( i do drop some things later in a more specific rule ), and whether or not you want to block all ifaces or not is a matter of taste too... for annoying things like crackwhores trying to hit my TCP:135 pipe and the like, i create specific non-log block rules for them so my pflog0 and /var/log/pflog actually contain useful data when i look at them. just as long as you avoid the bitch-out temptation of setting some 'pass quick all' rule right after that, you'll be on the quick way to solving things for yourself. as a sidebar, i succumbed to that very same bitch-out temptation just a bit ago and was completely confused why my pf was NOT blocking incoming UDP:500 from a friend of mine after he changed ISPs and thus had an IP which was not in my pf table of allowed VPN Gateways. my pass quick all log was shooting my entire rule logic in the face (stupid!). i won't claim to be captain pants of setting up pf in all cases, however i have no difficulty recalling many instances over the years of someone asking a question to pf@ which they would *not* have had to ask had they been logging their blocks ( eg - they come back 2w later and say oh, i'm dumbass, i was blocking that but didn't know ). log your blocks for chrissake all the time :P jared -- [ openbsd 3.6 GENERIC ( dec 11 ) // i386 ]
Re: Specific HFSC questions
On Mon, Jan 03, 2005 at 02:33:37PM -0800, John Ricardo wrote:
1. In general, where does priority count? Are priority values only
considered at a parent queue with respect to the child queues, or are
they considered at the root with respect to all the leaf queues, or...?
i am currently unsure myself how to extract much use out of priority,
and have stopped using it entirely.
perhaps it works best if _not_ combined with actual service curves,
but just flat bandwidth declarations -- but in that case it would
seem to me that you're kinda just doing cbq with a little bit of
finer granularity, rather than actually trying to get the most out of
hfsc?
i try to set good sc values, and as an experiment while on a
couple bittorrents ( each individual torrent had its own queue ),
i set the priority of one higher than the other and restarted them.
i didn't see any difference at all after the queues settled into
stride than when they were the same priority, but that is, i would
estimate, a fault of my configuration and not a fault of the mechanism.
2. Does realtime imply that the bandwidth specified is left unused
unless that queue sees packets, or is it simply a priority mechanism?
realtime is the bandwidth that each queue is absolutely guaranteed
to get in any circumstance where data is being queued into said queue
( ie - that queue is actively pumping data ). that might be an
inaccruate explanation technically, but it seems at least as a decent
mental-model foundation.
linkshare is each queue's ability to suck down extra bandwidth
from surplus after the active queues' realtimes have been satisfied.
upperlimit is the maximum bandwidth a queue can consume if there's
still bandwidth left over after satisfying linkshares.
i guess i am thinking of surplus as a condition where the amount
of data being queued is less than the sum of bandwidth expressed
by the culimation of all realtimes.
to directly answer your question, yes, the bandwidth specified is
unused unless the queue sees packets, and no, it is not *simply*
a priority mechansim - it is a guarantee-of-bandwidth mechanism which
can be setup to imply priority but doesn't necessarily have to always
mean priority.
if you have 4 queues, each split the same way for simplicity:
( i will also set flat non-curve service classes for simplicity )
---
altq on $e hfsc bandwidth 512Kb queue{ q-1 q-2 q-3 q-4 }
queue q-1 bandwidth 10% hfsc(default realtime 20% linkshare 10%
upperlimit 100%)
queue q-2 bandwidth 10% hfsc(realtime 20% linkshare 10% upperlimit 100%)
queue q-3 bandwidth 10% hfsc(realtime 20% linkshare 10% upperlimit 100%)
queue q-4 bandwidth 10% hfsc(realtime 20% linkshare 10% upperlimit 100%)
---
if at a specific moment, you only have data queued in q-2 and q-3, say,
and that's all that is happening, each one wil first satisfy itself
from the realtime allocation. that means they'll stake out 20% of
the bandwidth each ( total 40% ), and if after that has been allocated
to them, they look around and see surplus bandwidth ( the rest of the 60% ),
they will take their linkshare percentages also, and as long as nobody
else competes for linkshare, they will each try to approach 100%, which,
as they are set equally, provided the connection at the other end of
the transmissions are equal, they will ride along at about the same
usage %.
perhaps in this case if you set priority of one of them higher than the
other, you might see the higher priority queue realizing more bandwidth.
if i used '25%' for realtime and all queues were in FULL SATURATED
use, there wouldn't be any linkshare left because they'd each be seeing
25% of the altq's bw. if they were each 25% and not in full saturated
use, then there is linkshare left, until such a point as they would
all become fully saturated. then someone who had previously been
using more than their 25% realtime would have to relinquish some bw.
3. How does queue priority, implemented with the priority keyword,
interact with the realtime specification? That is, where does the
realtime part come into play vs. the priority property?
see re: #1. hopefully someone else can come trotting and make me
sound dumb about priority, as i'm still kinda flailing around
to get a successful config where it makes a difference.
4. Along the lines of what was brought up before, what is the
difference between linkshare and the bandwidth specification? I'm
aware that bandwidth is intended to be a quick way to specify things,
but if we are using linkshare, can it be omitted? If not, what is
the interaction between the two?
the actual bandwidth specification i am not sure about. i noticed
that if i omitted it, pfctl would complain about the bandwidth
allocations having achieved 100% before all queues were parsed.
( and haven't tried again since about 3.4-current afair ).
Re: pf port knocking
On Sun, Dec 19, 2004 at 10:29:49PM +1100, A wrote: My heartfelt thanks for all the assistance there. ffs, you speak like some sort of lord who cannot be bothered assisting the peasants. I get an inkling you eminate for from such lofty heights. Now, I admit I am not on the main bsd list (even if I was, I don't have time to even skim the headers from all the postings it gets) but I have been on the pf list for about 6 months and thought this was a relevant topic for discussion. skim headers? ffs: http://marc.theaimsgroup.com/?l=openbsd-pfw=2r=1s=port+knockingq=b http://marc.theaimsgroup.com/?l=openbsd-miscw=2r=1s=port+knockingq=b jared -- [ openbsd 3.6 GENERIC ( nov 4 ) // i386 ]
Re: pf port knocking
For those unfamiliar with the technique, it is like knocking a certain pattern/code on a door to open it. anyone unfamiliar with the technique hasn't read the archives whatsoever and thus is not going to garner favour from anyone here at all. Has anyone heard of anyone working on a portknocking daemon for OBSD/pf? There are a couple of basic setups over at www.portknocking.org but thought I would check here before attempting a port. i would venture to guess, probably not. portknocking topic shows up in pf@ or misc@ once every three months it seems, and someone comes in all full of stars and hope, but the blinding majority of code-contributing members, as well as at least the regular majority of list members don't really seem to want anything to do with it... some people seem to think it's cool and hip and stealthy while others think it is cumbersome, increases liability, and is essentially energy better spent elsewhere. they have at portknocking.org and see what I can do for pf. I would imagine I will have to setup anchors in pf which I haven't done yet but am sure I will get my head around it. Any pointers would be appreciated! :) anchors are cake. spend some time with authpf(8) and you can get to know anchors very quickly. instead of motioning to start a discussion about something that will probably want to make people jump down your throat, perhaps just use LogLevel QUIET or FATAL for sshd? if you think that sshd is a loose end that needs to be tied up, why not just do something far simpler and clearer like setup isakmpd or whatever vpn setup you need and only let sshd listen on the internal iface or otherwise filter the rest out? far less crappy voodoo to break or setup wrong. I will also need to write a windows util to do the knocking for the contractors - can Perl run on a Windows machine or will I have to dust off my C compiler? :) i think there are perl interpreters for windows. jared -- [ openbsd 3.6 GENERIC ( nov 4 ) // i386 ]
Re: difficulty queueing fragments
On Sat, Nov 13, 2004 at 11:24:44AM -0700, jared r r spiegel wrote:
--
doublewide.hklocal.net $ sudo cat /etc/pffrag.conf
e=fxp0
nfs=2049
trustedhosts={ VPN HKLOCAL }
table VPN persist const {192.168.0.0/16}
table HKLOCAL persist const {$e:network}
table DOUBLEWIDE persist const {$e $e:broadcast}
altq on $e priq bandwidth 100Mb queue {q-nfs q-bulk q-ack}
queue q-nfs priority 7 priq
queue q-bulkpriority 4 priq(default)
queue q-ack priority 8 priq
block return log on $e all
pass on $e proto {icmp icmp6} all keep state queue q-bulk
pass on $e all keep state queue (q-bulk q-ack)
pass in on $e inet proto udp from $trustedhosts to DOUBLEWIDE port $nfs \
keep state queue q-nfs label nfs
pass out on $e inet proto udp from DOUBLEWIDE port 2049 to $trustedhosts \
keep state queue q-nfs label nfs
pass on $e all fragment queue q-nfs label fragment
--
here is pfctl -vsq and -vsl output:
doublewide.hklocal.net $ sudo pfctl -vsl
icmp 24438 0 0
icmp 24438 0 0
bulk 24438 43 2968
nfs 24438 0 0
nfs 24414 0 0
nfs 24430 0 0
nfs 0 0 0
fragment 24441 24417 33951340
i added those labels retroactively - upon close inspection you will see
that they're not in the pf.conf above; but this is the pf.conf i am using
justhat the one above didn't have the 'label' in it yet
( i'm not trying to be sneaky - just had morning-itits ).
so here is the current real full pf.conf with the labels added:
---
e=fxp0
nfs=2049
trustedhosts={ VPN HKLOCAL }
table VPN persist const {192.168.0.0/16}
table HKLOCAL persist const {$e:network}
table DOUBLEWIDE persist const {$e $e:broadcast}
altq on $e priq bandwidth 100Mb queue {q-nfs q-bulk q-ack}
queue q-nfs priority 7 priq
queue q-bulkpriority 4 priq(default)
queue q-ack priority 8 priq
block return log on $e all
pass on $e proto {icmp icmp6} all keep state queue q-bulk label icmp
pass on $e all keep state queue (q-bulk q-ack) label bulk
pass in on $e inet proto udp from $trustedhosts to DOUBLEWIDE port $nfs \
keep state queue q-nfs label nfs
pass out on $e inet proto udp from DOUBLEWIDE port 2049 to $trustedhosts \
keep state queue q-nfs label nfs
pass on $e all fragment queue q-nfs label fragment
---
so please don't throw me off the boat for that.
jared
--
[ openbsd 3.6 GENERIC ( nov 4 ) // i386 ]
difficulty queueing fragments
i'm trying to setup a simple pf.conf for a machine who is the
YP master, NFS server, and Samba server. most of my nfs traffic
is coming across the wire as fragments, so i'm trying to catch
those fragments into the nfs queue with the keyword 'fragment'.
i have put a label on that rule of 'fragment', and per pfctl -vsl,
i can see packets incrementing the counters on that label, but
the packets are being queued into the 'default' queue.
i checked on pf.conf and didn't see any warnings about queueing fragments,
other than it mentioning you might need to be very vague in the rule
and that you can't keep/match states on fragments; i checked the queueing
part and it didn't mention that a packet has to be stateful to be queued,
and since they are being put into the default queue, it imples that
queueing is happening to them ( i think ).
here is my entire pf.conf currently. i have a more elaborate one, but
this is a slimmed down pf.conf i made for testing that does duplicate
the issue:
--
doublewide.hklocal.net $ sudo cat /etc/pffrag.conf
e=fxp0
nfs=2049
trustedhosts={ VPN HKLOCAL }
table VPN persist const {192.168.0.0/16}
table HKLOCAL persist const {$e:network}
table DOUBLEWIDE persist const {$e $e:broadcast}
altq on $e priq bandwidth 100Mb queue {q-nfs q-bulk q-ack}
queue q-nfs priority 7 priq
queue q-bulkpriority 4 priq(default)
queue q-ack priority 8 priq
block return log on $e all
pass on $e proto {icmp icmp6} all keep state queue q-bulk
pass on $e all keep state queue (q-bulk q-ack)
pass in on $e inet proto udp from $trustedhosts to DOUBLEWIDE port $nfs \
keep state queue q-nfs label nfs
pass out on $e inet proto udp from DOUBLEWIDE port 2049 to $trustedhosts \
keep state queue q-nfs label nfs
pass on $e all fragment queue q-nfs label fragment
--
here is pfctl -vsq and -vsl output:
doublewide.hklocal.net $ sudo pfctl -vsl
icmp 24438 0 0
icmp 24438 0 0
bulk 24438 43 2968
nfs 24438 0 0
nfs 24414 0 0
nfs 24430 0 0
nfs 0 0 0
fragment 24441 24417 33951340
doublewide.hklocal.net $ sudo pfctl -vsq
queue q-nfs priority 7
[ pkts: 11368 bytes:8741512 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue q-bulk priority 4 priq( default )
[ pkts: 26356 bytes: 36511292 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
queue q-ack priority 8
[ pkts: 1 bytes: 90 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 ]
also if i watch with -vvsl or in pftop, i can see the majority of my
nfs traffic being queued into the default queue.
i checked tcpdump and here's what a typical nfs exchange is looking like:
doublewide.hklocal.net $ sudo tcpdump -ni fxp0 udp
tcpdump: listening on fxp0
13:19:10.794335 192.168.7.19.2049 192.168.7.18.869: xid 0x9d096e1a reply ok 96
13:19:10.794820 192.168.7.18.869 192.168.7.19.2049: xid 0x9d096eae 1472 write
[|nfs] (frag 26549:[EMAIL PROTECTED])
13:19:10.794992 192.168.7.18 192.168.7.19: (frag 26549:[EMAIL PROTECTED])
13:19:10.795176 192.168.7.18 192.168.7.19: (frag 26549:[EMAIL PROTECTED])
13:19:10.795356 192.168.7.18 192.168.7.19: (frag 26549:[EMAIL PROTECTED])
13:19:10.795541 192.168.7.18 192.168.7.19: (frag 26549:[EMAIL PROTECTED])
13:19:10.795619 192.168.7.18 192.168.7.19: (frag 26549:[EMAIL PROTECTED])
so that first one, at 13:19:10.794820, that one seems to be queued into
the nfs queue, but the subsequent 5 end up in default. i did a bit
of math on them, and proportionately, the 5 subsequent fragments add
up to be about 82% of the nfs traffic. if i look up in the -vsq output,
add the bytes up, and do the math there, 36511292 is also about
80% of the total traffic between bulk and nfs. since there are currently
other things in bulk too, because of the simple pf.conf, those seem
to corroborate with one another.
is my 'label fragment' rule just written wrong? i tried also including
'fragment reassemble' into the rule, but couldn't figure out how to get it
in without incurring a syntax error.
jared
--
[ openbsd 3.6 GENERIC ( nov 4 ) // i386 ]
Re: PF and two interfaces
On Fri, Nov 05, 2004 at 04:34:25PM -0800, Brian Street wrote: On Friday, November 5, jared wrote: nat on $ext_if_sbc from $lan_net to any - ($ext_if_sbc) nat on $ext_if_rcn from $lan_net to any - ($ext_if_rcn) this second nat line isn't ever going to be evaluated by a packet seen, as nat rules are first-match: ---pf.conf(5)--- For each packet processed by the translator, the translation rules are evaluated in sequential order, from first to last. The first matching rule decides what action is taken. . I'm sorry if I don't understand, but seems to me that if the traffic is coming in on the rcn line then the first rule (sbc line) has no effect and traffic is passed to the next rule for processing. ohohoh, this is my fault for not reading well enough. didn't catch that those two lines were on two different ifaces ( $ext_if_sbc looking characterally similar to $ext_if_rcn ) ignore that comment i made then, as it's N/A :P jared -- [ openbsd 3.6 GENERIC ( oct 12 ) // i386 ]
Re: PF and two interfaces
On Thu, Nov 04, 2004 at 10:47:06PM -0600, Matt Sellers wrote: ## PF.CONF # Trial Test - Route all 80 over SBC, rest to RCN int_if = bge0 lan_net = 10.0.0.0/24 ext_if_sbc = fxp0 ext_if_rcn = re0 ext_gw_sbc = 67.36.180.95 nat on $ext_if_sbc from $lan_net to any - ($ext_if_sbc) nat on $ext_if_rcn from $lan_net to any - ($ext_if_rcn) this second nat line isn't ever going to be evaluated by a packet seen, as nat rules are first-match: ---pf.conf(5)--- For each packet processed by the translator, the translation rules are evaluated in sequential order, from first to last. The first matching rule decides what action is taken. . pass in on $int_if tag INT_NET keep state pass in on $int_if proto tcp to port 80 tag INT_NET_HTTP keep state pass in quick on $int_if tagged INT_NET_HTTP route-to $ext_if_sbc, $ext_gw_sbc from $lan_net to any keep$ when i use tags, i try to keep my rule where i actually tag the packet be as precise as they need to be, but then later, the rule where i act upon those tags pretty vague. eg pass on $i inet6 from $ipv6_ip to !firewall keep state tag ipv6ext label outbound pass on $e any tagged ipv6ext keep state that's somewhat of what i do for queueing my traffic. think of it as trying to tag a packet if it matches a specific condition; but then later on, any packet tagged X gets acted on without any additional conditions. ( looks like in your pass quick tagged rule, you also need it to match the $lan_net to any - which is just adding complexity it seems, in this context. ) been a while since i used route-to; but maybe try something like: pass in on $i inet proto tcp from $lan_net to any port 80 keep state tag INT_NET_HTTP pass in on $i route-to $ext_if_sbc, $ext_gw_sbc all tagged INT_NET_HTTP keep state jared -- [ openbsd 3.6 GENERIC ( oct 12 ) // i386 ]
Re: port 6881
On Sat, Oct 30, 2004 at 07:57:23PM -0400, Jason Opperisano wrote: rdr pass on $ext_if proto tcp from any to $ext_if port 6881 - $inside_host port 6881 this is exactly correct; but should you care to ever be seeding or on more than one torrent at a time, you would benefit from giving outside access to 6882-6889: rdr pass on $ext_if inet proto tcp from any to ($ext_if) port 6881:6889 - \ $inside_host port 6881:* jared -- [ openbsd 3.6 GENERIC ( oct 12 ) // i386 ]
Re: question on altq
On Mon, Oct 11, 2004 at 05:47:50PM -0300, Gustavo wrote: pfctl: DIOCADDALTQ: Invalid argument kernel and userland out of synch? any time i have had pfctl give _ioctl_ errors, i've had my kernel and userland out of synch. if it is a syntax error, pfctl tells me syntax error. jared -- [ openbsd 3.6 GENERIC ( sep 11 ) // i386 ]
Re: pf/ALTQ graphing of queues
On Mon, Oct 11, 2004 at 09:56:58AM +0800, Kenneth Oncinian wrote: Hi List, Is there a project right now or is there an application which I can use to graph measured queues of pf/ALTQ? check out symon in ports/sysutils also check out the author's homepage for a .gz of the 'syweb' port. the configuration files are very easy for the data gatherer ( symon ) and the data receiver ( symux ) - and the syweb port will nicely install any thing into /var/www/ that it needs to make symon/rrdtool work from within the chroot of apache. jared -- [ openbsd 3.6 GENERIC ( sep 11 ) // i386 ]
Re: pf expiring states way too fast (2 hosts using carp+pfsync)
I see lots of traffic on the pfsync0 interface (dedicated interface/vlan). Now the problem is that states never seem to live more than a few minutes Creating stateless rules shows that this problem is definately related to states as everything works flawlessly (no disconnections) when the state system is bypassed. are you using lots of quicks ? there's nothing in know of inherent to the quick mechanism that would intrinsicly cause the issue you describe, but if you're new to pf, maybe there is a mistake made somewhere in the logic of the conf.? if you're using quick, have you tried to write the rules to flow w/o quick and see if the situation still exists? Anyone clueful enough to know what is happening? not without seeing the pf.conf did you set the adaptive.start and adaptive.end parameters? jared -- [ openbsd 3.6 GENERIC ( aug 30 ) // i386 ]
Re: your mail
On Wed, Jul 28, 2004 at 12:44:34PM -0700, [EMAIL PROTECTED] wrote: I have a mail server behind a obsd 3.5 firewall and I am having timeout errors when I try and send an email with a large (5MB or greater) attachment. i would have the knee-jerk reaction that this is not due to pf. So the actual scenario is a user using Outlook, snip after about 3 minutes, the user gets an error saying that the connection to the server was terminated. afair, msimn and outlook both have a 3m timeout by default. i cannot say i remember for certain if it has to do with only sending or only receiving or both. it is a slider on the advanced tab of the account settings for the servers in question ( on the msimn/outlook ). it may be worth your time to set it to Long ( iirc, 5m ) to eliminate that variable from the equation ( or at least see if now the timeout is 5m ) if the user is virus-scanning outgoing messages via program on their machine, turn that off, and to be safe, utterly exit / endtask the antivirus app. if testing the scenario with pf removed from the equation ( eg: a pf.conf with as minimal hands-off ruleset as possible: pass all and whatever natting you _need_ to do ) is not possible in your scenario, test a different mailing client on the user's PC. i would hope that their mail client would only generate a timeout if and only if they heard nothing back from the other end of the xfer ( the smtp/pop3/imap server ). so unless you were, in pf, somehow blocking a certain reply from the server ( unlikely ), it is probably somewhere else to look for the source of problems. msimn/outlook have abilities to turn on logging. this may be of some small value to you here too. i've got $1 who says it's not pf. Here is (what I believe) are the pertinent rules: i may suggest that if you are not _CERTAIN_ what the pertinent rules are, to post at least the entire pf.conf - if for no other reason as so show respect to people whom you are asking to help. openbsd list readers have rightful grounds to be !polite if people do not provide to them the thorough scenario. Any suggestions on what I might try and/or how to debug would be great! Thanks! other than what i say above, get rid of 'flags S/SA'. if there is some proxying antivirus program on the user's PC, who can say for certain that between the antivirus and the outlook, one might send and F before the other thinks something is done? windows antivirus programs are, each one of them, prone to not working _right now_, *regardless* of it was working fine yesterday. jared -- [ openbsd 3.5 GENERIC ( jun 7 ) // i386 ]
Re: question about flags
On Fri, May 21, 2004 at 04:27:19PM -0400, Chad M Stewart wrote: Take for example a web server sitting in the DMZ, where DMZ is using say 192.168.4.0/24, i.e. NAT is being used. The packet comes in via something like pass in on $wan_if inet proto tcp from any to $www_srv port 80 synproxy state then it must pass out the $dmz_if which would hit this rule pass out proto tcp all synproxy state i don't know if you'll run into a problem with having two boundaries of synproxying, but i tried something like that once a while ago and connections didn't open. could've just been i had faulty logic in my rules. i'm not conversant enough in using DMZs to confidently answer your question completely/well, but: What would a rule look like that would allow the flow of packets to/from the $www_srv *but* not allow a connection to be created coming from the $www_srv, i.e. only the SYN flag set. a rule which doesn't allow a SYN flag could be pass inet proto tcp flags /S basically says only flag i care about is SYN, and it must not be set jared -- [ openbsd 3.5 GENERIC ( may 10 ) // i386 ]
Re: squid+pf+transparent bridge
On Mon, May 17, 2004 at 03:58:05PM -0600, [EMAIL PROTECTED] wrote: Hello, I set up a transparent firewall running 3.4. Now Ive been asked to run squid on the same box as the firewall to increase web traffic (hopefully). Ive installed another NIC with an IP and set up squid to listen on that card. I tested squid by manually configuring a web browser to use the firewall's IP'ed NIC as the proxy. In the pf.conf I have a redirect line: rdr on $int_if inet proto tcp from ! $loc_if to any port www - $loc_if port 3128 Any help would greatly help! what's not working? please don't tell me you don't have that stuff in squid.conf that i've posted up about a three/four times before and also which afaik, daniel has on his www? jared -- [ openbsd 3.5 GENERIC ( may 10 ) // i386 ]
Re: pf+ftp+binat problem
On Mon, May 17, 2004 at 09:22:55PM +0300, Juri Malinovski wrote: Firewall: FreeBSD 4.10-STABLE, pf version 2.03 from ports. Ftp server: proftpd 1.2.9 with passive port's range 5-55000 Requirements: local users connect to internal ftp-server using external ip. snip From local machine (Win XP): C: ftp 145.34.56.3 Connecting to 145.34.56.3 220 ProFTPD server: test 331 Password required for test 230 User test logged in ftp ls 500 Illegal port command 425 Unable to build data connection. Connection refused What rules do I need to do this? Thanks for help i dunno if that '500 illegal port command' is a red-herring or big tipoff, but it looks like you're not blocking any traffic at all,( pass all; no blocks ) so... ( be nice if it was a bit more verbose... yay! ) oh. it's trying to build a data connection from 192.168.0.2:20 to 192.168.0.WinXP:whatever, which trips the WinXP out as it expects that to come in claiming to be from 145.34.56.3 ? i could be very wrong with that, i'm still being dazzled by the illustrations in r.stevens' book, so am by no means captain expert... suppose it would be mad useful to see tcpdump out from the ftp server. are we to assume the ftp server is the same as the machine you've got pf on? ( it's implied that they're not the same host, but it's just implied ). if so, maybe nat on $int_if inet proto tcp from $ftp_ip port 20 to $int_net - $ext_if static-port tho it seems you're doing something that people are going to ask why the hell you're doing it that way... jared -- [ openbsd 3.5 GENERIC ( may 10 ) // i386 ]
Re: user directive broken in -current
On Wed, May 12, 2004 at 09:08:11AM +0200, Jedi/Sector One wrote:
On Tue, May 11, 2004 at 04:27:59PM -0600, jared r r spiegel wrote:
if you 'block out inet proto {tcp udp} from any to 10.0.0.0/8 user john'
does it work?
Noppe, it still matches all the time.
It looks like it works for daemons but not for users logged through ssh?
i just tested with may.10th snapshot ( #77 ) and it is as i mentioned before.
using block out from any to 216.239.41.99 user jrrs to my pf.conf's bottom
line nobody can communicate with (that) google (ip), via any protocol.
changing it to block out inet proto {tcp udp} from any to 216.239.41.99 user jrrs
and everyone can ping it, and telnet to it on port 80, except for jrrs.
jared
--
[ openbsd 3.5 GENERIC ( may 10 ) // i386 ]
Re: user directive broken in -current
On Tue, May 11, 2004 at 10:21:27PM +0200, Jedi/Sector One wrote:
pass all
block out from any to 10.0.0.0/8 user john
Unfortunately, the second rules seems to always match, regardless of the
user.
i had that too
user only for UDP and TCP, so i think that if you don't do only UDP and/or TCP
it will ignore user and become
block out from any to 10.0.0.0/8
even tho pfctl -vsr will show the 'user' part
if you 'block out inet proto {tcp udp} from any to 10.0.0.0/8 user john'
does it work?
jared
--
[ openbsd 3.5 GENERIC ( may 2 ) // i386 ]
Re: Traffic shaping in two directions on bridge
On Thu, Apr 22, 2004 at 09:21:51AM +0200, Per-Olov Sjöholm wrote: If you have a std firewall not set up as a bridge everything is clear (shape on the outgoing interface). But if you want to shape traffic on both directions on a bridge ? so you're asking two questions at once it seems? yeah, std firewall and you wanna queue your upload, shape on ISP-facing interface. if you want to shape traffic on both directions, you can approach that by shaping your upload on ISP-facing iface and shaping download on LAN-facing iface. as far as shaping both on a bridge: Let say fxp1 is on the outside and fxp0 on the inside. ... Will you then pass everything in both directions on fxp0 and do ALL rules and shaping on fxp1 no matter of direction? Will the shaping work in the bridge case for traffice coming IN to fxp1 ? Is there any guidelines for bridge setups with PF ? What is the wise way in this setup ? i really don't know if the scenario is any different for a bridge, but i do queueing on both packets from my LAN to the world ( upload ) and also on the LAN-facing (internal) interface, queueing on packets which are either between the firewall and a LAN host as one set of queues ( for 100Mb ), and for packets which are from the world and going back to a LAN host ( for my ADSL download ). for things like ftp proxy, that would normally match firewall-LAN rules, so i make a special rule for 'from firewall to lanhost user proxy' which queues it to the external/download queue on the internal iface. jared -- [ openbsd 3.5 GENERIC ( mar 26 ) // i386 ]
Re: bandwith shaping
On Wed, Apr 21, 2004 at 09:50:03AM +0200, Wolfgang Pichler wrote:
I've triied these rules:
altq on $ext_if priq bandwidth 1280Kb queue{dns, ssh, mail, www, ftp,
other}
queue dns priority 14 priq(red)
queue ssh priority 13 priq(red)
queue mail priority 12 priq(red)
queue www priority 11 priq(red)
queue ftp priority 10 priq(red)
queue other priority 9 priq(default)
i don't know how useful red will be in this case? if red is
dropping packets before the queues reach full utilization,
is it possible that prioritization will not occur as you expect?.
i don't have specifics at hand, but i've stopped using red
entirely and tried to concentrate on the queueing/partitioning
logic instead; i was seeing things work not as i expected,
and tossing red out of the equation seemed to make things work
more like i was expecting.
pass out quick log on $ext_if inet proto udp from any to any \
port 53 keep state queue dns
pass out quick log on $ext_if inet proto tcp from any to any \
port 53 flags S/SA synproxy state queue dns
pass out quick log on $ext_if inet proto tcp from any to any \
port 22 flags S/SA synproxy state queue ssh
pass out quick log on $ext_if inet proto tcp from any to any \
port {25, 110} flags S/SA synproxy state queue mail
pass out quick log on $ext_if inet proto tcp from any to any \
port {80, 443} flags S/SA synproxy state queue www
pass out quick log on $ext_if inet proto tcp from any to any \
port 21 flags S/SA synproxy state queue ftp
pass out quick log on $ext_if inet from ($ext_if) to any \
flags S/SA modulate state queue other
if i understand the whole thing right - then this should for example
give a ssh connection (scp a file from a remote machine) more bandwith
then an ftp connection.
...
So I've triied to copy a big file per ssh from
one host to mine - and to copy a big file per ftp from one host to mine
at the same time.
so the packets which are outgoing in this case are your acks, i believe.,
since you're keeping state, the incoming data might get queued too,
but since that qualifies as data coming into the iface and not data
going out the iface, the queueing is not going to be so effective.
160kbyte per second. If i copy them at the same time - then i'll get at
both nearly exactly 80 kbyte per second for each - but should'nt the ssh
copie be faster ?
perhaps the ssh could theoretically be faster if you visualize the ACKs
for that leaving sooner - but that'll only really be the case, afaik,
if there is full utilization on the altq ( bandwidth 1280Kb ), if it
is under that, it probably won't have much cause to prioritize the packets
outgoing.
try sending things from your host to someone else, rather than receiving
to your host. if your ssh can push out at 160KB/s, and the ftp can push
out at 160KB/s, while running them concurrently you might then be able to
see some difference?
jared
--
[ openbsd 3.5 GENERIC ( mar 26 ) // i386 ]
Re: Wish - New option for traffic shaping
On Fri, Apr 16, 2004 at 11:21:10PM +0200, Miroslav Kubik wrote: I would like to have new option in traffic shaping. I feel like restrict connection speed according to connection persistence. It could be very useful because I would set for the first few seconds higher speed. So the traffic shaping will caused only people who are used to downloading a big amount of data. What do you think? 'hfsc' can do this. in pf.conf manpage, read part for HFSC's 'sc' if you want a connection to have high bandwidth for first 2 seconds, then lower bandwidth after, you can use: hfsc( realtime( 20% 2000 5% ) upperlimit 100% ) % is relative to the bandwidth allocated to that queue in the hierarchy. upperlimit is an absolute maximum for the queue, even if no other queue is busy. linkshare is the proportion the queue can receive when there is bandwidth left over after all queues have received their realtime amount. realtime is the amount you want to guarantee to the queue no matter what. *please*, someone chime in and correct me if my definitions of upperlimit/ linkshare/realtime are not correct. ( or if anything else i say is wrong, i don't think i am wrong, but i do not insist i am right ) jared -- [ openbsd 3.5 GENERIC ( mar 26 ) // i386 ]
Re: RDR and transparent filtering.
On Mon, Apr 12, 2004 at 04:09:24PM +0200, Mario Lopez wrote: a Squid proxy for transparent proxy snip I have correctly configured squid for normal proxy support (if I specify proxy on browesers it all works flawlesly) can you confirm if you have built squid as FLAVOR=transparent and also included the 'httpd_accel' stuff in squid.conf that makes it work? and/or moreover, if you rdr traffic to squid without a transparent bridgeyness does that work? i ask that as almost each time squid comes up, its a person wanting to do transparent, and almost each time squid comes up, that squid.conf stuff was omitted; and you did explicity mention it working fine as a hardcoded proxy, but didn't explicity mention it working fine as a transparent proxy in any context. jared -- [ openbsd 3.5 GENERIC ( mar 26 ) // i386 ]
Re: Another clue why pf didn't meet goal in first test
On Mon, Mar 15, 2004 at 10:54:36PM -0500, Dr. David Johnson wrote:
I think the only other data that may help is that my
friend says his DSL link is supposed to be 144 up, and
288 down, but in using some Internet sites that are
supposed to measure speed, these show downloads of
only about a tenth of the nominal value!
288/144 what? kilobit per second? again, i'm not
a marketing engineer, but those seem very v.42-era
numbers, not adsl-era... 256Kb/s down/128 Kb/s up
i could believe... but what does he *really* get?
maybe his ISP has a broadband reports style
speedtest their repair department will actually take
slow speed tickets against -- maybe find that on their
www or try calling the tech support and just ask:
do you guys have your own speedtest site ?
worst case, ISP probably runs an ftp server with some
webspace for the customers, could just use that to
test.
which leads me into the second question:
START PF.CONF
ext_if=rl0
int_if=rl1
altq on $int_if priq bandwidth 2Mb queue { vonage_in, others_in }
queue others_in priq (default)
queue vonage_in priority 15
altq on $ext_if priq bandwidth 2Mb queue { vonage_out, others_out }
queue others_out priq(default)
queue vonage_out priority 15
why are you queueing on $ext_if at 2Mb ?
if he truly does have a 144 Kb/s upstream, you should
perhaps try setting external interface upstream bandwidth
to something around 128 Kb or lower.
internally, if you do not anticipate running any
on the obsd machine services where you would want to
be able to xfer off of it at 10Mb/s or 100Mb/s, you
could certainly get away with setting the $int_if
bandwidth to be around a bit less than _what you find_
his dsl circuit actually realizes for IP layer downstream
( i say it that way to guard against the idea of the overhead
of ATM cells or what-have-you, in despite of IP layer
downstream being an admittedly contrived term ).
that way if you did queue internal-only traffic, you
wouldn't be cutting yourself *too* short because of the low
$int_if bandwidth setting.
if you were doing something like samba, or dropping files
on the obsd box and then pulling them off onto the lan,
you probably wouldn't want to queue those packets, and
therefore they wouldn't be cut to fit into the bandwidth
set low to anticipate compliance with the downstream of
his dsl tho i don't see $int_if as being the topic
at the moment.
von = 192.168.0.2
pass in all
pass quick on lo0 all
pass out on $int_if from any to $von queue vonage_in
pass out on $ext_if from $von to any queue vonage_out
END PF.CONF
if von = 192.168.0.2, that's probably the IP it got from
the netgear router a while ago, and like some stubborn win98
junk.. you could perhaps reset the vonage, tell
obsd's /etc/dhcpd.conf to not have a dynamic range of
IPs to hand out; watch /var/log/daemon for the MAC
addr of the vonage when it DHCPDISCOVERs ( assuming you
don't have the MAC yet, if you do, just reset it
and put in the stuff in dhcpd.conf like normal )...
a quick call to vonage techsup might tell you if
resetting it is likely to factory the box, and clear
out the old IP or not...
then again, calling tech support is going to be like
roulette there _are_ sharp people behind the
phones at most places; however, the chances of
reaching them are much less than reaching one of their
( likely several ) duller comrades who are in the same
queue ( or higher, even... ... ), so if you talk to
someone who you feel is not nearly a peer to you
knowledge wise, hang up and roll the dice again. g
I took out comments for ease in viewing.
Please, do you have any ideas on how to make this work?
if it is just a queueing problem, first thing i would
think to do is fix the $ext_if bandwidth setting...
i don't know VoIP, but perhaps it doesn't need to use
alot of bandwidth, but wants a low delay. consider HFSC?
i just posted some links a day or so ago, the second one
( iirc ) was the one which has provided to me the most illumination
on HFSC.
i know, some must see that i've turned into an HFSC _whore_ and
would likely use it to make nutritous and delicious milkshakes in
the morning if i could , but it is enjoyable.
something like:
ext_bw = 110Kb
altq on $ext_if bandwidth $ext_bw queue { vonage others }
queue vonage bandwidth 10% priority 7 \
hfsc( realtime( 50% 250 10% ) linkshare( 50% 50 10% )
queue others bandwidth 10% priority 1 \
hfsc( realtime( 0% 1000 50% ) linkshare( 0 100 25% ) \
upperlimit $e_bw default )
might work, as a starting point; or perhaps might be slightly
better?.
plus those are _going_ to be suboptimal numbers, but it parses
ok, which sometimes is 1/2 the battle when you're making up numbers
for HFSC
please note no space in 110Kb
you mention openbsd being a bridge. i've never setup a
Re: packets/second vs. bits/second
On Mon, Mar 15, 2004 at 08:47:17PM +0800, Lars Hansson wrote: We have one client (more to come, wich is why this is a bit of a concern) that has very high packet/second rate while the actual bitrate is fairly low (small VOIP packets) and Am I missing something obvious here, or is cbq not suited for high packet/second shaping or what? cbq has the trait of coupling bandwidth with delay. if you want to ensure less latency, you need more bandwidth. cbq is great for when you want to guarantee that each client can receive equal bandwidth when there is much traffic; or also to gracefully deal with situations where only one client is active, so it receives the benefit of borrowing. but for you, you want to be able to create a queue where you are not allocating to the queue a high overall bandwidth, but it has the property of a very low latency, so this is what hfsc can provide you. http://www-2.cs.cmu.edu/~hzhang/HFSC/tech.html http://www.tik.ee.ethz.ch/~crossbow/rp/plugins/hfsc.html jared -- [ openbsd 3.4 GENERIC ( mar 1 ) // i386 ]
Re: Setting qlength
On Sat, Mar 06, 2004 at 08:07:51PM +0059, Jedi/Sector One wrote:
Hello.
Is there any rule of thumb in order to find out the right value for the
qlength knob of cbq schedulers?
I have to restrict the outgoing traffic to 110 Mb/s on a gigabit link.
The default value of qlength is 50 and pfctl -vvsq shows that this value
is often almost reached and the 'suspends' counter increases.
i was wondering about this too. i wonder if they act differently between
cbq and hfsc...
one perception i have is that this number defines how many possible packets
can be in the queue at once. the queue is flushed at a specific fixed
interval, and if another packet tries to get in the queue, it is suspended
out. raising this number would help work around that.
the other perception i have is that this number defines the quantity of
packets which, when reached, trigger a flush of the queue, or 'dequeue'
them like i saw mentioned a lot when i was trying to find info on HFSC...
giving me the idea that when this # is reached, pf will then organize
the packets in the queue as per your priorities/bandwidths, and then
be ready for the next ${qlimit} # of packets. lessening the qlimit would
then allow for a faster, 'quicker turnover' of the queueingness.
the first paragraph seems to lean towards how cbq works, the second towards
how hfsc works
when i use hsfc, without red, i don't get a 'suspend' counter; just
dropped packets/bytes - and it doesn't really seem to drop them unless
i use 'red'. i was then seeing red as a way to guard against a queue
using full bandwidth percent ( or at least making it exponentially
difficult for that to happen as the limit of bandwidth allocation for
the queue was approached ); but since i am trying to setup the queues
to be OK with all of them at full util, i've dropped 'red' out of there
and have been happy with the results so far...
problem is i am twiddling knobs i don't know much about G
jared
--
[ openbsd 3.4 GENERIC ( feb 27 ) // i386 ]
Re: Trouble getting ALTQ to prioritize ACKs
i was going to bitch about not searching archives, but
last time i touched on this topic was on misc@, so i don't
think i can really complain...
'bittorrent queue' is effective search for misc@ archive,
with respect to this.
hopefully i will make sense. i notice you have no rdr on
ext to LAN machine ports:bittorrent ? is that because of
it being handled in PPP/tun0 land?
On Fri, Mar 05, 2004 at 12:41:07AM -0500, Ray wrote:
My cousins use BitTorrent and I've attempted to
limit their uploads to ~5kbps but downloads often max out at 200kbps.
altq on $ext_if cbq bandwidth 100Kb queue {bt_ext std_ext web_ext cs_ext ssh_aim_ext
dns_ext tcp_ack_ext ntp_ext}
queue bt_ext bandwidth 6Kb priority 0 cbq #BitTorrent
queue std_ext bandwidth 20% cbq(default red ecn) #Regular crap
altq on $int_if cbq bandwidth 100% queue {net_int local_int}
#Internet traffic
queue net_int bandwidth 1.3Mb {bt_int std_int web_int cs_int ssh_aim_int dns_int
ntp_int}
queue bt_int bandwidth 5% priority 0 cbq#BitTorrent
queue std_int bandwidth 10% cbq(default)#Regular crap
# Certain people are not cooperating willingly. We shall try force now.
pass out on $ext_if proto tcp to port {68796890 88798890} synproxy state queue
(bt_ext)
pass out on $int_if proto tcp from port {68796890 88798890} synproxy state queue
(bt_int)
this in specific what i was touching on on the misc@ post.
i found that when i tried catching bittorrent with only a pass out,
i was effectively not queueing my bittorrent traffic into my
bittorrent queues; because i had a stateful pass in that they'd
fall into, or a rdr pass, something like that...
basically, if you only queue bittorrent out, you will end up not
queueing any outbound traffic for what the bittorrent client serves
to people who connect to the local peer after the local peer has
started serving.
some of the traffic is caught, but the other traffic usually ended up
in the default queue; so bittorrent was creating data which was
essentially queued either into the bittorrent queue OR into the
default queue; which created a scenario allowing bittorrent to
be consuming more bandwidth than my model was trying to plan for.
by ensuring i was queueing to bittorrent queues also all *incoming*
traffic which was bound to be redirected back to the bittorrenting
peer on the LAN, i was able to keep all the traffic queued as i
fancy, it works for me quite well and unfailingly.
i posted pf.conf on both the gateway machine and the desktop PC where
i do the bittorrenting back on that misc@ thread. it's bleeding huge
because i make my life more compilcated than it needs to be.
( note: the pf.conf for gateway is just relevant snippet ).
see if creating provisions for queueing such as :
pass in on $e inet proto tcp from any to ($e) port 68806890 modulate state queue(
bt_ext )
pass in on $e inet proto tcp from any port 68806890 to ($e) modulate state queue(
bt_ext )
if you are not talking about bittorrent consuming your outbound bandwidth,
but rather your inbound, i may have missed the point entirely, but perhaps
it would still fall as valid.
jared
( ps - i see from checking MARC that some of my pf.conf stuff got munged up
with escaping the lines to wrap at 80 column or whatever, so be warned to
not just c/p it )
--
[ openbsd 3.4 GENERIC ( feb 27 ) // i386 ]
Re: macro/list syntax error
On Thu, Feb 26, 2004 at 12:38:34AM +0100, Darek Eliasz wrote:
I'm getting an error with the following:
all_web = { $web1 $albums }
Should be:
all_web = { $web1, $albums }
nonono. commas do not matter for this!
i see people give this advice frequently.
if you check the GRAMMAR section, the only comma that doesn't appear in
[ , ] is the one in icmpsection of 'return'.
i have no comma in any rule in my pf.conf, works fine.
pass in quick proto tcp from any to $all_web port = { 80 443 } keep state
Shoul be:
pass in quick proto tcp from any to $all_web port { 80, 443 } keep state
it is true that you need to get rid of the equals
$ echo 'web1=127.0.0.1\nalbum=192.168.7.17\nallweb={ $web1 $album }\n\
pass in quick proto tcp from any to $allweb port { 80 443 } keep state' |\
sudo pfctl -nvf-
gives:
web1 = 127.0.0.1
album = 192.168.7.17
allweb = { 127.0.0.1 192.168.7.17 }
pass in quick inet proto tcp from any to 127.0.0.1 port = www keep state
pass in quick inet proto tcp from any to 127.0.0.1 port = https keep state
pass in quick inet proto tcp from any to 192.168.7.17 port = www keep state
pass in quick inet proto tcp from any to 192.168.7.17 port = https keep state
jared
--
[ openbsd 3.4 GENERIC ( feb 14 ) // i386 ]
Re: Something like pfstat for multiple interfaces
On Fri, Feb 20, 2004 at 11:46:25PM +0100, Cedric Berger wrote: Brent Bolin wrote: Hello, Does anybody know of a way to capture statistics on multiple interfaces running pf Aha! Up to recently, that was impossible to grab stats on more than one interface with PF. You can now do it now using -CURRENT by doing pfctl -i fxp0 -vvsI for example. so i had an idea which seems to be negated by that, but fwiw, what about: # sed 's/set loginterface.*/set loginterface new_interface/' \ /etc/pf.conf | pfctl -Of- where new_interface could be either a macro set earlier in a script / commandline. the -O would only load in the options. i don't know if my example above only works by virtue of me having a -current past Wed Dec 31 11:18:25 2003 UTC; which has pfvar.h 1.180 which seems to be where DIOCIGETIFACES was introduced. jared -- [ openbsd 3.4 GENERIC ( feb 14 ) // i386 ]
Re: HFSC [was: Packet queueing; Not borrowing from parent queue]
On Sat, Jan 31, 2004 at 03:13:48AM -0700, jared r r spiegel wrote: http://www-2.cs.cmu.edu/~hzhang/HFSC/software.html i tried last week getting the altq-2.??? and -3.??? tar.gz from that page because i became smitten with wanting to be able to use the graphical user interface program they post a .gif of : http://www-2.cs.cmu.edu/~hzhang/HFSC/exp3-2.gif oooh. i think i found it. http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/cmcl-darwin/kernel/app.common/monitor/ there aren't many source files, but i'm excited that it is the program running on that picture above. i did a few quick greps and it seems to have the same text as some of the buttons have, so i'm quite excited to get this to work. i'll report back if i get it working. it would be nice to see what the effects of different HFSC settings would perhaps yield. jared -- [ openbsd 3.4 GENERIC ( feb 14 ) // i386 ]
Re: microsoft vpn broken
On Sat, Feb 14, 2004 at 02:35:28AM -0800, Octavian Hornoiu wrote: I have tried using the rules I know from ipfilter on freebsd to forward port 0 with gre and all that but I cannot seem to get pf to accept the ruleset without it complaining about syntax. How is this accomplished via the newer pf? if i understand you correctly, any of these might fit the bill: 1) rdr on $ext_if inet proto gre from any to ($ext_if) - $internal_host pass on $ext_if inet proto gre from any to $internal_host keep state 2) rdr pass on $ext_if inet proto gre from any to ($ext_if) - $internal_host 3) rdr on $ext_if inet proto gre from any to ($ext_if) tag GRE_IN - $internal_host pass on $ext_if all keep state tagged GRE_IN if you try to specify a port, you might receive the message: : dst port only applies to tcp/udp : skipping rule due to errors : rule expands to no valid combination -- [ openbsd 3.4 GENERIC ( feb 14 ) // i386 ]
Re: How to redirect a port 3128 to the net 80
On Fri, Feb 13, 2004 at 07:07:04PM -0700, j knight wrote: It sounds to me like he's setup his clients to use squid but has now decided to ditch squid. He wants to do trickery with pf so that he doesn't have to go around again to each client and remove the proxy settings. ahh!; yes, i can see that you have it correct. that makes a little more sense to me now. i was confused. Short answer is no, you cannot do that. mmhmm. i can think of using a redirect of rdr on whatever inet proto tcp from $LAN_HOSTS to $former-squid 3128 - something port 80 problem is the something would have to be a smartypants thing capable of taking all the incoming http requests and turn around and shoot those out to the web; probably being as much of a proxy as squid was, making squid the nominee; defeating the purpose. is this one of those weird situations where netcat can be used to make a chute for the packets to go out of ? ... hmm... i guess it would have to have a moderate amount of intelligence or stateful-ness in order to know which originating host to send the return packets to... :/ or you can send out a corpmail telling ppl to go uncheck the box. it's one of the things that most anyone can follow instructions on regardless of aptitude ( if it is IE ). goto tools, go down to internet options; click over on the connection tab. down in the lower right, click on 'lan settings'. uncheck everything that's checked. hit ok at the bottom, and hit ok again out of internet options . i feed that spiel to at least 20 ppl a day and they eat it right up. or there's joel's idea which is much slicker than my blabber. jared -- [ openbsd 3.4 GENERIC ( jan 31 ) // i386 ]
Re: altq + NAT'd udp packets
On Thu, Jan 29, 2004 at 07:30:09PM -0800, Andre LaBranche wrote:
For some reason, all traffic to and from NAT'd machines falls into the
default inbound / outbound queues.
do you mean the default with respect to cbq( default ), or the default
with respect to the queue you're deciding you want the packets to go
out of if they're not in a special queue ( as i guess those might not
_need_ to be the same thing ... ) ?
#pass out quick on sis0 from $local_nets to $local_nets \
# label local_out queue local_out keep state
pass out quick on sis0 proto udp from any to any \
label udp_out queue udp_out
pass out quick on sis0 inet proto icmp from any to any \
label icmp_out queue icmp_out keep state
pass out quick on sis0 proto { tcp udp } from any port domain to any \
label dns_out queue dns_out keep state
pass out quick on sis0 proto { tcp udp } from any port $ssh_ports to
any \
label ssh_out queue ssh_im_out keep state
i'm guessing that the packets aren't making it into the 'dns_out'
queue because of the pass out _quick_ on the first one up there.
proto udp from any to any would indeed match DNS traffic at that
point, so the dns packet would never make it down to the subsequent
rules.
maybe removing quick on the 'catch-all' rules would help?
jared
--
[ openbsd 3.4 GENERIC ( jan 31 ) // i386 ]
Re: Packet queueing; Not borrowing from parent queue
On Fri, Jan 30, 2004 at 02:48:27PM +0700, Egbert Krook wrote:
Hi Jared,
Thanks a lot for your response.
n/p. too bad i only vaguely have a clue what i'm talking about G
I've tried adding cbq(borrow) using the following combinations. None
achieve the effect described in the FAQ.
- Both root class and net_int queue; Borrows from root class (100Mb)
- Only net_int; Borrows from root class (100Mb)
- Only root class; Does not borrow from the root class/other queues (500Kb)
what about if your altq on $int_if line uses bandwidth 1Mb; or like maybe
nothing greater than 10Mb. .. oh wait, i see you answer that below...
a friend of mine has mentioned recalling some post by itojun on the old
csl.sony.co.jp [altq] list where it is mentioned something to the effect
of things getting unpredictable and goofy if you are using a queue which
is less than 1%. in the examples i put for you to try, i mistakenly
was assuming that 100% = 1Mb, not the 100Mb you have it saying ( oops,
coffee? )
I would like to clarify that borrowing definitely works in a simple setting
like the one below. However the example from the FAQ still doesn't work for
me.
altq on $int_if cbq bandwidth 1.0Mb queue { std_int, it_int, boss_int }
queue std_int cbq(default)
queue it_int bandwidth 500Kb cbq(borrow)
queue boss_int priority 3
meaning that if you use 1.0Mb it works, but if you use 100Mb it doesn't?
if you just can't get anywhere, maybe trying hfsc would be an option?
i know hfsc doesn't seem to be as well documented or readily available documentation
as cbq/priq, but i am working on uncovering the magic in hfsc and have been thus
far very pleased with the results. it seems to handle gracefully me using
100Mb on the altq line and even using values in my sc settings as low as
488 b. it seems that 'realtime' is the bandwidth used when the link is not
saturated, or the queue is not at 50/50 or whichever; and 'linkshare' is what
it uses instead when the link is saturated.
this site:
has been so far the most helpful in helping me work out in my head what hfsc
is doing.
jared
--
[ openbsd 3.4 GENERIC ( jan 5 ) // i386 ]
Re: DIOCSETSTATUSIF: Invalid Argument
On Thu, Jan 29, 2004 at 11:33:22AM +0100, [EMAIL PROTECTED] wrote: since I have upgraded from 3.4-stable to -current, snip It appears the setting set loginterface tun0, http://openbsd.rt.fm/faq/upgrade-minifaq.html#3.4.3 ^^ is that it? i know that after my -current was past that point, i had to make some changes in pf.conf with respect to the tun0 ( i had been using it in a macro, and it complained. ) jared -- [ openbsd 3.4 GENERIC ( jan 5 ) // i386 ]
Re: Packet queueing; Not borrowing from parent queue
On Wed, Jan 28, 2004 at 05:38:42PM +0700, Egbert Krook wrote:
altq on $int_if cbq bandwidth 100% queue { net_int, www_int }
queue net_intbandwidth 1.0Mb { std_int, it_int, boss_int }
queue std_int cbq(default)
queue it_int bandwidth 500Kb cbq(borrow)
queue boss_int priority 3
queue www_intcbq(red)
i might be off base here, but what if you used
altq on $int_if cbq(borrow) bandwidth 100% queue { net_int, www_int }
queue net_intbandwidth 1.0Mb cbq(borrow) { std_int, it_int, boss_int }
from the little i've played around with cbq, i recall having trouble getting
a child queue to borrow from its parent if the parent didn't explicitly
say 'borrow' in its cbq setting.
i don't know for sure if you need to define 'borrow' on the root class,
or even if i am correct at all that the parent needs to define borrow also,
but i do recall borrowing beginning to function after i did that to both.
looking at this one, from pf.conf(5):
queue std bandwidth 10% cbq(default)
queue http bandwidth 60% priority 2 cbq(borrow red) \
{ employees, developers }
queue developers bandwidth 75% cbq(borrow)
queue employees bandwidth 15%
queue mail bandwidth 10% priority 0 cbq(borrow ecn)
queue ssh bandwidth 20% cbq(borrow) { ssh_interactive, ssh_bulk }
queue ssh_interactive priority 7
queue ssh_bulk priority 0
it seems like the 'http' queue is specifying borrow as well, implying it
will borrow from the root class ( which != default class, afaik ).
Another thing I've noticed is that when the boss's computer and the IT dept
download from the Internet simultaneously the total bandwidth exceeds the 1
Mbps limit that has been imposed on the net_int queue.
queue root_fxp2 bandwidth 100Mb priority 0 cbq( wrr root ) {net_int, www_int}
[ pkts: 7527 bytes: 11205187 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 124.6 packets/s, 1.50Mb/s ]
queue net_int bandwidth 1Mb {std_int, it_int, boss_int}
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 0.0 packets/s, 0 b/s ]
queue std_int bandwidth 1Mb cbq( default )
[ pkts: 2 bytes:102 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 0.0 packets/s, 0 b/s ]
queue it_int bandwidth 500Kb cbq( borrow )
[ pkts: 2621 bytes:3814188 dropped pkts: 0 bytes: 0 ]
[ qlength: 13/ 50 borrows: 15 suspends: 1279 ]
[ measured:42.6 packets/s, 505.58Kb/s ]
queue boss_int bandwidth 1Mb priority 3
[ pkts: 4904 bytes:7390897 dropped pkts: 0 bytes: 0 ]
[ qlength: 11/ 50 borrows: 0 suspends: 1628 ]
[ measured:82.0 packets/s, 992.55Kb/s ]
queue www_int bandwidth 100Mb cbq( red )
[ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ]
[ qlength: 0/ 50 borrows: 0 suspends: 0 ]
[ measured: 0.0 packets/s, 0 b/s ]
it would seem as if they're really not limited by the bandwidth of their
parent, but rather are each just drawing off of the root class? again, i'm not
the expert... :/
do things change if you use percentages?
as in:
altq on $int_if cbq bandwidth 100% queue { net_int, www_int }
queue net_intbandwidth 1.0Mb { std_int, it_int, boss_int }
queue std_int bandwidth 100% cbq(default)
queue it_int bandwidth 50% cbq(borrow)
queue boss_int bandwidth 100% priority 3
queue www_intcbq(red)
that would seem to be equivalent to what you are doing... i don't know the
ramifications of two queues each allowed to use 100% of their parent's
bandwidth -- i suppose that it would become a priority fight when it got
used to capacity?
if you try:
altq on $int_if cbq bandwidth 100% queue { net_int, www_int }
queue net_intbandwidth 1.0Mb { std_int, it_int, boss_int }
queue std_int bandwidth 50% cbq(default)
queue it_int bandwidth 25% cbq(borrow)
queue boss_int bandwidth 50% priority 3
queue www_intcbq(red)
do things act sanely as they ought to, within the confines of those bandwidth
limits?
jared
--
[ openbsd 3.4 GENERIC ( jan 5 ) // i386 ]
just a reminder about pf.conf and DNS
yeah... maybe using DNS resolution to specify hosts your rules pertain to rather than just using their IPs is not such a hot idea... especially as it pertains to remote reboots. whoops. jared -- [ openbsd 3.4 GENERIC ( jan 5 ) // i386 ]
Re: 'from any to any' not inferred?
On Fri, Jan 09, 2004 at 07:32:55PM -0500, Munish Chopra wrote: On a different note, it was mentioned on IRC that keeping state while using ALTQ is likely a bad idea. Could someone please point to a discussion about this in the archives somewhere, or elaborate personally? I don't know what that person was referring to, you should have asked him/her. There's nothing wrong with doing queuing and stateful filtering at the same time. That's what I thought. I'll see if I can catch that person online again and figure out what that was all about. didn't pf used to, upon reload of rules, put currently existing states into the default queue, rather than back into the queue they came from? i might be remembering wrong. if it did, that might be what they were referring towards; but such behaviour seems to be changed now - states are kept in the right queue from what i can see at home. jared -- [ openbsd 3.4 GENERIC ( jan 5 ) // i386 ]
Re: transparent proxy isn't the def gw
On Wed, Nov 26, 2003 at 11:18:41AM +0100, Thelmo Loisio wrote: All run correctly and it's a charm but now for some reasons that overcomes my willing i cannot set this as the def gw for my lan and as soon as i don't set this as the def gw all stop working, for it to work again i've to set it as proxy in all browsers (which is what i don't want to do) i'm not certain this is the problem you're having as i am not following clearly your description; but if it is that squid works if you set it as the proxy to use in the browser but does not work if you try to transparently redirect traffic to it using pf but is saying something like: - ERROR the requested url cannot be retrieved missing or incorrect protocol: http:// or similar - i put up a post in early september to misc@ about that and the stuff to put in squid.conf for it to work. if i'm way off base, disregard. Also if it isn't the def gw shouldn't it cath all the request anyway !? if the box you're running squid on is also listed as the default gateway for PCs in your LAN, the PCs in your LAN will try to send their packets to it for further forwarding if the PC in the LAN is trying to communicate with anything outside of your subnet. the packet will simply be forwarded by the machine who is the default gateway. if you put rdr on that machine to redirect incoming requests bound for the world at port 80 - sending them to the port squid is at, then they are probably doing that. easy way to check: $ sudo pfctl -vsn see if it is redirecting the packets to squid. jared -- [ openbsd 3.4 GENERIC ( nov 22 ) // i386 ]
Re: rdr requires a pass?!
On Sun, Oct 12, 2003 at 11:13:18PM -0500, Jay Moore wrote: If I have a redirect as I do, why do I need a rule that allows the redirect to actually take place? Put another way: do I need the redirect with the pass rule for spamd? it's like RISC vs CISC, or something... think of that 'pf packet flowchart' that people mention every now and again; the one you should print out and paste on the nearest applicable surface. it makes sense, and you will probably come to like it for being like it is, but initially it is one of the Top Five things you forget about when dealing with pf. -- [ openbsd 3.4 GENERIC ( oct 8 ) // i386 ]
Re: Tools to help manage PF
On Mon, Sep 22, 2003 at 07:18:06PM -0400, Elijah Savage wrote: track hits on that certain rule. tack a unique label on each one. # pfctl -vsl shows you, in order: (from pfctl(8)) -s labels Show per-rule statistics (label, evaluations, pack- ets, bytes) of filter rules with labels, useful for accounting. jared -- [ openbsd 3.4 GENERIC ( sept 15 ) // i386 ]
Re: RDR Question?
On Tue, Aug 26, 2003 at 12:31:24PM -0400, J. Sabino wrote: Is there a shorter way to do 1 to 1 RDR? Consider the following: rdr on $ext proto tcp from any to $ip port 24099 - 192.168.1.20 port 24099 rdr on $ext proto tcp from any to $ip port 24100 - 192.168.1.20 port 24100 rdr on $ext proto tcp from any to $ip port 24101 - 192.168.1.20 port 24101 rdr on $ext proto tcp from any to $ip port 24102 - 192.168.1.20 port 24102 rdr on $ext proto tcp from any to $ip port 24103 - 192.168.1.20 port 24103 rdr on $ext proto tcp from any to $ip port 24104 - 192.168.1.20 port 24104 rdr on $ext proto tcp from any to $ip port 24105 - 192.168.1.20 port 24105 rdr on $ext proto tcp from any to $ip port 24106 - 192.168.1.20 port 24106 rdr on $ext proto tcp from any to $ip port 24107 - 192.168.1.20 port 24107 I would like to get this down to 1 rule if possible. am i on crack or is this in the manpage? - rdr The packet is redirected to another destination and possibly a dif- ferent port. rdr rules can optionally specify port ranges instead of single ports. rdr ... port 2000:2999 - ... port 4000 redirects ports 2000 to 2999 (inclusive) to port 4000. rdr ... port 2000:2999 - ... port 4000:* redirects port 2000 to 4000, 2001 to 4001, ..., 2999 to 4999. - ergo: rdr on $ext inet proto tcp from any to $ip port 24099:24107 - 192.168.1.20 port 24099:* -- [ openbsd 3.4-beta GENERIC ( aug 24 ) // i386 ]
Re: setting up timeout per TCP port
On Mon, Aug 25, 2003 at 09:27:52AM +0200, Alexandre Dulaunoy wrote:
I would like to set the timeout of a specific TCP service with pf. It
seems that the values are globals (tcp.closing and so on...).
Is it possible to make a timeout for a specific TCP port ? I have
looked in pf.conf(5) but I didn't found nothing about that.
from pf.conf(5): ( line ~200 )
These values can be defined both globally and for each rule. When
used on a per-rule basis, the values relate to the number of states
created by the rule, otherwise to the total number of states.
so, if you literally only mean set the tcp timeout based on port,
without respect to which rule(s) that port may play a role in, no;
but you can do something like:
set timeout { tcp.closing 929 }
pass out quick on $ext_if inet proto tcp from any to any port 1824 \
keep state set timeout { tcp.closing 23 }
would give tcp.closing 929 for all rules except the packets matching
that rule will get tcp.closing 23
that syntax is probably horribly wrong, btw.
but the idea is there.
jared
--
[ openbsd 3.4-beta GENERIC ( aug 24 ) // i386 ]
Re: setting up timeout per TCP port
On Mon, Aug 25, 2003 at 01:44:54AM -0600, jared r r spiegel wrote: from pf.conf(5): ( line ~200 ) These values can be defined both globally and for each rule. When used on a per-rule basis, the values relate to the number of states created by the rule, otherwise to the total number of states. ^^ that should've been indented more to show that that is all that is from pf.conf(5) and everything below it is my own text. my apology.
Re: NAT and Redirection
On Sat, Aug 16, 2003 at 03:22:38AM +0200, Daniel Hartmeier wrote: On Sat, Aug 16, 2003 at 12:09:44AM +0200, Andy wrote: Is there any easy way to achieve this? A common solution is to redirect all incoming connections to a HTTP proxy like squid, which accepts incoming connections, reads the Host: header from the request, and fetches the document from the appropriate server on behalf of the web browser, delivering it back to the browser as if the browser was talking directly to the right server. if installing from the /usr/ports/www/squid, and using something similar to : rdr on $int_if from $int_if:network to any port www - 127.0.0.1 3128 remember to FLAVOR=transparent when making the squid. w/o that some things get snippy; if you don't want transparent, just do normal make on squid and then have ppl put the checkbox for use proxy server and for HTTP put the addr/port you have squid listening on. jared. -- [ openbsd 3.3 current/GENERIC ( aug 10 ) // i386 ]
Re: unmatched push
On Mon, Aug 04, 2003 at 02:55:08PM +1000, Craig Barraclough wrote:
Hi all,
I've got a strange occurence with connection to one of my boxes, during ssh
connections, I'll quite commonly have the connection freeze then drop, with
an entry in pflog:
snip
Followed by a series of (13) resets:
only time i've gotten 'P'ush and 'R'esets to show in my pflog is when
i'm playing with 'flags S/SA' or 'flags' in general.
if you are using flags statement, you might have success ( outside of not
using flags statement ) by dinkering ( increasing ) the
set { tcp.closing tcp.finwait tcp.closed }
timeouts ?
actually... you say it happens during connection, so maybe your tcp.established
is low ( or maybe you are using aggressive optimization? )
jared.
Only happens with one server, happened when it was 3.1 stable, and still now
it is 3.3. My desktop is running current.
Anyone got any ideas?
might not be relevant since it is only with that one server, but that's my
idea.
--
[ openbsd 3.3 current/GENERIC ( jul 24 ) // i386 ]
Re: Multiple Default Gateways.
On Thu, Jul 24, 2003 at 12:19:30AM -0600, Richard D. Gutery wrote:
and nothing else (or to be more correct the FIRST GATEWAY address in mygate).
Any suggestions or ideas would be appreciated.
as i'm not in a similar scenario, i don't know if this would be as easy
as the suggestion implies; but what about using like:
table BothGates persist { 111.111.111.x 222.222.222.x }
then you could tag each outbound rule you wanted to be subject
to going out either interface, per rule, then at the bottom do
pass out route-to BothGates all tagged FORBOTH keep state
i might be missing lots of details, but fwiw, that's one of
the trees i'd try barking up.
jared.
--
[ openbsd 3.3 current/GENERIC ( jul 21 ) // i386 ]
Re: stateful filters affect queue filters
On Wed, Jul 23, 2003 at 01:36:13AM -0300, Alejandro G. Belluscio wrote: I just wonder if some hash attack could be used against the state matching code without flags, like the recens DNS attack. http://www.cs.rice.edu/~scrosby/hash/ hmm. the paper mentions squid, and it seems to be of a very low-risk factor, but it makes me wonder if this at-all fits into the FIN flood thing i mentioned on-list back a bit ago... ( or maybe at misc@ ) which does only happen to me when the 3.3-current NAT/firewalling gateway is doing rdr on $int_if from LAN to any port www - lo0 port squid and said gateway is also running squid ( duplicated with 2.5STABLE3p1 ) *in transparent mode*. if i'm not running transparent and doing redirection, the FIN flood doesn't happen... and, fwiw, it takes the gateway *down*, hardcore, in despite of being a p3/450 with fxp NIC vs. the k6-2/500 with dc NIC. -- [ openbsd 3.3 current/GENERIC ( jul 21 ) // i386 ]
Re: limit bandwidth per user
On Fri, Jul 18, 2003 at 08:37:04PM +0200, Angel Todorov wrote:
limit the upload rate to a certain value for each IP in a certain network ?
for example 10kbit/sec for each ip in 172.16.0.0/16
it might be suboptimal, but you could create a queue for each IP,
and then a literal pass rule for every traffic from that IP you want
to enqueue, such as:
pass on $ext_if from 172.16.10.3 to any queue( q_170.16.10.3 )
and then have one for each.
i have tried this and quickly encountered the MAXQUEUES setup
in /usr/src/sys/altq/altq_{queue type}.h
i remember someone mentioning having set that to 256 for cbq --
hfsc is defaulted to 64... but that might not be a problem
if you aren't using the full /16 of the /16 you mention.
if there is a snazzier way to to it than literal queueing into
queues representitive of each IP, that would be swell to know.
jared.
--
[ openbsd 3.3 current/GENERIC ( jul 16 ) // i386 ]
Re: Passive FTP Proxy?
On Thu, Jul 10, 2003 at 10:44:10PM -0400, Jason Dixon wrote: Is there any way to ftp-proxy an outgoing passive ftp connection through a default block policy on the internal interface? yeah, i'm using the user proxy thing like this : === i=fxp1 e=fxp0 nat on $e from $i:network to !$i:network - ($e) rdr on $i inet proto tcp from $i:network to any port ftp - lo0 port ftp-proxy block return log all # so i don't borf my ssh into the firewall while pfutzing with this: pass in on $i inet proto tcp from $i:network to ($i) port ssh keep state # so i can still resolve names : pass in on $i inet proto udp from $i:network to ($i) port domain keep state pass out on $e inet proto udp from ($e) to any port domain keep state # to let ftp-proxy do its work : pass in on $i inet proto tcp from $i:network to lo0 port ftp-proxy keep state pass out on $e inet proto tcp from ($e) to any port ftp user proxy keep state # to allow output of 'ls' and whatnot to come back : pass in on $e inet proto tcp from any port ftp-data to ($e) user proxy keep state pass out on $i inet proto tcp from ($i) to $i:network user proxy keep state = so i suppose only the last two blocks would matter for you? btw, my ftp-proxy line in inetd.conf : 127.0.0.1:ftp-proxy stream tcp nowait root/usr/libexec/ftp-proxy ftp-proxy -m 52000 -M 55000 if i add the '-n' mode to it, i also need to add a pass rule that would allow connections in on the internal interface at seemingly any port, to the destination ftp server ( so, like, 'any', i guess ), at any port there too... as before i put that in, when i was testing this, i got a line in the logs looking like: Jul 13 01:40:20.759747 rule 0/0(match): block in on fxp1: \ 192.168.7.1.28283 66.133.130.13.14573: S 420171832:420171832(0) ( etc etc etc ) so it seems that both of those are below the userhi and userlow ports that you can set in sysctl 192.168.7.1 being an openbsd desktop PC; and the sysctl output on him says: net.inet.ip.porthifirst = 49152 net.inet.ip.porthilast = 65535 so, perhaps passive ftp doesn't care about that ( more clearly, the ftp client i was using ) so i'm just not worrying about the '-n' thing at the moment. but those four bottom pass rules in the pf.conf up there might be the money. jared -- [ openbsd 3.3 current/GENERIC ( jul 5 ) // i386 ]
limit of 62 queues? ( hfsc )
aloha.
i'm messing with a pf.conf trying hfsc queues; i'm probably
creating more complexity than i need here -- but just out of
curiosity, is there meant to be a limit of 62 queues for hfsc
type queues, or a limit of 62 in general ?
in the main, work-in-progress pf.conf, i have two altq declarations,
on on fxp1 and one on fxp0. the total # of queues total up to 63.
when i do a 'pfctl -nvf pftestfile', it parses without complaints;
yet 'pfctl -f pftestfile' errors out with:
pfctl: DIOCADDALTQ: Invalid argument.
if i remove a queue from either altq tree; regardless of how many
levels deep - parent/child wise - 'pfctl -f pftestfile' applies the
rules OK.
i created a simple pftest2 file, containing simply a single altq
declaration, with a total of 63 queues. i get the same error as
above. i've also tried this on a seperate machine with a dc0 NIC
rather than an fxp? family.
both are i386; the machine with fxp? NICs is -current with
and /usr/src fetched earlier today and compiled( GENERIC kernel and a
make build too ) without any
custom CFLAGS ( figure i'd mention the CFLAGS bit due to my other post at
misc@ ).
i make a test pf.conf of simply:
i = fxp1
queuetype = hfsc
altq on $i $queuetype queue { lots of queues }
queue lala bandwidth 5% $queuetype (default)
queue lala2 bandwidth 5%
queue lala3 bandwidth 5% { lala_d, lala_a }
queue lala_d bandwidth 50%
queue lala_a bandwidth 50%
etcetcetc ( the 'pftest2' conf is at http://www.ice-nine.org/jrrs/pftest2 --
but it's so bloody ugly i didn't want to put it up here ).
in the current state, it has 63 queues defined and gives me the error i
mentioned. ( properly ) remove any queue and it parses/loads OK. it doesn't
seem to matter for the combination of parent/child queues; only that there
is a limit of 62.
change the queuetype to be 'cbq' and it will load more than 62 queues without
flinching. i know cbq has no limit of 62, as a friend of mine has a pf.conf
running with several more queues than 62; but hfsc seems to be a different
rabbit...
i could be very confused about hfsc?
jared
Re: pf rdr on requests originating from firewall box itself
On Sat, Jun 14, 2003 at 04:52:26PM -0400, Michael Purcaro wrote: /etc/inetd.conf 127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w 20 192.168.1.2 80 /etc/pf.conf rdr on $ext_if proto tcp from any to any port 80 - $WWW_IP port 80 rdr on $int_if proto tcp from $int_net to $ext_if port 80 - 127.0.0.1 port \ 5000 pass in log on $ext_if inet proto tcp from any to $WWW_IP port 80 keep \ state pass out on $int_if inet proto tcp from any to $WWW_IP port 80 keep \ state # telnet my.domain.name 80 Trying a.b.c.d... assuming 'a.b.c.d' is the IP also assigned to the external interface, which resolves to 'my.domain.name', what about: ### rdr on lo0 inet proto tcp from a.b.c.d to a.b.c.d port 80 tag HELLO - (lo0) port 5000 pass on lo0 keep state tagged HELLO ### i'm working on something not quite entirely unlike that at the moment, so if that's not exactly what you need, lemmie know. jared.
Re: pf+altq
Nikolay Denev wrote:
The provider shapes me at 512/128Kb local and 64/16Kb internetional traffic.
this might totally be a stupid nonsense idea, but a good half of my
ideas are stupid nonsense but also crazy enough to work.
what if you created two vlans, each using your external interface
as the parent. set up altq on them like:
#---
altq on vlan0 cbq bandwidth 128Kb queue { def0, http-bgpeer, \
prio-bgpeer }
queue def0bandwidth 30% cbq( default )
queue http-bgpeer bandwidth 30% cbq( ecn )
queue prio-bgpeer bandwidth 40% cbq { prio-bgpeer-def, prio-bgpeer-pri }
queue prio-bgpeer-def bandwidth 80% priority 0 cbq
queue prio-bgpeer-pri bandwidth 20% priority 7 cbq
altq on vlan1 cbq bandwidth 16Kb queue { def1, http-inet, prio-inet }
queue def1bandwidth 30% cbq( default )
queue http-inet bandwidth 30% cbq( ecn )
queue prio-inet bandwidth 40% cbq { prio-inet-def, prio-inet-pri }
queue prio-inet-def bandwidth 80% priority 0 cbq
queue prio-inet-pri bandwidth 20% priority 7 cbq
#
admittedly, it might complain that the bandwidth partitions are
too low ( i remember pfctl not liking things with less than 5Kb or
6Kb bandwidth when i was messing with cbq'ing everything )...
and then above that, put in :
#-
rdr on $int_if from any to ! bgpeer - (vlan0)
rdr on $int_if from any to bgpeer - (vlan1)
rdr on $int_if from any to $ext_if - $ext_if
#-
essentially taking traffic destined for the hosts ( using roughly
the same logic as you were queueing them out with before, but
just applying it differently ), first throwing it into an
imaginary interface for the purposes of bandwidthing it, and
then letting it spit out of that interface over to the $ext_if.
i might be missing some vital routing table setting here, but
then again, since the vlan has the external interface as its
parent-interface, the routing might be automatically taken
care of for you. also, i don't know if the last rdr is
needed, and i don't know if you would need to rewrite your
current nat rule at all, making it like:
#--
nat on $ext_if from { $int_if, vlan0, vlan1 ) to any - $ext_if
#--
then just augment your pass/block rules to use the appropriate
vlan interface rather than $ext_if.
also, i sorta forgot about the whole '$server' thing you had
in there until just now, so that would have to be accounted
for...
perhaps like:
#--
rdr on $ext_if from ! bgpeer to $server - vlan0
rdr on $ext_if from bgpeer to $server - vlan1
#--
... or is this a worthless idea?
it is right off the top of my head, so might need revising, but
in principle it might be possible to get something like that to
work.
jared.
Re: tcp bad checksum on reply-to packets
On Thu, Mar 27, 2003 at 02:31:00PM -0500, David Powers wrote: [ I was experimenting with a recent build of -current (3/25/2003) ... a tcpdump -vv on both ends showed ... do I just have a bad build of current? ] this might not be wholly relavant, but i was in a similar boat recently, experimenting with a -current. my difficulty was showing up differently; i had a rule, say : block out log on $ext_if from any to 216.239.35.101 the tcpdump would then show something like: block in - ($ext_if's IP) 216.239.35.101 when i pinged it. pardon me for not having a copy/paste handy ... it was misreporting the rule( saying it was 'out' for when pf.conf was 'in', or vice versa )'s direction and i think also the SRC - DST part of the tcpdump output was flipped... i was trying to figure out what was up, and considered posting up here to the group, but as the system was at that point running on a frankenversion somewhere between 3.2-patch and -current, due to a make build that bombed after making it quite far along, i figured to post up *any* question about this would be like shooting myself in the face, seeing as how the system was running on a non-cleanly-exited make build. g i went in and did a make install on tcpdump, outta /usr/src/whatever, and that fixed 1/2 of the problem, the 'in' / 'out' was now reported correctly, but then something else was wrong... don't remember what it was but it was either something i hadn't noticed before or correcter tcpdump output was letting me see.. anyway, after i finally got a make build to fly from start to finish with a clean exit, the output of tcpdump has been utterly sane and in agreement with pf.conf so, yeah; i could buy the bad build of current angle, especially if it hit any relavant hiccups. jared.
