From owner-freebsd-pf@FreeBSD.ORG Sun Jan 9 00:56:47 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C990216A4CE for ; Sun, 9 Jan 2005 00:56:47 +0000 (GMT) Received: from bsdfreaks.muntinternet.nl (bsdfreaks.zone1.muntinternet.net [81.173.4.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C2FA43D49 for ; Sun, 9 Jan 2005 00:56:46 +0000 (GMT) (envelope-from rob@bsdfreaks.nl) Received: (qmail 95919 invoked by uid 89); 9 Jan 2005 01:00:16 -0000 Received: by simscan 1.0.8 ppid: 95901, pid: 95907, t: 1.5685s scanners: attach: 1.0.8 clamav: 0.80/m:28/d:633 spam: 3.0.1 Received: from unknown (HELO ?192.168.1.2?) (rob@bsdfreaks.nl@84.31.114.222) by bsdfreaks.zone1.muntinternet.net with SMTP; 9 Jan 2005 01:00:15 -0000 Message-ID: <41E08244.2070409@bsdfreaks.nl> Date: Sun, 09 Jan 2005 02:00:52 +0100 From: Rob Lensen User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <41B9BB9A.7000300@bsdfreaks.nl> In-Reply-To: <41B9BB9A.7000300@bsdfreaks.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-DCC: sgs_public_dcc_server: bsdfreaks.muntinternet.nl 1199; Body=1 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bsdfreaks.muntinternet.nl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Pyzor: Reported 0 times. Subject: Re: Strange bridge problem with pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 00:56:47 -0000 Hello, The problem which I had with FreeBSD and the bridged setup is solved. I solved it by switching the transparent bridge machine to OpenBSD 3.6. So the same ruleset is working perfect on OpenBSD. So I think PF and bridge do not work well on FreeBSD. Best, Rob > > I have strange problem with pf on a bridged setup. > > Did read the previous thread about the pf problem with a bridge, since sysctl value of ipf bridge should be enabled. > > In the attached file the pf.conf is given. (fxp0 is the outside nic) > > The firewall is working for all machines behind the firewall except sf1, nothing seem to go this machine if the firewall is enanbled. > > If I look at the output of pfctl -sr I can see the rules for this machine are loaded: > > @7 pass in quick on fxp0 inet proto tcp from any to X.6 port = ssh flags S/SA keep state > @16 pass in quick on fxp0 inet proto tcp from any to X.6 port = http flags S/SA keep state > @17 pass in quick on fxp0 inet proto tcp from any to X.6 port = https flags S/SA keep state > > This should open the ports for ssh and http to machine X.6 (sf1), however no connection can be made. > Nmap shows: > 22/tcp open ssh > 80/tcp open http > > #telnet X.6 22 > gives a time out > > All other hosts are working fine. > > Doe anyone have any clue on this problem? > > Best > Rob Lensen > > > ------------------------------------------------------------------------ > > outside="fxp0" > ext_if="fxp0" > inside="fxp1" > local="rl0" > > ext_ip="" > local_net ="X.0/24" > > # Tables: similar to macros, but more flexible for many addresses. > table {127.0.0.0/8, 192.168.1.0/16, 172.16.0.0/12, 10.0.0.0/8 } > > set loginterface $outside > set block-policy return > > # Normalization: reassemble fragments and resolve or reduce traffic ambiguities. > #scrub in all > > web_A_2 = "X.2" > web_A_3 = "X.3" web_A_4 = "X.4" > web_A_7 = "X.7" > web_A_8 = "X.8" > web_A_9 = "X.9" > web_A_20 = "X.20" > sf1 = "X.6" > sf2 = "X.30" > mysql2 = "X.14" > extranet = "X.13" > firewall = "X.254" > sec_dns = "X" > > http_servers = "{" $web_A_2 $web_A_4 $sf1 $web_A_8 $web_A_9 $extranet "}" > ssh_servers = "{" $web_A_2 $sf1 $sf2 $extranet $mysql2 $firewall "}" > ftp_servers = "{" $web_A_2 $sf1 "}" > mail_servers = "{" $extranet "}" > samba_servers = "{" $extranet "}" > dns_servers = "{" $web_A_3 "}" > > ssh_ports = "{ 22 }" > http_ports = "{ 80 , 443 }" > ftp_ports = "{ 20, 21 }" > ftp_ports_pasv = "{ 65000:65500 }" > snmp_ports = "{ 161 }" > mysql_ports = "{ 3306 }" > dns_ports = "{ 53 }" > email_ports = "{ 25, 110, 143, 993, 995 }" > samba_udp_ports = "{ 137, 138, 587 }" > samba_tcp_ports = "{ 139, 445, 587 }" > > # filtering done on public side of bridge, so allow everything > # on the protected side of things > pass in quick on $inside all > pass out quick on $inside all > > # block everything by default on bridge > block in log on $outside all > pass out on $outside all > #block out log on $outside all > > pass in quick on $local all > pass out quick on $local all > > ############ > # IN RULES > ############ > > #allow ssh to defined servers > pass in quick on $outside proto tcp from any to $ssh_servers \ > port $ssh_ports flags S/SA keep state > > > #allow http for the defined servers > pass in quick on $outside proto tcp from any to $http_servers \ > port $http_ports flags S/SA keep state > > #allow ftp for defined servers > pass in quick on $outside proto tcp from any to $ftp_servers \ > port $ftp_ports #flags S/SA keep state > pass in quick on $outside proto tcp from any to $ftp_servers \ > port $ftp_ports_pasv #keep state > > #allow email for defined server > pass in quick on $outside proto tcp from any to $mail_servers \ > port $email_ports #flags S/SA keep state > > #allow samba for defined server > pass in quick on $outside proto tcp from any to $samba_servers \ > port $samba_tcp_ports #flags S/SA keep state > > pass in quick on $outside proto udp from any to $samba_servers \ > port $samba_udp_ports #keep state > > #allow dns for defined server > pass in quick on $outside proto { tcp, udp } from any to $dns_servers \ > port domain keep state > > #snmp on firewall > #pass in quick on $outside proto {tcp, udp } from any to $local_ip \ > # port $snmp_ports > > #pass in quick on $local proto {tcp,udp } from any to $firewall_bridge \ > # port $snmp_ports > # Allow ICMP (ping) IN > # pass out/in certain ICMP queries and keep state (ping) > pass in on $outside inet proto icmp all icmp-type {0,3 ,8, 11} > > > ############ > # OUT RULES > ############ > # Allow ICMP (ping) OUT > pass out on $outside inet proto icmp all icmp-type {0,3 ,8, 11} > # Pass (Allow) all UDP/TCP OUT and keep state > pass out on $outside proto udp all #keep state > pass out on $outside proto tcp 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 owner-freebsd-pf@FreeBSD.ORG Mon Jan 10 14:07:23 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AAB916A4CE for ; Mon, 10 Jan 2005 14:07:23 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6456043D3F for ; Mon, 10 Jan 2005 14:07:22 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Co0CT-0006jE-00; Mon, 10 Jan 2005 15:07:17 +0100 Received: from [84.128.128.177] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Co0CR-0002Wb-00; Mon, 10 Jan 2005 15:07:17 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Mon, 10 Jan 2005 15:07:03 +0100 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2299320.XI0AfLurh9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501101507.10501.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Bernhard Schmidt Subject: Re: Scalability of ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 14:07:23 -0000 --nextPart2299320.XI0AfLurh9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 08 January 2005 00:49, Bernhard Schmidt wrote: > we're currently using an old and overloaded packeteer packetshaper for > IP-over-Satellite deployment. Since this business will be expanded in > the next weeks to a level the packeteer cannot cope with anymore I'm > looking for alternatives in the unix-world, especially with pf and ALTQ > since it is impressively easy to configure and maintain. > > There currently are four encapsulating units that have 30-40 Mbps IP > bandwidth each. Every unit has up to ten first-level customers with > about 20 second-level customers behind them. Every customer (first and > second level) has a commited rate and a burstable rate. There is no > oversubscribing in this business with regard to the commited rates, > while burstable may be used (up to a paid amount) as long as noone else > needs it. > > The address ranges behind those encapsulators tend to be very large (/18 > or bigger), with very many concurrent sessions. Due to the transmission > technique used the packet shapers cannot see the traffic coming back > from the customers, sometimes these packets don't even flow through our > site. Generally speaking, 30-40Mbps are no problem. The limiting factor for pf (= as=20 for any packet filter/firewall/etc.) is packets per second (pps). In the e= nd=20 there is no alternative to just try it. In the worst case scenario (with 6= 4=20 byte per packet) this means about 625 kpps, which will certainly overload=20 most systems. An *average* packet size of 400-800 byte/packet, however,=20 resulting in 50-100 kpps, should already be doable without problems. > a) Is pf/kernel capable of that many queues? The only way I could think > of copying that commited/burstable model into pf were two queues for > each level, something like > > altq on fxp0 cbq bandwidth 40Mb queue { cust1, cust2, ... } > > queue cust1 on fxp0 bandwidth 5Mb cbq { cust1_commit } > queue cust1_commit on fxp0 bandwidth priority 2 10Mb cbq(borrow) { > cust1_sub1, cust1_sub2 } queue cust1_sub1 on fxp0 bandwidth 10Mb cbq { > cust1_sub1_commit } queue cust1_sub1_commit on fxp0 priority 2 bandwid= th > 2Mb cbq(borrow) queue cust1_sub2 on fxp0 bandwidth 0Mb cbq { > cust1_sub2_commit } queue cust1_sub2_commit on fxp0 priority 2 bandwid= th > 10Mb cbq(borrow) > > and so on, which should simulate the following ruleset > > Encapsulator 1 (40Mb max rate) > Customer1 (10Mb commited + 5Mb burstable) > Subcustomer 1 (2Mb commited + 10Mb burstable) > Subcustomer 2 (10Mb commited (+ 0Mb burstable)) > > and so on. Subcustomer1 could even have subcustomers on their own. > For 200 subcustomers per encapsulation unit this makes more than 400 > queues per box, not talking about handling several encap. units on > one box. And if one wants to use the nifty pf feature to use another > queue for interactive traffic we're at twice the size. What about > adding RED/ECN in this environment, adding additional need for > resources (I guess). > > Another problem that might occur (I haven't tested it yet, so it is > just speculation).... assuming the ruleset above, I guess packets > "borrowing" from their parent class still get the attributes of their > native class. With sub2 doing 10Mbps commited traffic and sub1 10Mbps > (2Mbps commited + 8Mbps burst) there would be 20Mbps of traffic > fighting for 15Mbps bandwidth of the cust1 queue. With all having > prio 2, sub2 might be dropped below his 10Mbps commited rate. > > After reading up the manpage I believe hsfc could be the solution, > with something like > > queue cust1 on fxp0 hsfc(realtime(10Mb), upperlimit(15Mb)) { cust1_sub= 1, > cust1_sub2 } queue cust1_sub1 on fxp0 hsfc(realtime(2Mb), > upperlimit(12Mb)) queue cust1_sub2 on fxp0 hsfc(realtime(10Mb)) > > would this help me? Any better ideas? =46rom a very first glance, I think HSFC is what best suits your applicatio= n. =20 Here again, you must make sure not to overload your parent with the client= =20 bandwidth. > b) Is pf/kernel capable of handling that many states? I'm not able to > access the packeteer at the moment, but I think we're way over 10000 > concurrent sessions. 10'000 states are no problem. In general states are a lot cheaper than act= ual=20 ruleset evaluation. Depending on your setup it might be a good idea to=20 switch to if-bound states. This will generate even more states, but will=20 reduce the search time. For reference, a state entry is just 256 Byte whic= h=20 should make it obvious that you can have a lot of states before you hit a=20 limit. States are organized in a red-black tree which provides an upper=20 limit of O(lg(N)) for the state search, where N is the number of states (pe= r=20 interface, if you go with if-bound states). > Any idea whether pf would be able to scale at that level? I was thinking > about boxes in the P4 2GHz class, best would be if one could handle > at least two encapsulators. On that kind of hardware, you can do quite a few pps - depending on the=20 network cards and system bus organization, of course. > Even better would be if pf could do this whole thing in a bridged > environment, but this might be too much to ask. Bridge support is currently broken in FreeBSD. This might be fixed once we= =20 import if_bridge from Open/NetBSD, but right now it just does not work. Yo= u=20 might want to try OpenBSD instead, which has full bridge support. > I'm glad to hear any experience with deployments of that size. Sorry, I can't provide such. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2299320.XI0AfLurh9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD4DBQBB4owOXyyEoT62BG0RAhaSAJ4x/nB2KVPlICkNKHMDd99Y3WPa9ACYhzuG 53hZt9gfnOrsFiWFqAWnOQ== =8W92 -----END PGP SIGNATURE----- --nextPart2299320.XI0AfLurh9-- From owner-freebsd-pf@FreeBSD.ORG Tue Jan 11 03:42:43 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FD4516A4CE for ; Tue, 11 Jan 2005 03:42:43 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C266943D58 for ; Tue, 11 Jan 2005 03:42:42 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [192.168.1.99] (i-99.forrie.net. [192.168.1.99]) (authenticated bits=0) by forrie.com with ESMTP id j0B3gWCl091373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Jan 2005 22:42:33 -0500 (EST) (envelope-from forrie@forrie.com) Message-ID: <41E34BA2.5060404@forrie.com> Date: Mon, 10 Jan 2005 22:44:34 -0500 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 1.0 (Windows/20041226) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean Subject: Timestamp on packets? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 03:42:43 -0000 After reading through the manpage for pfctl, I wonder if there's a mechanism/equivalent for PF that shows the timestamp of the last "hit" on a rule... similar to "ipfw -t"...? Thanks. From owner-freebsd-pf@FreeBSD.ORG Tue Jan 11 16:43:32 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5273A16A4CE for ; Tue, 11 Jan 2005 16:43:32 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id F223A43D2D for ; Tue, 11 Jan 2005 16:43:31 +0000 (GMT) (envelope-from brent.bolin@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so346095wri for ; Tue, 11 Jan 2005 08:43:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=BMYgfFclFb62pRu2BPOegAHWb8eHCn0rU0vWw0SBrCpbow7gbXU5kvvMwwJh50gldwIV30kHA3soEJrxFGHA+5qMszsyPigwcw2jSC6BB3AaEASzVEet/KjcvkTcz1c4d9XajkNPMMo3b7x6FNsxQMm96DuIhEAqphaQ6Ed3Y10= Received: by 10.54.54.71 with SMTP id c71mr131769wra; Tue, 11 Jan 2005 08:43:31 -0800 (PST) Received: by 10.54.4.54 with HTTP; Tue, 11 Jan 2005 08:43:31 -0800 (PST) Message-ID: <787dcac20501110843272dc7a1@mail.gmail.com> Date: Tue, 11 Jan 2005 10:43:31 -0600 From: BB To: FreeBSD-pf mail list Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: pflog0 not up after a reboot X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: BB List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 16:43:32 -0000 Hi all, I have this set in /etc/rc.conf but the interface never comes up. Have to do it manually. pf_logd="YES" pflog_logfile="/var/log/pflog" pflog_program="/sbin/pflogd" ifconfig pflog0 up This system was cvsup yesterday - tag=RELENG_5_3 From owner-freebsd-pf@FreeBSD.ORG Tue Jan 11 16:48:35 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150D216A4CE for ; Tue, 11 Jan 2005 16:48:35 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8290E43D3F for ; Tue, 11 Jan 2005 16:48:32 +0000 (GMT) (envelope-from dr.clau@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so346855wri for ; Tue, 11 Jan 2005 08:48:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:disposition-notification-to:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:x-enigmail-supports:content-type; b=iX/Ylur4zRzW89EvTj5xI82ShUS1LpsEzHBqFB0CE+KJCi8kD8vDC0ywBC40JfY6hRE6T6MOlTUG+cMqNUYGCwmcBTz31bsr7Dp3HQ+0kN2JXZGp9zkOZQhMfI2cop6V5M58sx72HqUSLIsLHBU+WZlfZM3dcDauJZOjmo1mkFo= Received: by 10.54.45.51 with SMTP id s51mr547427wrs; Tue, 11 Jan 2005 08:48:32 -0800 (PST) Received: from ?192.168.0.3? ([82.79.29.15]) by smtp.gmail.com with ESMTP id 33sm78640wra.2005.01.11.08.48.30; Tue, 11 Jan 2005 08:48:32 -0800 (PST) Message-ID: <41E4034E.8030206@gmail.com> Date: Tue, 11 Jan 2005 18:48:14 +0200 From: Claudiu Dragalia-Paraipan User-Agent: Mozilla Thunderbird 1.0 (X11/20041211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: BB References: <787dcac20501110843272dc7a1@mail.gmail.com> In-Reply-To: <787dcac20501110843272dc7a1@mail.gmail.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig188CCE43E12D68CA9E640544" cc: FreeBSD-pf mail list Subject: Re: pflog0 not up after a reboot X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 16:48:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig188CCE43E12D68CA9E640544 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I think that pf_logd="YES" should be pflog_enable="YES". cheers, Claudiu. BB wrote: > Hi all, > > I have this set in /etc/rc.conf but the interface never comes up. > Have to do it manually. > > pf_logd="YES" > pflog_logfile="/var/log/pflog" > pflog_program="/sbin/pflogd" > > ifconfig pflog0 up > > This system was cvsup yesterday - > > tag=RELENG_5_3 > _______________________________________________ > 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" > -- Claudiu Dragalina-Paraipan dr.clau@gmail.com --------------enig188CCE43E12D68CA9E640544 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5ANTm0FWxb+swkQRAn7+AJ4pDAOc/xmXEStq359WlYj6K1BoOQCdGHLR MaoXGaZY9m/N2ljJVGDZ4yA= =T9p8 -----END PGP SIGNATURE----- --------------enig188CCE43E12D68CA9E640544-- From owner-freebsd-pf@FreeBSD.ORG Wed Jan 12 16:13:28 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8390E16A4CE for ; Wed, 12 Jan 2005 16:13:28 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22C1943D2F for ; Wed, 12 Jan 2005 16:13:28 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Col7b-0001wD-00; Wed, 12 Jan 2005 17:13:23 +0100 Received: from [217.227.150.54] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Col7a-0001j7-00; Wed, 12 Jan 2005 17:13:23 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Wed, 12 Jan 2005 17:13:07 +0100 User-Agent: KMail/1.7.2 References: <41E34BA2.5060404@forrie.com> In-Reply-To: <41E34BA2.5060404@forrie.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2474564.Zk18hZCn0v"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501121713.17588.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: Timestamp on packets? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:13:28 -0000 --nextPart2474564.Zk18hZCn0v Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 January 2005 04:44, Forrest Aldrich wrote: > After reading through the manpage for pfctl, I wonder if there's a > mechanism/equivalent for PF that shows the timestamp of the last "hit" > on a rule... similar to "ipfw -t"...? No, there is no such functionality. In fact, we don't even store such data= in=20 the rules. For rules that create state, you can check the output of "$pfct= l=20 =2Dvvss" for the newest state for a certain rule. For rules that do loggin= g,=20 you can check /var/log/pflog for the last packet logged. I don't really see the point in this information. Why do you want to know= =20 this? Can you explain a bit - it's certainly not difficult to implement. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2474564.Zk18hZCn0v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5UydXyyEoT62BG0RAkSPAJwLhiULtjaV54R4dNHM4y3TqHgfEgCfU9+1 VK1qXjsmpZ/fd2jSuyDR52E= =VrsV -----END PGP SIGNATURE----- --nextPart2474564.Zk18hZCn0v-- From owner-freebsd-pf@FreeBSD.ORG Wed Jan 12 21:01:35 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D666016A4CF for ; Wed, 12 Jan 2005 21:01:35 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC42443D41 for ; Wed, 12 Jan 2005 21:01:34 +0000 (GMT) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CopcT-0002Pn-00 for ; Wed, 12 Jan 2005 22:01:33 +0100 Received: from ppp-62-245-162-183.mnet-online.de ([62.245.162.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Jan 2005 22:01:33 +0100 Received: from berni by ppp-62-245-162-183.mnet-online.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Jan 2005 22:01:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Bernhard Schmidt Date: Wed, 12 Jan 2005 21:01:14 +0000 (UTC) Lines: 24 Message-ID: References: <200501101507.10501.max@love2party.net> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ppp-62-245-162-183.mnet-online.de User-Agent: slrn/0.9.8.1 (Linux) Sender: news Subject: Re: Scalability of ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 21:01:36 -0000 Hi Max, > Generally speaking, 30-40Mbps are no problem. The limiting factor for pf > (as for any packet filter/firewall/etc.) is packets per second (pps). > In the end there is no alternative to just try it. In the worst case > scenario (with 64 byte per packet) this means about 625 kpps, which > will certainly overload most systems. An *average* packet size of > 400-800 byte/packet, however, resulting in 50-100 kpps, should already > be doable without problems. I just had a short look, on the busiest encapsulator we're doing 10 kpps at 40Mbps currently, I don't think it should rise up much more. > From a very first glance, I think HSFC is what best suits your application. > Here again, you must make sure not to overload your parent with the > client bandwidth. Hrm, I guess I'll just convert a current Packeteer policy to an pf one and have a look whether it loads smoothly. I heard today that we already have a Dell PE750 on stock, I think I'll give it a shot. In the end, a mirrored switchport to the BSD box should be sufficient to test. Thanks for your answers Bernhard From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 00:41:06 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F54C16A4CE for ; Thu, 13 Jan 2005 00:41:06 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E40543D1F for ; Thu, 13 Jan 2005 00:41:05 +0000 (GMT) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cot2u-0008GK-00 for ; Thu, 13 Jan 2005 01:41:04 +0100 Received: from ppp-62-245-162-183.mnet-online.de ([62.245.162.183]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Jan 2005 01:41:03 +0100 Received: from berni by ppp-62-245-162-183.mnet-online.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Jan 2005 01:41:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Bernhard Schmidt Date: Thu, 13 Jan 2005 00:40:51 +0000 (UTC) Lines: 38 Message-ID: References: <200501101507.10501.max@love2party.net> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ppp-62-245-162-183.mnet-online.de User-Agent: slrn/0.9.8.1 (Linux) Sender: news Subject: Re: Scalability of ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 00:41:06 -0000 On 2005-01-12, Bernhard Schmidt wrote: >> From a very first glance, I think HSFC is what best suits your application. >> Here again, you must make sure not to overload your parent with the >> client bandwidth. > Hrm, I guess I'll just convert a current Packeteer policy to an pf one > and have a look whether it loads smoothly. I heard today that we already > have a Dell PE750 on stock, I think I'll give it a shot. In the end, > a mirrored switchport to the BSD box should be sufficient to test. And me again ... I'm now having a problem where I'm not entirely sure whether I misunderstood the manpage or there is a bug in the parsing. I fell about some errors converting a small subset of our packeteer rules to pf. I created a testcase with the following config altq on vr1 hfsc bandwidth 5000001b queue { 1, 9999 } queue 1 hfsc(red, realtime 5000000b, upperlimit 5000000b) { 2 } queue 2 hfsc(red, realtime 4900000b, upperlimit 5000000b) { 3 } queue 3 hfsc(red, realtime 4800000b, upperlimit 5000000b) { 4 } queue 4 hfsc(red, realtime 4700000b, upperlimit 5000000b) queue 9999 hfsc(default, red, realtime 0b, upperlimit 5000000b) when loading I get pfctl: real-time sc exceeds the interface bandwidth pf.conf:3: errors in queue definition apparently when using subqueues pf adds up the realtime bandwidth of all queues and compares it to the interface bandwidth. To my understanding the sum of the bandwidth of all child queues should be compared to the direct parent queue. Am I wrong here? Of course I could increase the bandwidth parameter on vr1 to something really hillariously high, but is this the thing intended? Bernhard From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 05:49:56 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C816716A4CE for ; Thu, 13 Jan 2005 05:49:56 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id C50B443D1F for ; Thu, 13 Jan 2005 05:49:55 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Coxri-0002Of-00; Thu, 13 Jan 2005 06:49:50 +0100 Received: from [217.227.150.51] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Coxrh-0007D4-00; Thu, 13 Jan 2005 06:49:50 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Thu, 13 Jan 2005 06:49:40 +0100 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4036111.6t8qkiUj0U"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501130649.47241.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Bernhard Schmidt Subject: Re: Scalability of ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 05:49:57 -0000 --nextPart4036111.6t8qkiUj0U Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 01:40, Bernhard Schmidt wrote: > On 2005-01-12, Bernhard Schmidt wrote: > >> From a very first glance, I think HSFC is what best suits your > >> application. Here again, you must make sure not to overload your parent > >> with the client bandwidth. > > > > Hrm, I guess I'll just convert a current Packeteer policy to an pf one > > and have a look whether it loads smoothly. I heard today that we already > > have a Dell PE750 on stock, I think I'll give it a shot. In the end, > > a mirrored switchport to the BSD box should be sufficient to test. > > And me again ... I'm now having a problem where I'm not entirely sure > whether I misunderstood the manpage or there is a bug in the parsing. > > I fell about some errors converting a small subset of our packeteer > rules to pf. I created a testcase with the following config > > altq on vr1 hfsc bandwidth 5000001b queue { 1, 9999 } > queue 1 hfsc(red, realtime 5000000b, upperlimit 5000000b) { 2 } > queue 2 hfsc(red, realtime 4900000b, upperlimit 5000000b) { 3 } > queue 3 hfsc(red, realtime 4800000b, upperlimit 5000000b) { 4 } > queue 4 hfsc(red, realtime 4700000b, upperlimit 5000000b) > > queue 9999 hfsc(default, red, realtime 0b, upperlimit 5000000b) > > when loading I get > > pfctl: real-time sc exceeds the interface bandwidth > pf.conf:3: errors in queue definition > > apparently when using subqueues pf adds up the realtime bandwidth of all > queues and compares it to the interface bandwidth. To my understanding > the sum of the bandwidth of all child queues should be compared to the > direct parent queue. Am I wrong here? > > Of course I could increase the bandwidth parameter on vr1 to something > really hillariously high, but is this the thing intended? =46rom the manpage: > realtime > The minimum required bandwidth for the queue. ^--------------^ So this is the guaranteed minimum bandwidth that must be available to the=20 queue at any given time. The makes it clear that the interface must be abl= e=20 to provided the combined realtime bandwidth of all child queues. >=20 > upperlimit > The maximum allowed bandwidth for the queue. >=20 > linkshare > The bandwidth share of a backlogged queue. That's more what you seem to want. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4036111.6t8qkiUj0U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5gv7XyyEoT62BG0RAtWKAJ9Jp9z38joCcFe8tk5P6ONMmVJbNwCffURj gXubF85hiCnWiMZHCbVpeWg= =ePd8 -----END PGP SIGNATURE----- --nextPart4036111.6t8qkiUj0U-- From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 07:57:17 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 698B516A4CE for ; Thu, 13 Jan 2005 07:57:17 +0000 (GMT) Received: from smtp-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFB743D41 for ; Thu, 13 Jan 2005 07:57:17 +0000 (GMT) (envelope-from tyler@neo.tamu.edu) Received: from neo.tamu.edu (xyzzy-5.tamu.edu [165.91.22.29]) by smtp-relay.tamu.edu (8.12.10/8.12.10) with SMTP id j0D7vE5V028776 for ; Thu, 13 Jan 2005 01:57:14 -0600 (CST) Message-Id: <200501130757.j0D7vE5V028776@smtp-relay.tamu.edu> Date: Thu, 13 Jan 2005 07:57:14 -0000 To: From: "Ballance, Robert T" X-Mailer: TWIG 2.6.2 X-Client-IP: Subject: Bridging + pf in a production environment X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tyler@neo.tamu.edu List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 07:57:17 -0000 Howdy list, My university is starting to seriously look into migrating from our convoluted Slackware Linux + iptables bridging solution to a FreeBSD + pf bridging solution. I've been reading around about it, after the mention by Solarflux about there being problems currently with bridging with pf on FreeBSD. Which worries me, he mentioned the option of using OpenBSD, which, is an option, but whatever we commit to, we're going to commit to for a good couple of years. (We have been using Slackware for about 2 years thus far) Is anybody currently working on bringing of if_bridge from Net/OpenBSD as Max suggests (http://lists.freebsd.org/pipermail/freebsd-pf/2005-January/000734.html) If not, if anybody could really outline how fixing this problem could be fixed (past maybe just importing if_bridge) I might be able to convince my employer to pay me to work on it ;) (after all, I'm just a measely student worker :P) Let me know :) -R. Tyler Ballance From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 11:03:35 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC37016A4CE for ; Thu, 13 Jan 2005 11:03:35 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26DAB43D31 for ; Thu, 13 Jan 2005 11:03:35 +0000 (GMT) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cp2lK-00008G-00 for ; Thu, 13 Jan 2005 12:03:34 +0100 Received: from ppp-82-135-0-10.mnet-online.de ([82.135.0.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Jan 2005 12:03:33 +0100 Received: from berni by ppp-82-135-0-10.mnet-online.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Jan 2005 12:03:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Bernhard Schmidt Date: Thu, 13 Jan 2005 11:03:27 +0000 (UTC) Lines: 36 Message-ID: References: <200501130649.47241.max@love2party.net> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ppp-82-135-0-10.mnet-online.de User-Agent: slrn/0.9.8.1 (Linux) Sender: news Subject: Re: Scalability of ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 11:03:35 -0000 On 2005-01-13, Max Laier wrote: >> apparently when using subqueues pf adds up the realtime bandwidth of all >> queues and compares it to the interface bandwidth. To my understanding >> the sum of the bandwidth of all child queues should be compared to the >> direct parent queue. Am I wrong here? >> >> Of course I could increase the bandwidth parameter on vr1 to something >> really hillariously high, but is this the thing intended? > >From the manpage: >> realtime >> The minimum required bandwidth for the queue. > ^--------------^ > > So this is the guaranteed minimum bandwidth that must be available to the > queue at any given time. The makes it clear that the interface must be able > to provided the combined realtime bandwidth of all child queues. Okay, makes sense. >> >> upperlimit >> The maximum allowed bandwidth for the queue. >> >> linkshare >> The bandwidth share of a backlogged queue. > > That's more what you seem to want. So my commited bandwidth is linkshare, and the burst is upperlimit? Is there a good description on how these attributes influence hfsc's queueing? Thanks Bernhard From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 12:16:16 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9803C16A4CE for ; Thu, 13 Jan 2005 12:16:16 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4DB143D2D for ; Thu, 13 Jan 2005 12:16:15 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Cp3td-0005Mr-00; Thu, 13 Jan 2005 13:16:13 +0100 Received: from [217.227.150.51] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Cp3td-0002Ui-00; Thu, 13 Jan 2005 13:16:13 +0100 From: Max Laier To: freebsd-pf@freebsd.org, tyler@neo.tamu.edu Date: Thu, 13 Jan 2005 13:16:00 +0100 User-Agent: KMail/1.7.2 References: <200501130757.j0D7vE5V028776@smtp-relay.tamu.edu> In-Reply-To: <200501130757.j0D7vE5V028776@smtp-relay.tamu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3425888.IxU8yVtZud"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501131316.11379.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: Bridging + pf in a production environment X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 12:16:16 -0000 --nextPart3425888.IxU8yVtZud Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 08:57, Ballance, Robert T wrote: > Howdy list, > > My university is starting to seriously look into migrating from our > convoluted Slackware Linux + iptables bridging solution to a FreeBSD + pf > bridging solution. > > I've been reading around about it, after the mention by Solarflux about > there being problems currently with bridging with pf on FreeBSD. Which > worries me, he mentioned the option of using OpenBSD, which, is an option, > but whatever we commit to, we're going to commit to for a good couple of > years. (We have been using Slackware for about 2 years thus far) > > Is anybody currently working on bringing of if_bridge from Net/OpenBSD as > Max suggests > (http://lists.freebsd.org/pipermail/freebsd-pf/2005-January/000734.html) > > If not, if anybody could really outline how fixing this problem could be > fixed (past maybe just importing if_bridge) I might be able to convince my > employer to pay me to work on it ;) > (after all, I'm just a measely student worker :P) > > Let me know :) There is somebody working on it, but it is yet unclear how long until we se= e=20 results from that. Meanwhile, you might want to try the patch for bridge.c= =20 from Pyun YongHyeon which improves the situation already:=20 http://www.kr.freebsd.org/~yongari/patches/bridge.patch There might be a newer version of this patch here:=20 http://www.pfsense.org/downloads/bridge.patch.041215 =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3425888.IxU8yVtZud Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5maLXyyEoT62BG0RAt5CAJ9/dfa6hAVNbWRZFLsMzmB0WbuYgQCeOYbQ jJSvdOwtRYU65/u6+u6/rqM= =vsSa -----END PGP SIGNATURE----- --nextPart3425888.IxU8yVtZud-- From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 22:33:14 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9288D16A4CE for ; Thu, 13 Jan 2005 22:33:14 +0000 (GMT) Received: from mail.revolutionsp.com (ganymede.revolutionsp.com [64.246.0.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47F6743D39 for ; Thu, 13 Jan 2005 22:33:14 +0000 (GMT) (envelope-from security@revolutionsp.com) Received: from mail.revolutionsp.com (localhost [127.0.0.1]) by mail.revolutionsp.com (Postfix) with ESMTP id 12E8415C95 for ; Thu, 13 Jan 2005 13:28:10 -0600 (CST) Received: from 81.84.175.77 (SquirrelMail authenticated user security@revolutionsp.com); by mail.revolutionsp.com with HTTP; Thu, 13 Jan 2005 13:28:10 -0600 (CST) Message-ID: <53197.81.84.175.77.1105644490.squirrel@81.84.175.77> Date: Thu, 13 Jan 2005 13:28:10 -0600 (CST) From: security@revolutionsp.com To: freebsd-pf@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Two feature suggestions for pf.. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 22:33:14 -0000 Hi, I hope this is the right place to discuss this.. I've had a couple of features that I think would fit nicely in pf, but only now I'm sending this email.. First of all, I believe pf is the best firewall around, I've been using it since there was a port available to FreeBSD :-). Also, sorry if this was previously discussed as I did not check the archives. Here are my two proposed features for pf: 1) Add the username of the blocked packet to the pf log. Currently, it's hard to trace an outgoing blocked packet to a username unless you're watching real-time. For example: 2005-01-11 03:03:40.777286 rule 92/0(match): block out on em0: IP xxx.xxx.xxx.xxx.59167 > zzz.zzz.zzz.zzz.6667: FP 0:24(24) ack 1 win 32832 I think the username that triggered the rule would fit really nicely and would be really handy.. like this: 2005-01-11 03:03:40.777286 rule 92/0(match): block out on em0: IP xxx.xxx.xxx.xxx.59167 > zzz.zzz.zzz.zzz.6667: FP 0:24(24) ack 1 win 32832 user UserName This would greatly reduce the time needed to find someone abusing the firewall from inside the system, for example trying to portscan someone and most of the packets hitting the firewall.. This shouldn't be too hard to implement. 2) Different blocked traffic goes to different logfiles My other idea is based on the following concept.. Normally your server sits there, serving requests etc, blocks some scans on the firewall, random bruteforce attacks, and so on. But, if unfornately your server is a target of a DDoS attack, then all the attack log will be with the rest of the junk your server receives. Altough not impossible, filtering the log to obtain only the DDoS attack log for analysis still takes it's time. My suggestion is: Why not allow a directive on pf.conf that let's you specify to which logfile that rule should be logged to ? Using this model, you could set up some rules aimed at blocking traffic, but then the logging will be on it's own, private, separate file. You could set up several rules you know will never be matched unless there is an attempt to attack the server (etc), and, when matched, they'll be easily available on a (possibly) small logfile, instead of the geral, big big log. This also helps a lot tracking failed attack attempts, each on it's own log.. thus cutting down the time one needs to find any blocked packets in the logs: You always know it will be in file A,B,C.. Again, if these have already been discussed in the past, I'm sorry. If not, please give some feedback. From owner-freebsd-pf@FreeBSD.ORG Thu Jan 13 23:40:27 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E202B16A4CE for ; Thu, 13 Jan 2005 23:40:27 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFF0F43D68 for ; Thu, 13 Jan 2005 23:40:24 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CpEZi-0005TY-00; Fri, 14 Jan 2005 00:40:22 +0100 Received: from [217.227.150.51] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CpEZh-0006JI-00; Fri, 14 Jan 2005 00:40:22 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Fri, 14 Jan 2005 00:40:00 +0100 User-Agent: KMail/1.7.2 References: <53197.81.84.175.77.1105644490.squirrel@81.84.175.77> In-Reply-To: <53197.81.84.175.77.1105644490.squirrel@81.84.175.77> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3296732.ilp3DIKOYj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501140040.10885.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: Two feature suggestions for pf.. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 23:40:28 -0000 --nextPart3296732.ilp3DIKOYj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 20:28, security@revolutionsp.com wrote: > Hi, > > I hope this is the right place to discuss this.. I've had a couple of > features that I think would fit nicely in pf, but only now I'm sending > this email.. =46irst of all, thanks. Second of all, I'd like to repeat what I said some= time=20 or another: I see pf4FreeBSD as a port not as a fork, hence I encourage tha= t=20 you bring up suggestions for new features with the OpenBSD folks - unless=20 it's a FreeBSD specific - first. Once it makes it's way into a new OpenBSD= =20 release it will also make it's way into FreeBSD (sooner or later). > First of all, I believe pf is the best firewall around, I've been using it > since there was a port available to FreeBSD :-). Also, sorry if this was > previously discussed as I did not check the archives. > > Here are my two proposed features for pf: > > 1) Add the username of the blocked packet to the pf log. Currently, it's > hard to trace an outgoing blocked packet to a username unless you're > watching real-time. For example: > > 2005-01-11 03:03:40.777286 rule 92/0(match): block out on em0: IP > xxx.xxx.xxx.xxx.59167 > zzz.zzz.zzz.zzz.6667: FP 0:24(24) ack 1 win 32832 > > > I think the username that triggered the rule would fit really nicely and > would be really handy.. like this: > > 2005-01-11 03:03:40.777286 rule 92/0(match): block out on em0: IP > xxx.xxx.xxx.xxx.59167 > zzz.zzz.zzz.zzz.6667: FP 0:24(24) ack 1 win 32832 > user UserName > > This would greatly reduce the time needed to find someone abusing the > firewall from inside the system, for example trying to portscan someone > and most of the packets hitting the firewall.. This shouldn't be too hard > to implement. Though I agree that this might be helpful on busy, multiuser shell servers,= I=20 don't think it will happen. For one, it's overly expensive to look up the= =20 user to a socket. Moreover, it's not the job of the firewall to enforce=20 local restrictions (or to log local events). If you want sophisticated=20 control (and logging) of the activity of your local user you can either use= =20 the MAC framework or restrict possible evildoers into jails. Hacking it in= to=20 pf is not a good idea - IMO. > 2) Different blocked traffic goes to different logfiles > > My other idea is based on the following concept.. Normally your server > sits there, serving requests etc, blocks some scans on the firewall, > random bruteforce attacks, and so on. But, if unfornately your server is a > target of a DDoS attack, then all the attack log will be with the rest of > the junk your server receives. Altough not impossible, filtering the log > to obtain only the DDoS attack log for analysis still takes it's time. My > suggestion is: Why not allow a directive on pf.conf that let's you specify > to which logfile that rule should be logged to ? Using this model, you > could set up some rules aimed at blocking traffic, but then the logging > will be on it's own, private, separate file. You could set up several > rules you know will never be matched unless there is an attempt to attack > the server (etc), and, when matched, they'll be easily available on a > (possibly) small logfile, instead of the geral, big big log. > This also helps a lot tracking failed attack attempts, each on it's own > log.. thus cutting down the time one needs to find any blocked packets in > the logs: You always know it will be in file A,B,C.. You can do that. Tcpdump/libpcap offer means to filter on a certain rule=20 number etc. You can either have pflogd logging all into one (big) logfile= =20 and split it afterwards with tcpdump -r or you can write a modified pflogd= =20 that would do the splitting online. > Again, if these have already been discussed in the past, I'm sorry. If > not, please give some feedback. Not really discussed before (if my memory servers me right), but don't worr= y=20 about such things too much. Feedback and suggestions greatly appreciated. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3296732.ilp3DIKOYj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5wbaXyyEoT62BG0RArF3AJ9KKamzG8fRroDYwJKEmCF8vCr6XQCaA6Fw VV5nEhqIyw4kz1XK72Q+Ifo= =Iojk -----END PGP SIGNATURE----- --nextPart3296732.ilp3DIKOYj-- From owner-freebsd-pf@FreeBSD.ORG Sat Jan 15 05:58:32 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ADEC16A4CE for ; Sat, 15 Jan 2005 05:58:32 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1BBC43D3F for ; Sat, 15 Jan 2005 05:58:31 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [192.168.1.99] (i-99.forrie.net. [192.168.1.99]) (authenticated bits=0) by forrie.com with ESMTP id j0F5wRo8009522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 15 Jan 2005 00:58:27 -0500 (EST) (envelope-from forrie@forrie.com) Message-ID: <41E8B102.20706@forrie.com> Date: Sat, 15 Jan 2005 00:58:26 -0500 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 1.0 (Windows/20041226) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean Subject: How to determine "hits" on rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 05:58:32 -0000 I'm migrating one of my systems to PF from IPFW. In so doing and planning, I've reviewed the manpages and some online literature. I've become dependent upon "ipfw -t" to determine hits on various spam rules I've implemented - some of them large lists of /24's. I've not been able to determine that there is an equivalent in PF - though I imagine there must be some method to accomplish this. I'd appreciate if someone could help point in the right direction. Thank you. From owner-freebsd-pf@FreeBSD.ORG Sat Jan 15 17:23:56 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3273316A4CE for ; Sat, 15 Jan 2005 17:23:56 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82A2843D2D for ; Sat, 15 Jan 2005 17:23:55 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CpreS-0006dU-00; Sat, 15 Jan 2005 18:23:52 +0100 Received: from [217.227.148.121] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CpreR-0000aW-00; Sat, 15 Jan 2005 18:23:51 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Sat, 15 Jan 2005 18:23:37 +0100 User-Agent: KMail/1.7.2 References: <41E8B102.20706@forrie.com> In-Reply-To: <41E8B102.20706@forrie.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1791697.6OMcbFaPMA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501151823.45078.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: How to determine "hits" on rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 17:23:56 -0000 --nextPart1791697.6OMcbFaPMA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 15 January 2005 06:58, Forrest Aldrich wrote: > I'm migrating one of my systems to PF from IPFW. > > In so doing and planning, I've reviewed the manpages and some online > literature. > > I've become dependent upon "ipfw -t" to determine hits on various spam > rules I've implemented - some of them large lists of /24's. > > I've not been able to determine that there is an equivalent in PF - > though I imagine there must be some method to accomplish this. > > I'd appreciate if someone could help point in the right direction. On Wednesday 12 January 2005 17:13, I wrote: > No, there is no such functionality. In fact, we don't even store such da= ta > in the rules. For rules that create state, you can check the output of > "$pfctl -vvss" for the newest state for a certain rule. For rules that do > logging, you can check /var/log/pflog for the last packet logged. > > I don't really see the point in this information. Why do you want to know > this? Can you explain a bit - it's certainly not difficult to implement. In any case: "pfctl -vsr" will give you counters on each rule. If you use a table to store the spammer-addresses, you might find: "pfctl=20 =2DvvTshow -t table_name" interesting. Check: http://www.benzedrine.cx/relaydb.html for a step-by-step tutorial, h= ow=20 to deal with spammers with the help of pf. This might give you some ideas. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1791697.6OMcbFaPMA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB6VGgXyyEoT62BG0RAsPhAJ98F4R7ILyOpJM1rfgILPcPPW9uKQCdGZcQ P6B54jXUBkua73dxx/vohIc= =ntxA -----END PGP SIGNATURE----- --nextPart1791697.6OMcbFaPMA--