From bugmaster at FreeBSD.org Mon Nov 3 03:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 3 03:08:33 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200811031106.mA3B6u5O010987@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/82271 pf [pf] cbq scheduler cause bad latency 24 problems total. From peterjeremy at optushome.com.au Mon Nov 3 09:27:14 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Nov 3 09:27:21 2008 Subject: [PATCH] PF+dummynet In-Reply-To: <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> Message-ID: <20081103060321.GA45414@server.vk2pj.dyndns.org> On 2007-Oct-27 19:45:59 +0000, Ermal Lu?i wrote: >Attached is the patch against -CURRENT for integrating PF with dummynet! > >It gives full dummynet support in pf.conf syntax and removes dummynet >depndency to ipfw. I've recently found this and applied it to 7.1-PRERELEASE. There were a few rejects and a couple of printf format problems which were all quite easy to fix. I also found an incorrect getopt() string in pfctl, incorrect PLR definition, and an uninitialised dnflow variable. Actually using it presents some more problems. Firstly, if you have ipfw in the kernel then dummynet packets appear to loop indefinitely. Disabling ipfw fixed this (I had built ipfw into the kernel incase I couldn't get pf+dummy to work). The above left me with wierd delays and incorrect packet counts on the rules. Further sleuthing shows that I'm falling foul of the state rules that pf is creating - though the behaviour is still wierd. Given the following: dnpipe 128 bandwidth 2Mb delay 500 queue 64KB dnpipe 136 bandwidth 2Mb delay 500 queue 64KB r1) pass in quick on vlan128 from any to 192.168.136.0/22 dnpipe 128 r2) pass in quick on vlan136 from any to 192.168.128.0/22 dnpipe 136 I get the following: t0 ICMP ECHO REQ a->b -> match r1: pass to pipe 128 (delay 500msec), create state s1 t+.5s -> ICMP ECHO REQ a->b t+.5s <- ICMP ECHO RESP b->a match r2: pass to pipe 136 (delay 500msec), create state s2 match s1: pass to pipe 128 (delay 500msec) t+1.5s ICMP ECHO RESP b->a <- t2 ICMP ECHO REQ a->b -> match s1: pass to pipe 128 (delay 500msec) match s2: pass to pipe 136 (delay 500msec) t2+1s -> ICMP ECHO REQ a->b t2+1s <- ICMP ECHO RESP b->a match s2: pass to pipe 136 (delay 500msec) match s1: pass to pipe 128 (delay 500msec) t2+2s ICMP ECHO RESP b->a <- I managed to fix ICMP by testing that the rule direction matches the packet direction before passing it to dummynet. Unfortunately, this means that TCP only goes through dummynet in one direction (since TCP only has a single state entry). I think the duplicate ICMP state entry is a bug in pf. And the dummynet patches need to support two pipes (one for each direction). I am still looking into this. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20081103/eec94acf/attachment.pgp From mk at adminlife.net Tue Nov 4 01:33:49 2008 From: mk at adminlife.net (Matthias Kellermann) Date: Tue Nov 4 01:33:55 2008 Subject: rdr rule does not work (bad hdr length) Message-ID: <491012AE.7000409@adminlife.net> Hi list, I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in a local network and want to forward one port from host a to host b. host a is the pf host. This is the rule to redirect traffic from host a to b: rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state If I try to get a telnet connection from my client 192.168.0.51 the connection gets stuck and nothing happens. This is the output of tcpdump on the pflog0 interface: # tcpdump -netttvvi pflog0 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > 192.168.0.10.23: [|tcp] 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] Anybody has an idea whats wrong here? Regards, Matthias From koitsu at FreeBSD.org Tue Nov 4 01:38:08 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Nov 4 01:38:15 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <491012AE.7000409@adminlife.net> References: <491012AE.7000409@adminlife.net> Message-ID: <20081104093800.GA43676@icarus.home.lan> On Tue, Nov 04, 2008 at 10:15:26AM +0100, Matthias Kellermann wrote: > Hi list, > > I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). > > I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in > a local network and want to forward one port from host a to host b. > > host a is the pf host. This is the rule to redirect traffic from host a > to b: > > rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 > pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state > > If I try to get a telnet connection from my client 192.168.0.51 the > connection gets stuck and nothing happens. This is the output of tcpdump > on the pflog0 interface: > > # tcpdump -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > 192.168.0.10.23: [|tcp] > 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > > Anybody has an idea whats wrong here? This is not a pf problem. tcpdump's snaplen defaults to 56 bytes, which is too small when reading from pflog. Use the -s flag to increase the snaplen to 256 bytes, for example. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mk at adminlife.net Tue Nov 4 01:52:11 2008 From: mk at adminlife.net (Matthias Kellermann) Date: Tue Nov 4 01:52:18 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <20081104093800.GA43676@icarus.home.lan> References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> Message-ID: <49101B48.2060704@adminlife.net> Jeremy Chadwick wrote: > On Tue, Nov 04, 2008 at 10:15:26AM +0100, Matthias Kellermann wrote: >> # tcpdump -netttvvi pflog0 >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > >> 192.168.0.10.23: [|tcp] >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] >> >> Anybody has an idea whats wrong here? > > This is not a pf problem. tcpdump's snaplen defaults to 56 bytes, which > is too small when reading from pflog. Use the -s flag to increase the > snaplen to 256 bytes, for example. > Thanks Jeremy. Did that. This is the output of tcdump after increasing the snaplen to 256 bytes: # tcpdump -s 256 -netttvvi pflog0 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 23993, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.43758 > 192.168.0.10.23: S, cksum 0xeb13 (correct), 3072328535:3072328535(0) win 5840 000319 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 22314, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.43758 > 192.168.0.10.23: S, cksum 0x4553 (correct), 108273612:108273612(0) win 0 I still have no clue whats going wrong here. Regards, Matthias From koitsu at FreeBSD.org Tue Nov 4 01:57:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Nov 4 01:57:56 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <49101B48.2060704@adminlife.net> References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> <49101B48.2060704@adminlife.net> Message-ID: <20081104095748.GA44045@icarus.home.lan> On Tue, Nov 04, 2008 at 10:52:08AM +0100, Matthias Kellermann wrote: > Jeremy Chadwick wrote: > > On Tue, Nov 04, 2008 at 10:15:26AM +0100, Matthias Kellermann wrote: > >> # tcpdump -netttvvi pflog0 > >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > >> 192.168.0.10.23: [|tcp] > >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > >> > >> Anybody has an idea whats wrong here? > > > > This is not a pf problem. tcpdump's snaplen defaults to 56 bytes, which > > is too small when reading from pflog. Use the -s flag to increase the > > snaplen to 256 bytes, for example. > > > > Thanks Jeremy. Did that. This is the output of tcdump after increasing > the snaplen to 256 bytes: > > # tcpdump -s 256 -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 23993, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.43758 > > 192.168.0.10.23: S, cksum 0xeb13 (correct), 3072328535:3072328535(0) win > 5840 > 000319 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 22314, > offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.43758 > > 192.168.0.10.23: S, cksum 0x4553 (correct), 108273612:108273612(0) win 0 > > > I still have no clue whats going wrong here. Try changing "synproxy state" to "keep state", and see if you have the same problem. Note that you may need to reset your state table after changing this rule (see pfctl -k). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mk at adminlife.net Tue Nov 4 02:23:12 2008 From: mk at adminlife.net (Matthias Kellermann) Date: Tue Nov 4 02:23:19 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <20081104095748.GA44045@icarus.home.lan> References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> <49101B48.2060704@adminlife.net> <20081104095748.GA44045@icarus.home.lan> Message-ID: <4910228C.3020400@adminlife.net> Jeremy Chadwick wrote: > Try changing "synproxy state" to "keep state", and see if you have the > same problem. Note that you may need to reset your state table after > changing this rule (see pfctl -k). Ok, I tried that. Here is the result: # tcpdump -s 256 -netttvvi pflog0 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35529, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x5fae (correct), 3300997001:3300997001(0) win 5840 2. 998190 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35530, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x5cc0 (correct), 3300997001:3300997001(0) win 5840 6. 000214 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35531, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x56e4 (correct), 3300997001:3300997001(0) win 5840 12. 000425 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35532, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x4b2c (correct), 3300997001:3300997001(0) win 5840 References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> <49101B48.2060704@adminlife.net> <20081104095748.GA44045@icarus.home.lan> <4910228C.3020400@adminlife.net> Message-ID: <20081104102535.GA44596@icarus.home.lan> On Tue, Nov 04, 2008 at 11:23:08AM +0100, Matthias Kellermann wrote: > Jeremy Chadwick wrote: > > Try changing "synproxy state" to "keep state", and see if you have the > > same problem. Note that you may need to reset your state table after > > changing this rule (see pfctl -k). > > Ok, I tried that. Here is the result: > > # tcpdump -s 256 -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35529, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > > 192.168.0.10.23: S, cksum 0x5fae (correct), 3300997001:3300997001(0) win > 5840 > 2. 998190 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35530, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > > 192.168.0.10.23: S, cksum 0x5cc0 (correct), 3300997001:3300997001(0) win > 5840 > 6. 000214 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35531, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > > 192.168.0.10.23: S, cksum 0x56e4 (correct), 3300997001:3300997001(0) win > 5840 > 12. 000425 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id > 35532, offset 0, flags [DF], proto TCP (6), length 60) > 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x4b2c (correct), > 3300997001:3300997001(0) win 5840 0,nop,wscale 6 > > If I stop the connection attempts from the client the tcpdump output > stops too. Others will have to assist. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From max at love2party.net Tue Nov 4 02:39:18 2008 From: max at love2party.net (Max Laier) Date: Tue Nov 4 02:39:24 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <491012AE.7000409@adminlife.net> References: <491012AE.7000409@adminlife.net> Message-ID: <200811041139.10125.max@love2party.net> On Tuesday 04 November 2008 10:15:26 Matthias Kellermann wrote: > I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). > > I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in > a local network and want to forward one port from host a to host b. > > host a is the pf host. This is the rule to redirect traffic from host a > to b: > > rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 > pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state > > If I try to get a telnet connection from my client 192.168.0.51 the > connection gets stuck and nothing happens. This is the output of tcpdump > on the pflog0 interface: > > # tcpdump -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > 192.168.0.10.23: [|tcp] > 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > > Anybody has an idea whats wrong here? redirection only works if your pf box sees both directions of the connection. In your case, however, 192.168.0.10 probably knows how to contact 192.168.0.51 directly. So what happens is: .51 -> SYN (src=.51,dst=.250) -> pf -> SYN (src=.51,dst=.10) -> .10 <---------------------------- SYN/ACK (src=.10,dst=.51) <- But .51 is waiting for a SYN/ACK from .250. You can solve this by either: - moving .10 into a separate LAN for which the pf box is the default gw - userland reflection (e.g. nc(1) from inetd(8)) - having your clients connect to the correct box in the first place (split horizon DNS etc.) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From mk at adminlife.net Tue Nov 4 07:48:33 2008 From: mk at adminlife.net (Matthias Kellermann) Date: Tue Nov 4 07:48:39 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <200811041139.10125.max@love2party.net> References: <491012AE.7000409@adminlife.net> <200811041139.10125.max@love2party.net> Message-ID: <49106ECF.4080803@adminlife.net> Max Laier wrote: > On Tuesday 04 November 2008 10:15:26 Matthias Kellermann wrote: >> I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). >> >> I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in >> a local network and want to forward one port from host a to host b. >> >> host a is the pf host. This is the rule to redirect traffic from host a >> to b: >> >> rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 >> pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state >> >> If I try to get a telnet connection from my client 192.168.0.51 the >> connection gets stuck and nothing happens. This is the output of tcpdump >> on the pflog0 interface: >> >> # tcpdump -netttvvi pflog0 >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > >> 192.168.0.10.23: [|tcp] >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] >> >> Anybody has an idea whats wrong here? > > redirection only works if your pf box sees both directions of the connection. > In your case, however, 192.168.0.10 probably knows how to contact 192.168.0.51 > directly. So what happens is: > > .51 -> SYN (src=.51,dst=.250) -> pf -> SYN (src=.51,dst=.10) -> .10 > > <---------------------------- SYN/ACK (src=.10,dst=.51) <- > > But .51 is waiting for a SYN/ACK from .250. You can solve this by either: > - moving .10 into a separate LAN for which the pf box is the default gw > - userland reflection (e.g. nc(1) from inetd(8)) > - having your clients connect to the correct box in the first place > (split horizon DNS etc.) Thanks for your explanation, Max. I've added the following line to /etc/inetd.conf: telnet stream tcp nowait nobody /usr/bin/nc /usr/bin/nc -w 20 192.168.0.10 23 Works fine! I've tried the same thing with other protocols (e.g. SSH). Doing an scp transfer is really slow this way. Any ideas what could cause this issue? (this is not pf related anymore, but perhaps someone has a quick answer). Regards, Matthias From koitsu at FreeBSD.org Tue Nov 4 07:50:45 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Nov 4 07:50:51 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <49106ECF.4080803@adminlife.net> References: <491012AE.7000409@adminlife.net> <200811041139.10125.max@love2party.net> <49106ECF.4080803@adminlife.net> Message-ID: <20081104155043.GA51736@icarus.home.lan> On Tue, Nov 04, 2008 at 04:48:31PM +0100, Matthias Kellermann wrote: > Max Laier wrote: > > On Tuesday 04 November 2008 10:15:26 Matthias Kellermann wrote: > >> I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). > >> > >> I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in > >> a local network and want to forward one port from host a to host b. > >> > >> host a is the pf host. This is the rule to redirect traffic from host a > >> to b: > >> > >> rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 > >> pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state > >> > >> If I try to get a telnet connection from my client 192.168.0.51 the > >> connection gets stuck and nothing happens. This is the output of tcpdump > >> on the pflog0 interface: > >> > >> # tcpdump -netttvvi pflog0 > >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > >> 192.168.0.10.23: [|tcp] > >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > >> > >> Anybody has an idea whats wrong here? > > > > redirection only works if your pf box sees both directions of the connection. > > In your case, however, 192.168.0.10 probably knows how to contact 192.168.0.51 > > directly. So what happens is: > > > > .51 -> SYN (src=.51,dst=.250) -> pf -> SYN (src=.51,dst=.10) -> .10 > > > > <---------------------------- SYN/ACK (src=.10,dst=.51) <- > > > > But .51 is waiting for a SYN/ACK from .250. You can solve this by either: > > - moving .10 into a separate LAN for which the pf box is the default gw > > - userland reflection (e.g. nc(1) from inetd(8)) > > - having your clients connect to the correct box in the first place > > (split horizon DNS etc.) > > Thanks for your explanation, Max. > > I've added the following line to /etc/inetd.conf: > telnet stream tcp nowait nobody /usr/bin/nc /usr/bin/nc -w 20 > 192.168.0.10 23 > > Works fine! > > I've tried the same thing with other protocols (e.g. SSH). Doing an scp > transfer is really slow this way. Any ideas what could cause this issue? > (this is not pf related anymore, but perhaps someone has a quick answer). Simple: you've created a wonderful, beautiful bottleneck by using netcat as a form of buffering mechanism. You can tune netcat to your hearts content, and probably improve things a bit, but you're more or less screwed (to put it frankly). I highly recommend Max's first recommendation. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ermal.luci at gmail.com Tue Nov 4 07:53:53 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Tue Nov 4 07:53:59 2008 Subject: [PATCH] PF+dummynet In-Reply-To: <20081103060321.GA45414@server.vk2pj.dyndns.org> References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> <20081103060321.GA45414@server.vk2pj.dyndns.org> Message-ID: <9a542da30811040753m1a2728bcu365c65da8fb61721@mail.gmail.com> On Mon, Nov 3, 2008 at 7:03 AM, Peter Jeremy wrote: > On 2007-Oct-27 19:45:59 +0000, Ermal Lu?i wrote: >>Attached is the patch against -CURRENT for integrating PF with dummynet! >> >>It gives full dummynet support in pf.conf syntax and removes dummynet >>depndency to ipfw. > > I've recently found this and applied it to 7.1-PRERELEASE. There were > a few rejects and a couple of printf format problems which were all > quite easy to fix. I also found an incorrect getopt() string in > pfctl, incorrect PLR definition, and an uninitialised dnflow variable. > Actually using it presents some more problems. > > Firstly, if you have ipfw in the kernel then dummynet packets appear > to loop indefinitely. Disabling ipfw fixed this (I had built ipfw > into the kernel incase I couldn't get pf+dummy to work). > > The above left me with wierd delays and incorrect packet counts on the > rules. Further sleuthing shows that I'm falling foul of the state > rules that pf is creating - though the behaviour is still wierd. > > Given the following: > dnpipe 128 bandwidth 2Mb delay 500 queue 64KB > dnpipe 136 bandwidth 2Mb delay 500 queue 64KB > r1) pass in quick on vlan128 from any to 192.168.136.0/22 dnpipe 128 > r2) pass in quick on vlan136 from any to 192.168.128.0/22 dnpipe 136 > > I get the following: > t0 ICMP ECHO REQ a->b -> > match r1: pass to pipe 128 (delay 500msec), create state s1 > t+.5s -> ICMP ECHO REQ a->b > t+.5s <- ICMP ECHO RESP b->a > match r2: pass to pipe 136 (delay 500msec), create state s2 > match s1: pass to pipe 128 (delay 500msec) > t+1.5s ICMP ECHO RESP b->a <- > > t2 ICMP ECHO REQ a->b -> > match s1: pass to pipe 128 (delay 500msec) > match s2: pass to pipe 136 (delay 500msec) > t2+1s -> ICMP ECHO REQ a->b > t2+1s <- ICMP ECHO RESP b->a > match s2: pass to pipe 136 (delay 500msec) > match s1: pass to pipe 128 (delay 500msec) > t2+2s ICMP ECHO RESP b->a <- > > I managed to fix ICMP by testing that the rule direction matches the > packet direction before passing it to dummynet. Unfortunately, this > means that TCP only goes through dummynet in one direction (since TCP > only has a single state entry). I think the duplicate ICMP state entry > is a bug in pf. And the dummynet patches need to support two pipes > (one for each direction). I am still looking into this. actually this is the latest against RELENG_7 which is confirmed to work with full features of pf(4) like route-to/reply-to etc... http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/dummynet.RELENG_7.diff?rev=1.5 The problem that is that i have yet to find time to post it here but since you have interes here it is. Its problem is that from the whole patches here http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/ you need to apply these others before it applies cleanly fairq.RELENG_7.diff <-- Mathew Dillon ALTQ_FAIRQ discipline dscp.RELENG_7.diff <-- a simple dscp syntax addition queuestats.RELENG_7.diff <-- you do not need this actually hfscconfig.RELENG_7.diff <-- this is on pfSense and only discussed with Max killifstates.RELENG_7.diff <-- pfctl -b $ip addition to kill states from the gateway ip(interface ip) dummynet.RELENG_7.diff <-- dummynet(4) divert.RELENG_7.diff <-- divert(4) these are incorporated in the latest snapshots of pfSense but if you want to do the patching yourself I have no problems with it. Since i am sending this mail there is another patch that might interest you http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/pfil.RELENG_7.diff?rev=1.1 it allows to reorder pfil hook or even disable one of them. Its a long time i am saying i will make them ready for review and commit for FreeBSD but still not found it. So i cannot state more on this. Feedback is always welcomed. The syntax on the this new patch is pass in ........ keep state dnpipe 1 or pass in ........ keep state dnpipe (1 ) or pass in ........ keep state dnpipe (1,3) where the latest pipe/queue 1 applies to in direction and pipe/queue 3 applies to out direction. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > -- Ermal From bsemene at cyanide-studio.com Tue Nov 4 07:56:39 2008 From: bsemene at cyanide-studio.com (Bastien Semene) Date: Tue Nov 4 07:56:45 2008 Subject: can't add a port forwarding Message-ID: <49106B68.2060007@cyanide-studio.com> Hi everyone, I'm currently facing a weird problem. I have a pf box acting as a gateway for some services and want to add a port forwarding for https. So I added the following rule : rdr pass on $ext_if proto tcp from any to any port 443 -> $atlas_ip //variables are correct since I have a similar rule for port 80. The "pfctl -s nat" shows this : nat on bge0 inet from 10.1.8.1 to any -> "external_interface_ip" rdr pass on bge0 inet proto tcp from any to any port = http -> 10.1.8.1 rdr pass on bge0 inet proto tcp from any to any port = https -> 10.1.8.1 An Nmap from outside shows this : # nmap -P0 -p80,443,17900 "external_interface_ip" Starting Nmap 4.20 ( http://insecure.org ) at 2008-11-04 16:22 CET Interesting ports on "external_interface_ip": PORT STATE SERVICE 80/tcp open http 443/tcp closed https 17900/tcp filtered unknown I tried reloading pf rules with "pfctl -F all -f /etc/pf.conf", restarting the machine, but nothing changed. The securelevel is also at -1, so pf should take the changes into account. And of course the destination https server receives nothing on https port. http and preconfigured nat/forwards works perfectly. I tried to comment the "scrub in all" option, but because the rdr line doesn't seem to be affected, I'm not sure this one is. If someone has an idea or direction to follow I take every piece of thought. Thanks all. From max at love2party.net Tue Nov 4 08:11:15 2008 From: max at love2party.net (Max Laier) Date: Tue Nov 4 08:11:23 2008 Subject: rdr rule does not work (bad hdr length) In-Reply-To: <20081104155043.GA51736@icarus.home.lan> References: <491012AE.7000409@adminlife.net> <49106ECF.4080803@adminlife.net> <20081104155043.GA51736@icarus.home.lan> Message-ID: <200811041711.12983.max@love2party.net> On Tuesday 04 November 2008 16:50:43 Jeremy Chadwick wrote: > On Tue, Nov 04, 2008 at 04:48:31PM +0100, Matthias Kellermann wrote: ... > > > > Thanks for your explanation, Max. > > > > I've added the following line to /etc/inetd.conf: > > telnet stream tcp nowait nobody /usr/bin/nc /usr/bin/nc -w 20 > > 192.168.0.10 23 > > > > Works fine! > > > > I've tried the same thing with other protocols (e.g. SSH). Doing an scp > > transfer is really slow this way. Any ideas what could cause this issue? > > (this is not pf related anymore, but perhaps someone has a quick answer). > > Simple: you've created a wonderful, beautiful bottleneck by using netcat > as a form of buffering mechanism. You can tune netcat to your hearts > content, and probably improve things a bit, but you're more or less > screwed (to put it frankly). > > I highly recommend Max's first recommendation. Basically, yes. Userland redirection is a hack. It's easy to setup and will get you going. There are more efficient implementations than netcat - e.g. rinetd from ports. Ultimately, however, if you are looking for throughput without too much impact on the forwarding box etc. ... you must use a different mechanism - such as in-kernel redirection as provided by pf. For that you need a different network layout, however. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From omasnjak at gmail.com Sun Nov 9 02:03:24 2008 From: omasnjak at gmail.com (Elvir Kuric) Date: Sun Nov 9 02:03:31 2008 Subject: Blocking udp flood trafiic using pf, hints welcome Message-ID: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Hi all, I am playing with pf tool on openbsd/freebsd platforms and it is super tool for firewalls. On thing is interesting for me, and I am hopping someone has expeience with this. If I say block log all block in log (all) quick on $ext_if proto udp from any to $ext_if this would block all traffic on $ext_if, but on my ext_if I recive a lot of ( huge amount ) of udp generated traffic which make me a lot of problems. I also tryed to add small pipe and play with ALTQ to handle this but it did not help a lot. Also I know that every packet which hit my ext_if should be processed ( or least take a little processor resources, if I block it with keyword quick ), but I am wondering is there some way to decrease impact on system when a lot of packets arive in short time. My question would be, what are your experinces with battling against boring udp flooders ? Platform are FreeBSD / OpenBSD and all works like a charm except time to time, stupid udp flood atacks. Any suggestion is welcome, With Regards, Elvir Kuric From omasnjak at gmail.com Sun Nov 9 03:05:40 2008 From: omasnjak at gmail.com (Elvir Kuric) Date: Sun Nov 9 03:05:45 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <425228071.20081109114720@rulez.sk> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <425228071.20081109114720@rulez.sk> Message-ID: <1814bfe70811090305y48b493c8h501f8d031510e62d@mail.gmail.com> Hello Daniel, thank you for answer, I understand, but I know pf is very powerful tool I want to make some workaround using pf to perform blocking udp floods, rule creation is not problem and I understand pf syntax. ISP also use I suppose pf as firewall on their machines, so if they can, I/we using pf aslo can make that :). I am reading manuals, HOWTOs, because I know it must be some way to make what I want using pf firewall tool Kind regards, Elvir On Sun, Nov 9, 2008 at 11:47 AM, Daniel Gerzo wrote: > Hello Elvir, > > Sunday, November 9, 2008, 10:37:29 AM, you wrote: > >> My question would be, what are your experinces with battling against >> boring udp flooders ? Platform are FreeBSD / OpenBSD and all works >> like a charm except time to time, stupid udp flood atacks. > > Ask your ISP to block UDP upfront, so that it won't hit you at all. > You probably don't need incomming UDP anyway... > > -- > Best regards, > Daniel mailto:danger@FreeBSD.org > > From danger at FreeBSD.org Sun Nov 9 03:07:26 2008 From: danger at FreeBSD.org (Daniel Gerzo) Date: Sun Nov 9 03:07:32 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Message-ID: <425228071.20081109114720@rulez.sk> Hello Elvir, Sunday, November 9, 2008, 10:37:29 AM, you wrote: > My question would be, what are your experinces with battling against > boring udp flooders ? Platform are FreeBSD / OpenBSD and all works > like a charm except time to time, stupid udp flood atacks. Ask your ISP to block UDP upfront, so that it won't hit you at all. You probably don't need incomming UDP anyway... -- Best regards, Daniel mailto:danger@FreeBSD.org From koitsu at FreeBSD.org Sun Nov 9 03:21:27 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Nov 9 03:21:33 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Message-ID: <20081109112125.GA36707@icarus.home.lan> On Sun, Nov 09, 2008 at 10:37:29AM +0100, Elvir Kuric wrote: > I am playing with pf tool on openbsd/freebsd platforms and it is super > tool for firewalls. On thing is interesting for me, and I am hopping > someone has expeience with this. > > If I say > > block log all > block in log (all) quick on $ext_if proto udp from any to $ext_if > > this would block all traffic on $ext_if, but on my ext_if I recive a > lot of ( huge amount ) of udp generated traffic which make me a lot > of problems. > I also tryed to add small pipe and play with ALTQ to handle this but > it did not help a lot. Also I know that every packet which hit my > ext_if should be > processed ( or least take a little processor resources, if I block > it with keyword quick ), but I am wondering is there some way to > decrease impact on system > when a lot of packets arive in short time. > > My question would be, what are your experinces with battling against > boring udp flooders ? Platform are FreeBSD / OpenBSD and all works > like a charm except time to time, stupid udp flood atacks. First, you should be very careful with use of the "log" directive on your rules. I've personally witnessed an attack which triggered "log" entries in block rules causing pflog to log at such a tremendous/fast rate, that newsyslog could not rotate+compress the log files fast enough, resulting in CPU maxing out and so on (a true self-induced denial-of-service). Consider this warning. :-) Secondly, and this is more a direct answer of your question: I believe what you're referring to is a UDP-based DoS attack against your FreeBSD machine(s). The "block" directives you're using will only stop your FreeBSD box from responding to those packets (whatever you do, silently deny those packets; do not use "reject", or else your box will be trying to send back denial responses to the attackers, which just makes the problem worse). It *cannot* solve the problem of your network connection becoming saturated. Your next question will be: "okay, so how do I solve this problem?" This is where it gets both technical and political. There are two things to do first: 1) See if the attacks are distributed (multiple IPs or even spoofed IPs hitting your machine with UDP packets). If they're distributed or spoofed, you're out of luck. If the packets are legitimate (e.g. some compromised machine on the Internet is being used to attack you), you need to find out who own that IP address, and contact them. ARIN (WHOIS) can be of help here. Pray they have an abuse department. If you do not get a prompt response (24-48 hours), try to figure out who their upstream network provider is, and send them a similar message. Continue up the chain until you get a response. Phone calls (even international) often work wonders decreasing mitigation time. 2) Investigate your own machine. I cannot stress this enough. Most DoS attacks I've seen in my years ARE NOT random -- there's a reason they happen. The majority of attacks I've seen involve IRC in some way, either as a central cause of attack (arguments, channel takeovers, whatever), or indirectly (a compromised account on your machine). If your machine is a shell box for friends/customers, I highly recommend considering *not* permitting IRC from it; this includes bouncers and eggdrops. Many IRC-induced attacks are done against a machine solely to knock it offline (so the user on IRC pings out for a channel takeover, or just to keep the user from getting back on IRC). And if your machine(s) run IRC servers... well, this is one of the many dangers in hosting a server. You have to weigh what's more important to you in this case: IRC, or the availability of your machines. I speak from personal experience as someone who used to administrate a public EFnet server, and as someone who has used IRC for the past 16 years. Whichever matters to you more is what you should stick with. The second most common reason for attack I've seen are controversial websites or domain names -- things that induce arguments, controversy or heated discussions, or are of a "shady" nature and would bring shady or questionable attention to you (e.g. wehaveeggdropshellz.com). If you host anything like this, consider suspending it, or removing the customer due to incidents which cause the network to become unavailable. Remember: one customer/user is not worth sacrificing all the rest. Finally: work with your own service/uplink provider. In the case of a very large-scale attack, your ISP will need to do the filtering to ensure that the packets never reach your machine. "What can they filter on if it's DDoS?" Good question -- very little. But your uplink should at least be told of the problem, both out of respect, and for your own benefit (especially if you are billed for *incoming* traffic!) If you don't find decent answers here, I highly recommend freebsd-net or freebsd-isp. Others may have better advice. Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the problem is that in this day and age, it can breed trouble. I don't want to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm simply pointing out the realities that are involved with IRC in this day and age. The degree of anonymity DoS and IRC provide sometimes brings out the worst in people, and that's sad. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From glen.j.barber at gmail.com Sun Nov 9 03:33:54 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Sun Nov 9 03:34:00 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Message-ID: <4ad871310811090309le19b2bwd2de855155b3797b@mail.gmail.com> On Sun, Nov 9, 2008 at 4:37 AM, Elvir Kuric wrote: > Hi all, > > I am playing with pf tool on openbsd/freebsd platforms and it is super > tool for firewalls. On thing is interesting for me, and I am hopping > someone has expeience with this. > > If I say > > block log all > block in log (all) quick on $ext_if proto udp from any to $ext_if > > this would block all traffic on $ext_if, but on my ext_if I recive a > lot of ( huge amount ) of udp generated traffic which make me a lot > of problems. > I also tryed to add small pipe and play with ALTQ to handle this but > it did not help a lot. Also I know that every packet which hit my > ext_if should be > processed ( or least take a little processor resources, if I block > it with keyword quick ), but I am wondering is there some way to > decrease impact on system > when a lot of packets arive in short time. > > My question would be, what are your experinces with battling against > boring udp flooders ? Platform are FreeBSD / OpenBSD and all works > like a charm except time to time, stupid udp flood atacks. > Not sure if this will help in your situation, but you could try setting the 'blackhole' for UDP. (There is also one for TCP.) net.inet.tcp.blackhole net.inet.udp.blackhole -- Glen Barber "If you have any trouble sounding condescending, find a Unix user to show you how it's done." --Scott Adams From omasnjak at gmail.com Sun Nov 9 05:16:33 2008 From: omasnjak at gmail.com (Elvir Kuric) Date: Sun Nov 9 05:16:40 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <4ad871310811090309le19b2bwd2de855155b3797b@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <4ad871310811090309le19b2bwd2de855155b3797b@mail.gmail.com> Message-ID: <1814bfe70811090516m78bdec90wa464606bdfa6c1ea@mail.gmail.com> Hi Glen, Thank you for mail and help, actually I do not have these options on my openBSD box, on freeBSD box there are and I will implennt this. Thank you very much Kind regards, Elvir Kuric On Sun, Nov 9, 2008 at 12:09 PM, Glen Barber wrote: > On Sun, Nov 9, 2008 at 4:37 AM, Elvir Kuric wrote: >> Hi all, >> >> I am playing with pf tool on openbsd/freebsd platforms and it is super >> tool for firewalls. On thing is interesting for me, and I am hopping >> someone has expeience with this. >> >> If I say >> >> block log all >> block in log (all) quick on $ext_if proto udp from any to $ext_if >> >> this would block all traffic on $ext_if, but on my ext_if I recive a >> lot of ( huge amount ) of udp generated traffic which make me a lot >> of problems. >> I also tryed to add small pipe and play with ALTQ to handle this but >> it did not help a lot. Also I know that every packet which hit my >> ext_if should be >> processed ( or least take a little processor resources, if I block >> it with keyword quick ), but I am wondering is there some way to >> decrease impact on system >> when a lot of packets arive in short time. >> >> My question would be, what are your experinces with battling against >> boring udp flooders ? Platform are FreeBSD / OpenBSD and all works >> like a charm except time to time, stupid udp flood atacks. >> > > Not sure if this will help in your situation, but you could try > setting the 'blackhole' for UDP. (There is also one for TCP.) > > net.inet.tcp.blackhole > net.inet.udp.blackhole > > -- > Glen Barber > > "If you have any trouble sounding condescending, find a Unix user to > show you how it's done." > --Scott Adams > From omasnjak at gmail.com Sun Nov 9 05:44:54 2008 From: omasnjak at gmail.com (Elvir Kuric) Date: Sun Nov 9 05:45:01 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <20081109112125.GA36707@icarus.home.lan> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> Message-ID: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> Hello Jeremy, Thank you for your time and your answer, > First, you should be very careful with use of the "log" directive on > your rules. I've personally witnessed an attack which triggered "log" > entries in block rules causing pflog to log at such a tremendous/fast > rate, that newsyslog could not rotate+compress the log files fast > enough, resulting in CPU maxing out and so on (a true self-induced > denial-of-service). Consider this warning. :-) I absolutely agree with you regarding logging, and I do not practice this, only logging specific data. The biggest problem with this DoS attacks ( udp floods ) is, processor must spend some time on packet arrive ( even dropping will take some processor power ). > > Secondly, and this is more a direct answer of your question: I believe > what you're referring to is a UDP-based DoS attack against your FreeBSD > machine(s). Actually it is OpenBSD, but it is not important for this case. > > The "block" directives you're using will only stop your FreeBSD box from > responding to those packets (whatever you do, silently deny those > packets; do not use "reject", or else your box will be trying to send > back denial responses to the attackers, which just makes the problem > worse). It *cannot* solve the problem of your network connection > becoming saturated. Block works fantastic, connection goes down due to milions of packets arrived. > > Your next question will be: "okay, so how do I solve this problem?" This > is where it gets both technical and political. There are two things to > do first: > > 1) See if the attacks are distributed (multiple IPs or even spoofed IPs > hitting your machine with UDP packets). If they're distributed or > spoofed, you're out of luck. > > If the packets are legitimate (e.g. some compromised machine on the > Internet is being used to attack you), you need to find out who own that > IP address, and contact them. ARIN (WHOIS) can be of help here. Pray > they have an abuse department. If you do not get a prompt response > (24-48 hours), try to figure out who their upstream network provider is, > and send them a similar message. Continue up the chain until you get a > response. Phone calls (even international) often work wonders > decreasing mitigation time. > > 2) Investigate your own machine. I cannot stress this enough. Most DoS > attacks I've seen in my years ARE NOT random -- there's a reason they > happen. > > The majority of attacks I've seen involve IRC in some way, either as a > central cause of attack (arguments, channel takeovers, whatever), or > indirectly (a compromised account on your machine). If your machine is > a shell box for friends/customers, I highly recommend considering *not* > permitting IRC from it; this includes bouncers and eggdrops. > > Many IRC-induced attacks are done against a machine solely to knock it > offline (so the user on IRC pings out for a channel takeover, or just to > keep the user from getting back on IRC). > > And if your machine(s) run IRC servers... well, this is one of the many > dangers in hosting a server. You have to weigh what's more important to > you in this case: IRC, or the availability of your machines. I speak > from personal experience as someone who used to administrate a public > EFnet server, and as someone who has used IRC for the past 16 years. > Whichever matters to you more is what you should stick with. > > The second most common reason for attack I've seen are controversial > websites or domain names -- things that induce arguments, controversy or > heated discussions, or are of a "shady" nature and would bring shady > or questionable attention to you (e.g. wehaveeggdropshellz.com). If > you host anything like this, consider suspending it, or removing the > customer due to incidents which cause the network to become unavailable. > Remember: one customer/user is not worth sacrificing all the rest. > > Finally: work with your own service/uplink provider. In the case of a > very large-scale attack, your ISP will need to do the filtering to > ensure that the packets never reach your machine. "What can they filter > on if it's DDoS?" Good question -- very little. But your uplink should > at least be told of the problem, both out of respect, and for your own > benefit (especially if you are billed for *incoming* traffic!) > > If you don't find decent answers here, I highly recommend freebsd-net > or freebsd-isp. Others may have better advice. No IRC is present here, or similar staff it is just firewal/router runing at the edge of internal network. Also on machines in internal network there is not some, "interesting " stuff. Thank you very much for your answer it is very helpful. > > Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the > problem is that in this day and age, it can breed trouble. I don't want > to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm > simply pointing out the realities that are involved with IRC in this day > and age. The degree of anonymity DoS and IRC provide sometimes brings > out the worst in people, and that's sad. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Kind regards, Elvir Kuric From peter at allicient.co.uk Sun Nov 9 10:18:00 2008 From: peter at allicient.co.uk (Peter Maxwell) Date: Sun Nov 9 10:18:06 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> Message-ID: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> Hi Elvir, I'd second the advice given further up the thread about getting your ISP to filter upstream - that's about the only really effective solution. Once UDP packets hit your firewall's external interface there's very little you can do about it. The only other advice I could offer is; i) Make sure the block rule for UDP gets hit first or very early in the rulebase (this can actually make a lot of difference for large rule sets) - and that the packet is dropped immediately without having to traverse the rest of the rule set (i.e. use "block quick" and "set block-policy drop"). ii) Ensure you're using a good NIC, the CPU offload abilities in Intel (and I think Broadcom) cards can reduce the impact on CPU generally. iii) Repeating the advice given from others in the thread above, only use logging very carefully. iv) Check the limits on the state table are high enough (and that you have enough memory to accomodate this) - its not entirely uncommon for a DDoS attack to completely fill the state table and block legitimate traffic (might be worthwhile checking that this isn't happening). v) There may be some mileage in tinkering with the udp timeout values, but it could also be counter productive if the state processing is faster than the initial rule processing - so you'd have to test this for yourself. If the bad traffic is coming from a massive range of source addresses (spoofed or not), then you're better clearing them from state quickly - if there is only a selection of source IPs then keep them in state longer. vi) Is your connection got enough bandwidth to handle legitimate traffic alongside the DoS traffic - if it doesn't you're stuck anyway. viii) Can you upgrade the CPU on the box? The ALTQ facilities will not help you with this. ALTQ only queues *outgoing packets* so cannot help with incoming UDP. The reason you may sometimes see advice that ALTQ can manage incoming packets is to do with TCP return ACK packets, you can ensure the return ACK packets don't have to compete with outgoing traffic by restricting outgoing bandwidth just a little - and hence speeding up your TCP connections. But again, no use here. To be honest I'm slightly surprised that CPU resource is the first limit you've hit, its usually going to be bandwidth. Packets filters are generally very very fast at doing simple drops - is the actual transfer of data or VPN stuff that usually kills a firewall. How wide is your connection? Cheers, Peter ---------------------------------- http://www.allicient.co.uk/ 2008/11/9 Elvir Kuric : > Hello Jeremy, > > Thank you for your time and your answer, > > >> First, you should be very careful with use of the "log" directive on >> your rules. I've personally witnessed an attack which triggered "log" >> entries in block rules causing pflog to log at such a tremendous/fast >> rate, that newsyslog could not rotate+compress the log files fast >> enough, resulting in CPU maxing out and so on (a true self-induced >> denial-of-service). Consider this warning. :-) > > I absolutely agree with you regarding logging, and I do not practice > this, only logging specific data. The biggest problem with this DoS > attacks ( udp floods ) is, processor > must spend some time on packet arrive ( even dropping will take some > processor power ). > >> >> Secondly, and this is more a direct answer of your question: I believe >> what you're referring to is a UDP-based DoS attack against your FreeBSD >> machine(s). > > Actually it is OpenBSD, but it is not important for this case. > > >> The "block" directives you're using will only stop your FreeBSD box from >> responding to those packets (whatever you do, silently deny those >> packets; do not use "reject", or else your box will be trying to send >> back denial responses to the attackers, which just makes the problem >> worse). It *cannot* solve the problem of your network connection >> becoming saturated. > > Block works fantastic, connection goes down due to milions of packets arrived. > >> >> Your next question will be: "okay, so how do I solve this problem?" This >> is where it gets both technical and political. There are two things to >> do first: >> >> 1) See if the attacks are distributed (multiple IPs or even spoofed IPs >> hitting your machine with UDP packets). If they're distributed or >> spoofed, you're out of luck. >> >> If the packets are legitimate (e.g. some compromised machine on the >> Internet is being used to attack you), you need to find out who own that >> IP address, and contact them. ARIN (WHOIS) can be of help here. Pray >> they have an abuse department. If you do not get a prompt response >> (24-48 hours), try to figure out who their upstream network provider is, >> and send them a similar message. Continue up the chain until you get a >> response. Phone calls (even international) often work wonders >> decreasing mitigation time. >> >> 2) Investigate your own machine. I cannot stress this enough. Most DoS >> attacks I've seen in my years ARE NOT random -- there's a reason they >> happen. > >> >> The majority of attacks I've seen involve IRC in some way, either as a >> central cause of attack (arguments, channel takeovers, whatever), or >> indirectly (a compromised account on your machine). If your machine is >> a shell box for friends/customers, I highly recommend considering *not* >> permitting IRC from it; this includes bouncers and eggdrops. >> >> Many IRC-induced attacks are done against a machine solely to knock it >> offline (so the user on IRC pings out for a channel takeover, or just to >> keep the user from getting back on IRC). >> >> And if your machine(s) run IRC servers... well, this is one of the many >> dangers in hosting a server. You have to weigh what's more important to >> you in this case: IRC, or the availability of your machines. I speak >> from personal experience as someone who used to administrate a public >> EFnet server, and as someone who has used IRC for the past 16 years. >> Whichever matters to you more is what you should stick with. >> >> The second most common reason for attack I've seen are controversial >> websites or domain names -- things that induce arguments, controversy or >> heated discussions, or are of a "shady" nature and would bring shady >> or questionable attention to you (e.g. wehaveeggdropshellz.com). If >> you host anything like this, consider suspending it, or removing the >> customer due to incidents which cause the network to become unavailable. >> Remember: one customer/user is not worth sacrificing all the rest. >> >> Finally: work with your own service/uplink provider. In the case of a >> very large-scale attack, your ISP will need to do the filtering to >> ensure that the packets never reach your machine. "What can they filter >> on if it's DDoS?" Good question -- very little. But your uplink should >> at least be told of the problem, both out of respect, and for your own >> benefit (especially if you are billed for *incoming* traffic!) >> >> If you don't find decent answers here, I highly recommend freebsd-net >> or freebsd-isp. Others may have better advice. > > No IRC is present here, or similar staff it is just firewal/router > runing at the edge of internal network. > Also on machines in internal network there is not some, "interesting " stuff. > > Thank you very much for your answer it is very helpful. > > > > >> >> Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the >> problem is that in this day and age, it can breed trouble. I don't want >> to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm >> simply pointing out the realities that are involved with IRC in this day >> and age. The degree of anonymity DoS and IRC provide sometimes brings >> out the worst in people, and that's sad. >> >> -- >> | Jeremy Chadwick jdc at parodius.com | >> | Parodius Networking http://www.parodius.com/ | >> | UNIX Systems Administrator Mountain View, CA, USA | >> | Making life hard for others since 1977. PGP: 4BD6C0CB | >> >> > > Kind regards, > > Elvir Kuric > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From fox at verio.net Sun Nov 9 12:35:46 2008 From: fox at verio.net (David DeSimone) Date: Sun Nov 9 12:35:52 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> Message-ID: <20081109200659.GA8477@verio.net> Elvir Kuric wrote: > > I absolutely agree with you regarding logging, and I do not practice > this, only logging specific data. The biggest problem with this DoS > attacks ( udp floods ) is, processor must spend some time on packet > arrive ( even dropping will take some processor power ). You may want to consider adding "keep state" to your "block log" rules. If you keep state on the blocked packets, only the first packet that is blocked will get logged; the others will be blocked statefully without consulting the rulebase, which may save some processing time. Note that "keep state" is only implicit on "pass" rules, you must add it on "block" rules. > No IRC is present here, or similar staff it is just firewal/router > runing at the edge of internal network. > > Also on machines in internal network there is not some, "interesting " > stuff. I suppose what you mean is "No IRC is present here" that you know of. A nefarious hacker can actually install these tools in ways that you are not aware of, and this is often the cause of any DOS attacks you receive. I agree with the above, DOS attacks do not typically happen without reason. There is probably a reason that your system is coming under attack, and you need to do some real forensic examination to make sure that your systems (all of them, the ones that forward traffic through this BSD gateway of yours) are clean and not doing anything they shouldn't be. It's easy to say that you did not set up anything bad on your systems, but can you really say with certainty that no one has broken into your systems and installed something you don't know about? -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From fox at verio.net Sun Nov 9 13:07:10 2008 From: fox at verio.net (David DeSimone) Date: Sun Nov 9 13:07:16 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <49174EEA.2040609@gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <20081109200659.GA8477@verio.net> <49174EEA.2040609@gmail.com> Message-ID: <20081109210708.GB8477@verio.net> Eric Williams wrote: > > David DeSimone wrote: > > You may want to consider adding "keep state" to your "block log" rules. > > Doesn't seem to work, it just gives "keep state on block rules doesn't > make sense" as an error. I guess what I mean is that "blog log" rules can keep state. So that they don't log every packet, just the first packet that creates the state. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From purpleshadow100 at gmail.com Sun Nov 9 13:30:01 2008 From: purpleshadow100 at gmail.com (Eric Williams) Date: Sun Nov 9 13:30:08 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <20081109200659.GA8477@verio.net> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <20081109200659.GA8477@verio.net> Message-ID: <49174EEA.2040609@gmail.com> David DeSimone wrote: > You may want to consider adding "keep state" to your "block log" rules. > If you keep state on the blocked packets, only the first packet that is > blocked will get logged; the others will be blocked statefully without > consulting the rulebase, which may save some processing time. > > Note that "keep state" is only implicit on "pass" rules, you must add it > on "block" rules Doesn't seem to work, it just gives "keep state on block rules doesn't make sense" as an error. From sebastian.tymkow at gmail.com Mon Nov 10 00:38:41 2008 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Mon Nov 10 00:38:48 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Message-ID: <692660060811100015p140b4d7bma034b32a25504ce4@mail.gmail.com> I wonder how does udp.blackhole working with DNS. Does it interfere bind or no ? Best regards, Sebastian Tymkow From koitsu at FreeBSD.org Mon Nov 10 00:49:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Nov 10 00:49:47 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <692660060811100015p140b4d7bma034b32a25504ce4@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <692660060811100015p140b4d7bma034b32a25504ce4@mail.gmail.com> Message-ID: <20081110084938.GA62562@icarus.home.lan> On Mon, Nov 10, 2008 at 09:15:08AM +0100, Sebastian Tymk?w wrote: > I wonder how does udp.blackhole working with DNS. Does it interfere bind or > no ? No. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From omasnjak at gmail.com Mon Nov 10 01:20:13 2008 From: omasnjak at gmail.com (Elvir Kuric) Date: Mon Nov 10 01:20:23 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> Message-ID: <1814bfe70811100120if6b7102p54905f1f7dde98ae@mail.gmail.com> Hi Peter, Thank you for this excessive answer and it is really helpful. On Sun, Nov 9, 2008 at 6:47 PM, Peter Maxwell wrote: > Hi Elvir, > > I'd second the advice given further up the thread about getting your > ISP to filter upstream - that's about the only really effective > solution. Once UDP packets hit your firewall's external interface > there's very little you can do about it. > > The only other advice I could offer is; > > i) Make sure the block rule for UDP gets hit first or very early in > the rulebase (this can actually make a lot of difference for large > rule sets) - and that the packet is dropped immediately without having > to traverse the rest of the rule set (i.e. use "block quick" and "set > block-policy drop"). > UDP drob rule is at very begginig, it is clear to stop packets which are not necessary in network as soon as possible just to prevent them to " eat " CPU, memory resources, etc > ii) Ensure you're using a good NIC, the CPU offload abilities in Intel > (and I think Broadcom) cards can reduce the impact on CPU generally. This could be weak point in chain. I will try to change some hardware, maybe the whole machine, it is not some representative hardware. But for purpose of filtering ( with udp hosts ) it works super. > > iii) Repeating the advice given from others in the thread above, only > use logging very carefully. > > iv) Check the limits on the state table are high enough (and that you > have enough memory to accomodate this) - its not entirely uncommon for > a DDoS attack to completely fill the state table and block legitimate > traffic (might be worthwhile checking that this isn't happening). > > v) There may be some mileage in tinkering with the udp timeout values, > but it could also be counter productive if the state processing is > faster than the initial rule processing - so you'd have to test this > for yourself. If the bad traffic is coming from a massive range of > source addresses (spoofed or not), then you're better clearing them > from state quickly - if there is only a selection of source IPs then > keep them in state longer. > > vi) Is your connection got enough bandwidth to handle legitimate > traffic alongside the DoS traffic - if it doesn't you're stuck anyway. > > viii) Can you upgrade the CPU on the box? > As I said, I will upgrade box, change it, with some better, this one is not very good. > > The ALTQ facilities will not help you with this. ALTQ only queues > *outgoing packets* so cannot help with incoming UDP. The reason you > may sometimes see advice that ALTQ can manage incoming packets is to > do with TCP return ACK packets, you can ensure the return ACK packets > don't have to compete with outgoing traffic by restricting outgoing > bandwidth just a little - and hence speeding up your TCP connections. > But again, no use here. Regarding this all is clear, UDP is connectionless so tracking it will not be useful, :) and as you write is could help just to manipulate with ack answers in tcp connections > > To be honest I'm slightly surprised that CPU resource is the first > limit you've hit, its usually going to be bandwidth. Packets filters > are generally very very fast at doing simple drops - is the actual > transfer of data or VPN stuff that usually kills a firewall. How wide > is your connection? > 1Mb/2Mb > Cheers, > > Peter > > ---------------------------------- > http://www.allicient.co.uk/ > Nice regards, Elvir Kuric > > > > > > > > > 2008/11/9 Elvir Kuric : >> Hello Jeremy, >> >> Thank you for your time and your answer, >> >> >>> First, you should be very careful with use of the "log" directive on >>> your rules. I've personally witnessed an attack which triggered "log" >>> entries in block rules causing pflog to log at such a tremendous/fast >>> rate, that newsyslog could not rotate+compress the log files fast >>> enough, resulting in CPU maxing out and so on (a true self-induced >>> denial-of-service). Consider this warning. :-) >> >> I absolutely agree with you regarding logging, and I do not practice >> this, only logging specific data. The biggest problem with this DoS >> attacks ( udp floods ) is, processor >> must spend some time on packet arrive ( even dropping will take some >> processor power ). >> >>> >>> Secondly, and this is more a direct answer of your question: I believe >>> what you're referring to is a UDP-based DoS attack against your FreeBSD >>> machine(s). >> >> Actually it is OpenBSD, but it is not important for this case. >> > >>> The "block" directives you're using will only stop your FreeBSD box from >>> responding to those packets (whatever you do, silently deny those >>> packets; do not use "reject", or else your box will be trying to send >>> back denial responses to the attackers, which just makes the problem >>> worse). It *cannot* solve the problem of your network connection >>> becoming saturated. >> >> Block works fantastic, connection goes down due to milions of packets arrived. >> >>> >>> Your next question will be: "okay, so how do I solve this problem?" This >>> is where it gets both technical and political. There are two things to >>> do first: >>> >>> 1) See if the attacks are distributed (multiple IPs or even spoofed IPs >>> hitting your machine with UDP packets). If they're distributed or >>> spoofed, you're out of luck. >>> >>> If the packets are legitimate (e.g. some compromised machine on the >>> Internet is being used to attack you), you need to find out who own that >>> IP address, and contact them. ARIN (WHOIS) can be of help here. Pray >>> they have an abuse department. If you do not get a prompt response >>> (24-48 hours), try to figure out who their upstream network provider is, >>> and send them a similar message. Continue up the chain until you get a >>> response. Phone calls (even international) often work wonders >>> decreasing mitigation time. >>> >>> 2) Investigate your own machine. I cannot stress this enough. Most DoS >>> attacks I've seen in my years ARE NOT random -- there's a reason they >>> happen. >> >>> >>> The majority of attacks I've seen involve IRC in some way, either as a >>> central cause of attack (arguments, channel takeovers, whatever), or >>> indirectly (a compromised account on your machine). If your machine is >>> a shell box for friends/customers, I highly recommend considering *not* >>> permitting IRC from it; this includes bouncers and eggdrops. >>> >>> Many IRC-induced attacks are done against a machine solely to knock it >>> offline (so the user on IRC pings out for a channel takeover, or just to >>> keep the user from getting back on IRC). >>> >>> And if your machine(s) run IRC servers... well, this is one of the many >>> dangers in hosting a server. You have to weigh what's more important to >>> you in this case: IRC, or the availability of your machines. I speak >>> from personal experience as someone who used to administrate a public >>> EFnet server, and as someone who has used IRC for the past 16 years. >>> Whichever matters to you more is what you should stick with. >>> >>> The second most common reason for attack I've seen are controversial >>> websites or domain names -- things that induce arguments, controversy or >>> heated discussions, or are of a "shady" nature and would bring shady >>> or questionable attention to you (e.g. wehaveeggdropshellz.com). If >>> you host anything like this, consider suspending it, or removing the >>> customer due to incidents which cause the network to become unavailable. >>> Remember: one customer/user is not worth sacrificing all the rest. >>> >>> Finally: work with your own service/uplink provider. In the case of a >>> very large-scale attack, your ISP will need to do the filtering to >>> ensure that the packets never reach your machine. "What can they filter >>> on if it's DDoS?" Good question -- very little. But your uplink should >>> at least be told of the problem, both out of respect, and for your own >>> benefit (especially if you are billed for *incoming* traffic!) >>> >>> If you don't find decent answers here, I highly recommend freebsd-net >>> or freebsd-isp. Others may have better advice. >> >> No IRC is present here, or similar staff it is just firewal/router >> runing at the edge of internal network. >> Also on machines in internal network there is not some, "interesting " stuff. >> >> Thank you very much for your answer it is very helpful. >> >> >> >> >>> >>> Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the >>> problem is that in this day and age, it can breed trouble. I don't want >>> to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm >>> simply pointing out the realities that are involved with IRC in this day >>> and age. The degree of anonymity DoS and IRC provide sometimes brings >>> out the worst in people, and that's sad. >>> >>> -- >>> | Jeremy Chadwick jdc at parodius.com | >>> | Parodius Networking http://www.parodius.com/ | >>> | UNIX Systems Administrator Mountain View, CA, USA | >>> | Making life hard for others since 1977. PGP: 4BD6C0CB | >>> >>> >> >> Kind regards, >> >> Elvir Kuric >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From koitsu at FreeBSD.org Mon Nov 10 01:31:43 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Nov 10 01:31:50 2008 Subject: Blocking udp flood trafiic using pf, hints welcome In-Reply-To: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> Message-ID: <20081110093141.GA63259@icarus.home.lan> On Sun, Nov 09, 2008 at 05:47:54PM +0000, Peter Maxwell wrote: > ii) Ensure you're using a good NIC, the CPU offload abilities in Intel > (and I think Broadcom) cards can reduce the impact on CPU generally. I think (hope) what you're referring to are TSO, LRO, and TX/RX checksum offloading. Assuming you are, you should be aware of the following: * These features do not greatly reduce CPU usage; the impact is minimal. * Both TSO and TX/RX checksums are known to be buggy on many NICs, including some developed within the past year. I can refer you to many threads on -hardware, -current, and -stable discussing this fact, specifically from the driver authors themselves. Sometimes it's just rxcsum which is buggy, or just txcsum. I do not believe Broadcom or Intel NICs are affected by such issues, but regardless it's important users understand these features *can* lead to packet corruption on some NICs. * TX/RX checksum offloading often confuse users who use tcpdump or Wireshark -- "why are all of my packets showing checksum errors??!" being a common question even today. It often leads users on a wild goose chase, thinking those messages indicate the source of their problems If you weren't referring to these features, what were you referring to? I'm curious to know. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bugmaster at FreeBSD.org Mon Nov 10 03:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 10 03:08:42 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200811101106.mAAB6sUW049802@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/82271 pf [pf] cbq scheduler cause bad latency 24 problems total. From freebsd at optiksecurite.com Wed Nov 12 15:21:31 2008 From: freebsd at optiksecurite.com (FreeBSD) Date: Wed Nov 12 15:21:37 2008 Subject: RDR not triggered Message-ID: <491B5715.8040601@optiksecurite.com> Hi everyone, I'm a little confused as to why my RDR is not working. Quick explanation of my setup: We have 2 webservers, a frontend and a backend. The frontend have a jail for Lighttpd (images server) and Apache on the base system (for PHP). There is one public IP associated to the jail on the public side of the frontend server. There is only one internal private IP. The jail is bound to 127.0.0.25 and a RDR on the external interface is redirecting the traffic in the jail when the request arrive with it's public IP as destination. rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD port http That's working great for external connections. The problem is that the backend server needs to access the Lighttpd jail by the public IP of the frontend server. I understand that I can't redirect the traffic inside the jail with a RDR on the external interface because the packets didn't passthrough the interface. That's why I created I copy of the above RDR but on the internal interface. rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD port http That rule is never triggered even when the traffic, according to tcpdump, is corresponding to the criteria. At the moment, the RDR for the internal interface is just before the external one. The pfctl -gvvvsn output for these 2 rules: @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> 127.0.0.25 port 80 [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 91246 Packets: 0 Bytes: 0 States: 0 ] @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> 127.0.0.25 port 80 [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 States: 2531 ] The tcpdump -nevvvi output from the internal interface of the frontend (where the RDR is not triggered) 17:16:24.683316 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 53680, offset 0, flags [DF], proto: TCP (6), length: 60) 10.0.0.11.61428 > 66.AAA.BB.66.80: S, cksum 0x8827 (correct), 766260635:766260635(0) win 65535 17:16:24.683342 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 59837, offset 0, flags [DF], proto: TCP (6), length: 64, bad cksum 0 (->b615)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: S, cksum 0xf1e7 (correct), 2408882600:2408882600(0) ack 766260636 win 65535 17:16:24.683520 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53681, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: ., cksum 0x112c (correct), 1:1(0) ack 1 win 8326 17:16:24.683672 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 265: (tos 0x0, ttl 64, id 53682, offset 0, flags [DF], proto: TCP (6), length: 251) 10.0.0.11.61428 > 66.AAA.BB.66.80: P 1:200(199) ack 1 win 8326 17:16:24.684461 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 545: (tos 0x0, ttl 64, id 59838, offset 0, flags [DF], proto: TCP (6), length: 531, bad cksum 0 (->b441)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: P 1:480(479) ack 200 win 33304 17:16:24.684803 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53683, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: F, cksum 0x0e83 (correct), 200:200(0) ack 480 win 8326 17:16:24.684823 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 59839, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->b61f)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: ., cksum 0xacef (correct), 480:480(0) ack 201 win 33304 17:16:24.684845 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 59840, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->b61e)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: F, cksum 0xacee (correct), 480:480(0) ack 201 win 33304 17:16:24.684956 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53684, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: ., cksum 0x0e82 (correct), 201:201(0) ack 481 win 8325 Nothing is blocked on both of the servers. The packets are simply not redirected and passed to the Apache on the base system of the frontend server instead of going in the Lighttpd jail, only when coming the the internal network. I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. Thanks everyone for helping me shed some light on this Martin From vadim_nuclight at mail.ru Thu Nov 13 04:10:07 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Thu Nov 13 04:10:14 2008 Subject: RDR not triggered References: <491B5715.8040601@optiksecurite.com> Message-ID: Hi FreeBSD! On Wed, 12 Nov 2008 17:22:13 -0500; FreeBSD wrote about 'RDR not triggered': > Quick explanation of my setup: > We have 2 webservers, a frontend and a backend. The frontend have a jail > for Lighttpd (images server) and Apache on the base system (for PHP). > There is one public IP associated to the jail on the public side of the > frontend server. There is only one internal private IP. The jail is > bound to 127.0.0.25 and a RDR on the external interface is redirecting > the traffic in the jail when the request arrive with it's public IP as > destination. > rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD > port http > That's working great for external connections. > The problem is that the backend server needs to access the Lighttpd jail > by the public IP of the frontend server. I understand that I can't > redirect the traffic inside the jail with a RDR on the external > interface because the packets didn't passthrough the interface. That's > why I created I copy of the above RDR but on the internal interface. > rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD > port http > That rule is never triggered even when the traffic, according to > tcpdump, is corresponding to the criteria. At the moment, the RDR for > the internal interface is just before the external one. > The pfctl -gvvvsn output for these 2 rules: > @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> > 127.0.0.25 port 80 > [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] > [ queue: qname= qid=0 pqname= pqid=0 ] > [ Evaluations: 91246 Packets: 0 Bytes: 0 > States: 0 ] > @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> > 127.0.0.25 port 80 > [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] > [ queue: qname= qid=0 pqname= pqid=0 ] > [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 > States: 2531 ] [...] > Nothing is blocked on both of the servers. The packets are simply not > redirected and passed to the Apache on the base system of the frontend > server instead of going in the Lighttpd jail, only when coming the the > internal network. > I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. It is possible that you have "set skip on $INT_IF" - in that case oll that interface rules will not work. Or another reason, need to see complete pf ruleset. Or try "rdr pass ..." I've asked some people, they tried similar (but not exact!) setup on 6.1/7.0, it worked. So it may be a bug in your version of pf, if not ruleset. The last possible reason - architectural flaw of pf, which binds IPs for states to interfaces, in that case you will need to do ipfw fwd (can use both ipfw and pf simultaneously). -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From freebsd at optiksecurite.com Thu Nov 13 07:57:38 2008 From: freebsd at optiksecurite.com (FreeBSD) Date: Thu Nov 13 07:57:44 2008 Subject: RDR not triggered In-Reply-To: References: <491B5715.8040601@optiksecurite.com> Message-ID: <491C4E9F.90903@optiksecurite.com> Vadim Goncharov a ?crit : > Hi FreeBSD! > > On Wed, 12 Nov 2008 17:22:13 -0500; FreeBSD wrote about 'RDR not triggered': > >> Quick explanation of my setup: > >> We have 2 webservers, a frontend and a backend. The frontend have a jail >> for Lighttpd (images server) and Apache on the base system (for PHP). >> There is one public IP associated to the jail on the public side of the >> frontend server. There is only one internal private IP. The jail is >> bound to 127.0.0.25 and a RDR on the external interface is redirecting >> the traffic in the jail when the request arrive with it's public IP as >> destination. > >> rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD >> port http > >> That's working great for external connections. > >> The problem is that the backend server needs to access the Lighttpd jail >> by the public IP of the frontend server. I understand that I can't >> redirect the traffic inside the jail with a RDR on the external >> interface because the packets didn't passthrough the interface. That's >> why I created I copy of the above RDR but on the internal interface. > >> rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD >> port http > >> That rule is never triggered even when the traffic, according to >> tcpdump, is corresponding to the criteria. At the moment, the RDR for >> the internal interface is just before the external one. > >> The pfctl -gvvvsn output for these 2 rules: > >> @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> >> 127.0.0.25 port 80 >> [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] >> [ queue: qname= qid=0 pqname= pqid=0 ] >> [ Evaluations: 91246 Packets: 0 Bytes: 0 >> States: 0 ] >> @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> >> 127.0.0.25 port 80 >> [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] >> [ queue: qname= qid=0 pqname= pqid=0 ] >> [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 >> States: 2531 ] > [...] >> Nothing is blocked on both of the servers. The packets are simply not >> redirected and passed to the Apache on the base system of the frontend >> server instead of going in the Lighttpd jail, only when coming the the >> internal network. >> I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. > > It is possible that you have "set skip on $INT_IF" - in that case oll that > interface rules will not work. Or another reason, need to see complete pf > ruleset. Or try "rdr pass ..." > D'OH!!! You're right, there was a set skip on $INT_IF... I wasted all mey afternoon trying to debug that. Thanks a lot for your reply. You just made my day :) Martin > I've asked some people, they tried similar (but not exact!) setup on 6.1/7.0, > it worked. So it may be a bug in your version of pf, if not ruleset. > > The last possible reason - architectural flaw of pf, which binds IPs for states > to interfaces, in that case you will need to do ipfw fwd (can use both ipfw and > pf simultaneously). > From salvador_d13 at yahoo.com.ph Fri Nov 14 00:31:30 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Fri Nov 14 00:31:50 2008 Subject: Need for igb(4) driver support with ALTQ Message-ID: <519620.64150.qm@web76108.mail.sg1.yahoo.com> Hi, I have read from this mailing list http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019224.html about igb(4) driver support in FreeBSD for newer releases of Intel Gigabit NICs but unfortunately I haven't found any support for altq(4). If someone could provide some patch on this, then I am willing to test. Regards, Diego --------------------------------- New Email names for you! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! From max at love2party.net Fri Nov 14 04:20:14 2008 From: max at love2party.net (Max Laier) Date: Fri Nov 14 04:20:23 2008 Subject: Need for igb(4) driver support with ALTQ In-Reply-To: <519620.64150.qm@web76108.mail.sg1.yahoo.com> References: <519620.64150.qm@web76108.mail.sg1.yahoo.com> Message-ID: <200811141320.10484.max@love2party.net> On Friday 14 November 2008 09:17:45 Diego Salvador wrote: > Hi, I have read from this mailing list > http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019224.html > about igb(4) driver support in FreeBSD for newer releases of Intel Gigabit > NICs but unfortunately I haven't found any support for altq(4). If someone > could provide some patch on this, then I am willing to test. according to the code, igb(4) supports ALTQ since it was first committed back in February. What makes you think that it isn't? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From salvador_d13 at yahoo.com.ph Sat Nov 15 06:03:50 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Sat Nov 15 06:03:57 2008 Subject: Need for igb(4) driver support with ALTQ In-Reply-To: <200811141320.10484.max@love2party.net> Message-ID: <931259.67719.qm@web76105.mail.sg1.yahoo.com> Max Laier wrote: On Friday 14 November 2008 09:17:45 Diego Salvador wrote: > Hi, I have read from this mailing list > http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019224.html > about igb(4) driver support in FreeBSD for newer releases of Intel Gigabit > NICs but unfortunately I haven't found any support for altq(4). If someone > could provide some patch on this, then I am willing to test. according to the code, igb(4) supports ALTQ since it was first committed back in February. What makes you think that it isn't? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News Hi Max, First of all, thank you for answering my concern because you are right, igb(4) driver already supports ALTQ. Second, please always consider that some users will read manual pages first posted in the web site before or without reading the code because altq(4) man page, doesn't say so. Lastly, I was asking you a polite question so please answer question professionally and ethically. Regards, Diego --------------------------------- Get your preferred Email name! Now you can @ymail.com and @rocketmail.com. From koitsu at FreeBSD.org Sat Nov 15 06:19:51 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Nov 15 06:19:58 2008 Subject: Need for igb(4) driver support with ALTQ In-Reply-To: <931259.67719.qm@web76105.mail.sg1.yahoo.com> References: <200811141320.10484.max@love2party.net> <931259.67719.qm@web76105.mail.sg1.yahoo.com> Message-ID: <20081115141950.GA75796@icarus.home.lan> On Sat, Nov 15, 2008 at 06:03:48AM -0800, Diego Salvador wrote: > First of all, thank you for answering my concern because you are right, igb(4) > driver already supports ALTQ. Second, please always consider that some > users will read manual pages first posted in the web site before or without > reading the code because altq(4) man page, doesn't say so. Please file a PR for this, specifically to the doc team, so we can get the man pages/documentation updated. > Lastly, I was asking you a polite question so please answer question > professionally and ethically. I thought Max's response was both professional and ethical. His question was an honest one, and you've answered it just as honestly. No harm done. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mouss at netoyen.net Sat Nov 15 09:33:14 2008 From: mouss at netoyen.net (mouss) Date: Sat Nov 15 09:33:22 2008 Subject: can't add a port forwarding In-Reply-To: <49106B68.2060007@cyanide-studio.com> References: <49106B68.2060007@cyanide-studio.com> Message-ID: <491F03F6.4020307@netoyen.net> Bastien Semene wrote: > Hi everyone, > > I'm currently facing a weird problem. I have a pf box acting as a > gateway for some services and want to add a port forwarding for https. > > So I added the following rule : > > rdr pass on $ext_if proto tcp from any to any port 443 -> $atlas_ip > //variables are correct since I have a similar rule for port 80. > > The "pfctl -s nat" shows this : > > nat on bge0 inet from 10.1.8.1 to any -> "external_interface_ip" > rdr pass on bge0 inet proto tcp from any to any port = http -> 10.1.8.1 > rdr pass on bge0 inet proto tcp from any to any port = https -> 10.1.8.1 > > An Nmap from outside shows this : > > # nmap -P0 -p80,443,17900 "external_interface_ip" > > Starting Nmap 4.20 ( http://insecure.org ) at 2008-11-04 16:22 CET > Interesting ports on "external_interface_ip": > PORT STATE SERVICE > 80/tcp open http > 443/tcp closed https > 17900/tcp filtered unknown > maybe you allow port 80 but not 443 in your pf rules? > I tried reloading pf rules with "pfctl -F all -f /etc/pf.conf", > restarting the machine, but nothing changed. The securelevel is also at > -1, so pf should take the changes into account. > And of course the destination https server receives nothing on https port. > http and preconfigured nat/forwards works perfectly. > > I tried to comment the "scrub in all" option, but because the rdr line > doesn't seem to be affected, I'm not sure this one is. > > If someone has an idea or direction to follow I take every piece of > thought. > Thanks all. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Nov 17 03:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 17 03:08:45 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200811171106.mAHB6sR2082608@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/82271 pf [pf] cbq scheduler cause bad latency 24 problems total. From linimon at FreeBSD.org Fri Nov 21 18:25:43 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Nov 21 18:25:50 2008 Subject: kern/129060: [pf] [tun] pf doesn't forget the old tun IP Message-ID: <200811220225.mAM2Phuj038059@freefall.freebsd.org> Old Synopsis: pf doesn't forget the old tun IP New Synopsis: [pf] [tun] pf doesn't forget the old tun IP Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 22 02:25:23 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129060 From cbuechler at gmail.com Sat Nov 22 14:36:58 2008 From: cbuechler at gmail.com (Chris Buechler) Date: Sat Nov 22 14:37:05 2008 Subject: kern/129060: [pf] [tun] pf doesn't forget the old tun IP In-Reply-To: <200811220225.mAM2Phuj038059@freefall.freebsd.org> References: <200811220225.mAM2Phuj038059@freefall.freebsd.org> Message-ID: On Fri, Nov 21, 2008 at 9:25 PM, wrote: > Old Synopsis: pf doesn't forget the old tun IP > New Synopsis: [pf] [tun] pf doesn't forget the old tun IP > This sounds like the expected behavior, not a bug. You have to kill your states when your WAN IP changes or else traffic will continue to be translated via the existing state. Chris From darius at dons.net.au Sat Nov 22 16:25:39 2008 From: darius at dons.net.au (Daniel O'Connor) Date: Sat Nov 22 16:25:47 2008 Subject: kern/129060: [pf] [tun] pf doesn't forget the old tun IP In-Reply-To: References: <200811220225.mAM2Phuj038059@freefall.freebsd.org> Message-ID: <200811231018.28601.darius@dons.net.au> On Sunday 23 November 2008 08:42:48 Chris Buechler wrote: > On Fri, Nov 21, 2008 at 9:25 PM, wrote: > > Old Synopsis: pf doesn't forget the old tun IP > > New Synopsis: [pf] [tun] pf doesn't forget the old tun IP > > This sounds like the expected behavior, not a bug. You have to kill > your states when your WAN IP changes or else traffic will continue to > be translated via the existing state. I have tried to use -k $oldip but it doesn't fix the problem :( Also, I don't think it is sensible behaviour - if my IP changes any connections are going to die because the other ends of the link will be sending traffic to the old IP. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20081123/1f9831f0/attachment.pgp From peter at allicient.co.uk Sat Nov 22 16:54:44 2008 From: peter at allicient.co.uk (Peter Maxwell) Date: Sat Nov 22 16:54:50 2008 Subject: kern/129060: [pf] [tun] pf doesn't forget the old tun IP In-Reply-To: <200811231018.28601.darius@dons.net.au> References: <200811220225.mAM2Phuj038059@freefall.freebsd.org> <200811231018.28601.darius@dons.net.au> Message-ID: <7731938b0811221654m6d7fff30x3e6ac51fccd32eaa@mail.gmail.com> I have only skim read the bug report, however in report it says "every second connection" which sounds like what happens when you have outgoing connections from an interface that has two IPs assigned (had got bitten with this when using IPSec over an interface that had two IPs assigned). Except this time the first IP is ofcourse now not routable, which is consistent with the observed behaviour. So, while necessary, I would doubt clearing the state table would do anything other than (possibly) fix the existing connections - as any new conenctinos have a 50% chance of having their source IP as the old IP. I'm assuming that ALL incoming connections are processed fine? pf is obviously working with the ($ext/if) syntax as it sounds like its picking up the new IP. Looks like a bug to me. 2008/11/22 Daniel O'Connor : > On Sunday 23 November 2008 08:42:48 Chris Buechler wrote: >> On Fri, Nov 21, 2008 at 9:25 PM, wrote: >> > Old Synopsis: pf doesn't forget the old tun IP >> > New Synopsis: [pf] [tun] pf doesn't forget the old tun IP >> >> This sounds like the expected behavior, not a bug. You have to kill >> your states when your WAN IP changes or else traffic will continue to >> be translated via the existing state. > > I have tried to use -k $oldip but it doesn't fix the problem :( > > Also, I don't think it is sensible behaviour - if my IP changes any > connections are going to die because the other ends of the link will be > sending traffic to the old IP. > > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > From max at love2party.net Sat Nov 22 17:40:04 2008 From: max at love2party.net (Max Laier) Date: Sat Nov 22 17:40:10 2008 Subject: kern/129060: [pf] [tun] pf doesn't forget the old tun IP Message-ID: <200811230140.mAN1e3Cj024702@freefall.freebsd.org> The following reply was made to PR kern/129060; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, darius@dons.net.au Cc: Subject: Re: kern/129060: [pf] [tun] pf doesn't forget the old tun IP Date: Sun, 23 Nov 2008 02:20:57 +0100 This is a known bug in pppd. You can work around this by using "(tun0:0)" instead of just "(tun0)" whenever you refer to the interface's address. -- Max From rmaglasang at infoweapons.com Sun Nov 23 19:00:57 2008 From: rmaglasang at infoweapons.com (Ronnel P. Maglasang) Date: Sun Nov 23 19:01:03 2008 Subject: limiting bandwidth at certain times during the day In-Reply-To: <56157.217.45.165.129.1223037455.squirrel@www.violetlan.net> References: <56157.217.45.165.129.1223037455.squirrel@www.violetlan.net> Message-ID: <492A1480.7080605@infoweapons.com> Current implementation of ALTQ and also PF is not dynamic. You apply changes (e.g. new Queue parameters), you basically have to flush all the queues and reload. That means, "pfctl -Fall" followed by "pfctl -f new-pf.conf" You can achieve this by creating a script that will called from cron. Be aware of the effect when flushing all the rules though. That would drop existing VPN sessions. I am not sure if there is an on-going project to support dynamic ALTQ/PF. Reinhold wrote: > Hi > > I was asked to limit the amount of bandwidth being used by our openvpn > connections during our office hours and then allow full access after > hours. > > In my current set up I'm using pf that does load balancing over 2 adsl > lines on a FreeBSD 7-STABLE system, I'm using mpd5 for dialing in and > establish the connections with our ISP. > > I'm in the process of implementing HFSC to see if I can improve our > bandwidth usage, I tried PRIQ but ended up loosing packets and the over > all performance decreased to a point where I had to disable it. > > How can I go about setting up a limit for a certain time period on the > amount of bandwidth being used by openvpn? > > Thanks > Reinhold > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From darius at dons.net.au Sun Nov 23 19:20:04 2008 From: darius at dons.net.au (Daniel O'Connor) Date: Sun Nov 23 19:20:14 2008 Subject: kern/129060: [pf] [tun] pf doesn't forget the old tun IP Message-ID: <200811240320.mAO3K4wA027210@freefall.freebsd.org> The following reply was made to PR kern/129060; it has been noted by GNATS. From: "Daniel O'Connor" To: Max Laier Cc: bug-followup@freebsd.org Subject: Re: kern/129060: [pf] [tun] pf doesn't forget the old tun IP Date: Mon, 24 Nov 2008 13:34:15 +1030 --nextPart34103142.i1CJtADx0V Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 23 November 2008 11:50:57 Max Laier wrote: > This is a known bug in pppd. You can work around this by using "(tun0:0)" > instead of just "(tun0)" whenever you refer to the interface's address. OK, I've mangled my PF rules, fingers crossed :) What is the actual bug with PPP? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart34103142.i1CJtADx0V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJKhm75ZPcIHs/zowRAqApAJ9TymAWVg7czROjD8uoIExiMLYudACfYyZ0 g3HWLxngK+Y1FErYB1gigCs= =c48z -----END PGP SIGNATURE----- --nextPart34103142.i1CJtADx0V-- From bugmaster at FreeBSD.org Mon Nov 24 03:07:19 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 24 03:08:44 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200811241107.mAOB7IOL019987@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129060 pf [pf] [tun] pf doesn't forget the old tun IP o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/82271 pf [pf] cbq scheduler cause bad latency 25 problems total. From marcello at linconet.com.br Mon Nov 24 13:21:52 2008 From: marcello at linconet.com.br (Marcello Barreto) Date: Mon Nov 24 13:21:59 2008 Subject: PF + ALTQ - Bandwidth per customer Message-ID: <20081124180411.0b065be5@wolwerine> Hello Folks, I believe you have heard this several times, but I'm new to FreeBSD and i'm trying to change my bandwidth control from Linux (iptables + TC + iproute) to Freebsd (PF + ALTQ). I read about PF and I was very interested on it, but I want to limit the bandwidth (Download and Upload) from each customer behind a router (Obviously, FreeBSD with PF.).. There are several networks and a lot of customers, and with my rules, only what I got was each customer sharing the same queue... There are my rules: altq on $external cbq queue {def_up, def_up300, def_up450, def_up600, def_up1000} altq on $internal cbq queue {def_down, def_down300, def_down450, def_down600, def_down1000} queue def_up bandwidth 10% cbq(default) queue def_down bandwidth 10% cbq(default) queue def_up300 bandwidth 128Kb cbq(red) queue def_up450 bandwidth 200Kb cbq(red) queue def_up600 bandwidth 300Kb cbq(red) queue def_up1000 bandwidth 500Kb cbq(red) queue def_down300 bandwidth 300Kb cbq(red) queue def_down450 bandwidth 450Kb cbq(red) queue def_down600 bandwidth 600Kb cbq(red) queue def_down1000 bandwidth 1024Kb cbq(red) pass in quick inet proto {tcp, udp} from to any queue def_down300 pass out quick inet proto {tcp, udp} from to any queue def_up300 Ps.: Excuse me for my bad English. -- Esta mensagem foi verificada pelo sistema de antivírus e acredita-se estar livre de perigo. From chflags at gmail.com Thu Nov 27 04:58:40 2008 From: chflags at gmail.com (Kevin Foo) Date: Thu Nov 27 04:58:46 2008 Subject: if_bridge + pf rdr (bridged inline proxy) Message-ID: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> Hi list, I recently setup a bridge box with inline cache proxy. if_bridge with pf filtering was working perfectly. However, squid-cache listening on loopback device did not get any packets from pf rdr. I have seen successful setups with OpenBSD's bridge spamd which rather a similar setup. Is something broken on FreeBSD's if_bridge or am I missing some configuration here? pfctl -ss (on bridge box): ------------------ all tcp 127.0.0.1:3128 <- 71.14.235.147:80 <- 192.168.1.100:1041 CLOSED:SYN_SENT all tcp 192.168.1.100:1041 -> 127.0.0.1:3128 SYN_SENT:CLOSED Environment ------------------ FreeBSD bridge.mybox 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Nov 25 22:56:22 MYT 2008 kev@bridge.mybox:/usr/obj/usr/src/sys/BRIDGE i386 Squid Cache: Version 2.7.STABLE5 with --enable-pf-transparent rc.conf: ------------------ cloned_interfaces="bridge0" ifconfig_bridge0="addm bge0 addm bge1 up" ifconfig_bge0="up" ifconfig_bge1="up" pf_enable="YES" squid_enabld="YES" pf.conf: ------------------ int_if="bge0" ext_if="bge1" rdr pass on $int_if inet proto tcp from any to any port 80 -> 127.0.0.1 port 3128 pass in all pass out all pass on $int_if route-to lo0 proto tcp from any to 127.0.0.1 port 3128 sysctl net.link.bridge : ------------------ net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 1 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 0 Hping Testing (from client 192.168.1.100): ------------------ hping -S -p 80 -c 10 www.google.com A quick search on freebsd-pf archive, I found a thread on similar setup in 2004. http://lists.freebsd.org/pipermail/freebsd-pf/2004-October/000522.html However, the bridge code of FreeBSD was blamed for poor performance and lack of functionalities. A more recent post on freebsd-net mailing list on similar issue. http://lists.freebsd.org/pipermail/freebsd-net/2008-September/019556.html Any ideas? TIA. P/S : please cc me as I'm not subscribed to freebsd-pf nor freebsd-net mailing list. Thanks. -- Regards Kevin Foo From rea-fbsd at codelabs.ru Thu Nov 27 06:15:50 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 27 06:15:56 2008 Subject: if_bridge + pf rdr (bridged inline proxy) In-Reply-To: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> References: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> Message-ID: Kevin, good day. Thu, Nov 27, 2008 at 08:26:55PM +0800, Kevin Foo wrote: > I recently setup a bridge box with inline cache proxy. if_bridge with > pf filtering was working perfectly. However, squid-cache listening on > loopback device did not get any packets from pf rdr. I have seen > successful setups with OpenBSD's bridge spamd which rather a similar > setup. Is something broken on FreeBSD's if_bridge or am I missing some > configuration here? pf can 'rdr' only incoming packets (from 'man pf.conf'): ----- Evaluation order of the translation rules is dependent on the type of the translation rules and of the direction of a packet. binat rules are always evaluated first. Then either the rdr rules are evaluated on an inbound packet or the nat rules on an outbound packet. Rules of the same type are evaluated in the same order in which they appear in the ruleset. The first matching rule decides what action is taken. ----- So this can be just pf-related. And may be not, as usual... -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20081127/edec6a87/attachment.pgp From samflanker at gmail.com Thu Nov 27 11:13:02 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Thu Nov 27 11:13:08 2008 Subject: synproxy state does not work on FreeBSD 7.1-PRERELEASE Message-ID: hello I tried to rule with `synproxy state` uname FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 29 12:47:36 UTC 2008 (amd64 & i386 arch) the synproxy state is not working uname FreeBSD 7.0-RELEASE GENERIC (amd64 & i386 arch) the synproxy state is working # cat /etc/pf.conf pass on em0 proto tcp from any to 192.168.0.1 port http synproxy state to all, please check and confirm or deny /Vladimir Ermakov From chflags at gmail.com Thu Nov 27 21:29:36 2008 From: chflags at gmail.com (Kevin Foo) Date: Thu Nov 27 21:29:42 2008 Subject: if_bridge + pf rdr (bridged inline proxy) In-Reply-To: References: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> Message-ID: <25cb30811272129h68e50bf4u46b15823b101a3@mail.gmail.com> Thank Eygene for the reply. It might be but I'm not sure. Anyone is having the same setting or any info on this? -- Regards Kevin Foo On Thu, Nov 27, 2008 at 10:00 PM, Eygene Ryabinkin wrote: > Kevin, good day. > > Thu, Nov 27, 2008 at 08:26:55PM +0800, Kevin Foo wrote: >> I recently setup a bridge box with inline cache proxy. if_bridge with >> pf filtering was working perfectly. However, squid-cache listening on >> loopback device did not get any packets from pf rdr. I have seen >> successful setups with OpenBSD's bridge spamd which rather a similar >> setup. Is something broken on FreeBSD's if_bridge or am I missing some >> configuration here? > > pf can 'rdr' only incoming packets (from 'man pf.conf'): > ----- > Evaluation order of the translation rules is dependent on the type of the > translation rules and of the direction of a packet. binat rules are > always evaluated first. Then either the rdr rules are evaluated on an > inbound packet or the nat rules on an outbound packet. Rules of the same > type are evaluated in the same order in which they appear in the ruleset. > The first matching rule decides what action is taken. > ----- > So this can be just pf-related. And may be not, as usual... > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > From david_5073 at yahoo.com Sat Nov 29 06:27:34 2008 From: david_5073 at yahoo.com (David Roseman) Date: Sat Nov 29 07:12:01 2008 Subject: PF + ALTQ - Bandwidth per customer In-Reply-To: <20081124180411.0b065be5@wolwerine> Message-ID: <705757.42117.qm@web38504.mail.mud.yahoo.com> --- On Mon, 11/24/08, Marcello Barreto wrote: > From: Marcello Barreto > Subject: PF + ALTQ - Bandwidth per customer > To: freebsd-pf@freebsd.org, freebsd-isp@freebsd.org > Date: Monday, November 24, 2008, 4:04 PM > Hello Folks, > I believe you have heard this several times, but I'm > new to FreeBSD and i'm trying to change my bandwidth > control from Linux (iptables + TC + iproute) to Freebsd (PF > + ALTQ). > I read about PF and I was very interested on it, but I > want to limit the bandwidth (Download and Upload) from each > customer behind a router (Obviously, FreeBSD with PF.).. > There are several networks and a lot of customers, and with > my rules, only what I got was each customer sharing the same > queue... > > There are my rules: > altq on $external cbq queue {def_up, def_up300, def_up450, > def_up600, def_up1000} > altq on $internal cbq queue {def_down, def_down300, > def_down450, def_down600, def_down1000} > > queue def_up bandwidth 10% cbq(default) > queue def_down bandwidth 10% cbq(default) > > queue def_up300 bandwidth 128Kb cbq(red) > queue def_up450 bandwidth 200Kb cbq(red) > queue def_up600 bandwidth 300Kb cbq(red) > queue def_up1000 bandwidth 500Kb cbq(red) > > queue def_down300 bandwidth 300Kb cbq(red) > queue def_down450 bandwidth 450Kb cbq(red) > queue def_down600 bandwidth 600Kb cbq(red) > queue def_down1000 bandwidth 1024Kb cbq(red) > > > pass in quick inet proto {tcp, udp} from > to any queue def_down300 > pass out quick inet proto {tcp, udp} from > to any queue def_up300 > You should consider a commercial product rather than relying on old and somewhat unreliable technology. We've been able to squeeze a lot more customers onto our network for a $3500. investment. It paid for itself in 2 months. We have a dual-core 2.33Ghz system passing 95Mb/s with 12000 rules in place and it runs at about 10%. The latest version is truly amazing. http://www.etinc.com Regards, David From sebastian.tymkow at gmail.com Sat Nov 29 07:48:37 2008 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Sat Nov 29 07:48:44 2008 Subject: PF + ALTQ - Bandwidth per customer In-Reply-To: <705757.42117.qm@web38504.mail.mud.yahoo.com> References: <20081124180411.0b065be5@wolwerine> <705757.42117.qm@web38504.mail.mud.yahoo.com> Message-ID: <692660060811290748i33059137g3977e51f692d8340@mail.gmail.com> Hello, Why do you think it's unrealiable technology ? I think system that you propose rely on this technology ;) Most of this use bsd/linux/unix on board with own solutions and than they're packed into the box with cute web interface. Of course I can be wrong... Best regards, Shamrock 2008/11/29 David Roseman > > > > --- On Mon, 11/24/08, Marcello Barreto wrote: > > > From: Marcello Barreto > > Subject: PF + ALTQ - Bandwidth per customer > > To: freebsd-pf@freebsd.org, freebsd-isp@freebsd.org > > Date: Monday, November 24, 2008, 4:04 PM > > Hello Folks, > > I believe you have heard this several times, but I'm > > new to FreeBSD and i'm trying to change my bandwidth > > control from Linux (iptables + TC + iproute) to Freebsd (PF > > + ALTQ). > > I read about PF and I was very interested on it, but I > > want to limit the bandwidth (Download and Upload) from each > > customer behind a router (Obviously, FreeBSD with PF.).. > > There are several networks and a lot of customers, and with > > my rules, only what I got was each customer sharing the same > > queue... > > > > There are my rules: > > altq on $external cbq queue {def_up, def_up300, def_up450, > > def_up600, def_up1000} > > altq on $internal cbq queue {def_down, def_down300, > > def_down450, def_down600, def_down1000} > > > > queue def_up bandwidth 10% cbq(default) > > queue def_down bandwidth 10% cbq(default) > > > > queue def_up300 bandwidth 128Kb cbq(red) > > queue def_up450 bandwidth 200Kb cbq(red) > > queue def_up600 bandwidth 300Kb cbq(red) > > queue def_up1000 bandwidth 500Kb cbq(red) > > > > queue def_down300 bandwidth 300Kb cbq(red) > > queue def_down450 bandwidth 450Kb cbq(red) > > queue def_down600 bandwidth 600Kb cbq(red) > > queue def_down1000 bandwidth 1024Kb cbq(red) > > > > > > pass in quick inet proto {tcp, udp} from > > to any queue def_down300 > > pass out quick inet proto {tcp, udp} from > > to any queue def_up300 > > > > You should consider a commercial product rather than relying on > old and somewhat unreliable technology. We've been able to squeeze a > lot more customers onto our network for a $3500. investment. It paid for > itself in 2 months. We have a dual-core 2.33Ghz system passing 95Mb/s > with 12000 rules in place and it runs at about 10%. The latest version is > truly amazing. > > http://www.etinc.com > > > Regards, > > David > > > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From david_5073 at yahoo.com Sat Nov 29 08:26:58 2008 From: david_5073 at yahoo.com (David Roseman) Date: Sat Nov 29 09:25:45 2008 Subject: PF + ALTQ - Bandwidth per customer In-Reply-To: <692660060811290748i33059137g3977e51f692d8340@mail.gmail.com> Message-ID: <425805.11833.qm@web38505.mail.mud.yahoo.com> Is top-posting allowed here? This product has been around longer than ALTQ and pf. So its unlikely that they threw away something that has always been superior to ALTQ to replace it with ALTQ. The release notes go back to 1996. They also claim to have re-written the FreeBSD bridging code to gain 40% in performance. http://www.etinc.com/release.notes RED and CBQ were technologies championed by Cisco. They're designed to work on CPU-starved routers. Cisco had a big problem because their routers were designed to move packets and they didn't have any cpu power available for intelligent processing required for packet shaping. So they designed these brain-dead "leaky bucket" and CBQ models to work on their cpu-starved routers in the 90s. Inexplicably, these silly techniques were copied and put into pubic operating systems, and people still use them to save what amounts to pennies compared to the new business they can attract with a better network. If you'd read the white papers you'd know its not a queue-based product and its totally custom. Window shaping is really the most important technology to reduce the amount of traffic in a nework. Slowing servers naturally without having to queue data makes a dramatic change in the delay patterns of a large network. Imagine 1000 servers sending 3000 bytes per window instead of 32K. The backup queue depths are dramatically reduced even without specific bandwidth limits per customer. It also has a traffic monitor that is indispensable in tracking down DOS attacks, worms and out of control servers. I'd pay $500. just for the monitor. I have a problem, I fire up the monitor and bingo, I find the problem. I think you can buy the lowest priced license and still use the monitor and gather statistics no matter how large your network is. David --- On Sat, 11/29/08, Sebastian Tymk?w wrote: > From: Sebastian Tymk?w > Subject: Re: PF + ALTQ - Bandwidth per customer > To: david_5073@yahoo.com > Cc: freebsd-pf@freebsd.org, freebsd-isp@freebsd.org, "Marcello Barreto" > Date: Saturday, November 29, 2008, 10:48 AM > Hello, > > Why do you think it's unrealiable technology ? > I think system that you propose rely on this technology ;) > Most of this use bsd/linux/unix on board with own solutions > and than they're > packed into the box > with cute web interface. > Of course I can be wrong... > > Best regards, > > Shamrock > > 2008/11/29 David Roseman > > > > > > > > > --- On Mon, 11/24/08, Marcello Barreto > wrote: > > > > > From: Marcello Barreto > > > > Subject: PF + ALTQ - Bandwidth per customer > > > To: freebsd-pf@freebsd.org, > freebsd-isp@freebsd.org > > > Date: Monday, November 24, 2008, 4:04 PM > > > Hello Folks, > > > I believe you have heard this several > times, but I'm > > > new to FreeBSD and i'm trying to change my > bandwidth > > > control from Linux (iptables + TC + iproute) to > Freebsd (PF > > > + ALTQ). > > > I read about PF and I was very interested > on it, but I > > > want to limit the bandwidth (Download and Upload) > from each > > > customer behind a router (Obviously, FreeBSD with > PF.).. > > > There are several networks and a lot of > customers, and with > > > my rules, only what I got was each customer > sharing the same > > > queue... > > > > > > There are my rules: > > > altq on $external cbq queue {def_up, def_up300, > def_up450, > > > def_up600, def_up1000} > > > altq on $internal cbq queue {def_down, > def_down300, > > > def_down450, def_down600, def_down1000} > > > > > > queue def_up bandwidth 10% cbq(default) > > > queue def_down bandwidth 10% cbq(default) > > > > > > queue def_up300 bandwidth 128Kb cbq(red) > > > queue def_up450 bandwidth 200Kb cbq(red) > > > queue def_up600 bandwidth 300Kb cbq(red) > > > queue def_up1000 bandwidth 500Kb cbq(red) > > > > > > queue def_down300 bandwidth 300Kb cbq(red) > > > queue def_down450 bandwidth 450Kb cbq(red) > > > queue def_down600 bandwidth 600Kb cbq(red) > > > queue def_down1000 bandwidth 1024Kb cbq(red) > > > > > > > > > pass in quick inet proto {tcp, udp} from > > > > to any queue def_down300 > > > pass out quick inet proto {tcp, udp} from > > > to any queue def_up300 > > > > > > > You should consider a commercial product rather than > relying on > > old and somewhat unreliable technology. We've been > able to squeeze a > > lot more customers onto our network for a $3500. > investment. It paid for > > itself in 2 months. We have a dual-core 2.33Ghz system > passing 95Mb/s > > with 12000 rules in place and it runs at about 10%. > The latest version is > > truly amazing. > > > > http://www.etinc.com > > > > > > Regards, > > > > David