PF Scrub
Hello All, Just a quick question. I am doing scrub on my upstream OpenBSD server. Will this work as a temporary workaround for this security flaw (below) in FreeBSD? Regards Mark -Forwarded Message- From: FreeBSD Security Advisories [EMAIL PROTECTED] To: FreeBSD Security Advisories [EMAIL PROTECTED] Subject: FreeBSD Security Advisory FreeBSD-SA-04:04.tcp Date: Tue, 02 Mar 2004 11:55:44 -0800 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-04:04.tcp Security Advisory The FreeBSD Project Topic: many out-of-sequence TCP packets denial-of-service Category: core Module: kernel Announced: 2004-03-02 Credits:iDEFENSE Affects:All FreeBSD releases Corrected: 2004-03-02 17:19:18 UTC (RELENG_4) 2004-03-02 17:24:46 UTC (RELENG_5_2, 5.2.1-RELEASE-p1) 2004-03-02 17:26:33 UTC (RELENG_4_9, 4.9-RELEASE-p3) 2004-03-02 17:27:47 UTC (RELENG_4_8, 4.8-RELEASE-p16) CVE Name: CAN-2004-0171 FreeBSD only: NO I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. When network packets making up a TCP stream (``TCP segments'') are received out-of-sequence, they are maintained in a reassembly queue by the destination system until they can be re-ordered and re-assembled. II. Problem Description FreeBSD does not limit the number of TCP segments that may be held in a reassembly queue. III. Impact A remote attacker may conduct a low-bandwidth denial-of-service attack against a machine providing services based on TCP (there are many such services, including HTTP, SMTP, and FTP). By sending many out-of-sequence TCP segments, the attacker can cause the target machine to consume all available memory buffers (``mbufs''), likely leading to a system crash. IV. Workaround It may be possible to mitigate some denial-of-service attacks by implementing timeouts at the application level. V. Solution Do one of the following: 1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2, RELENG_4_9, or RELENG_4_8 security branch dated after the correction date. OR 2) Patch your present system: The following patch has been verified to apply to FreeBSD 4.x and 5.x systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 5.2] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc [FreeBSD 4.8, 4.9] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp47.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp47.patch.asc b) Apply the patch. # cd /usr/src # patch /path/to/patch c) Recompile your kernel as described in URL:http://www.freebsd.org/handbook/kernelconfig.html and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_4 src/UPDATING 1.73.2.90 src/sys/conf/newvers.sh 1.44.2.33 src/sys/netinet/tcp_input.c 1.107.2.40 src/sys/netinet/tcp_subr.c1.73.2.33 src/sys/netinet/tcp_var.h 1.56.2.15 RELENG_5_2 src/UPDATING 1.282.2.9 src/sys/conf/newvers.sh1.56.2.8 src/sys/netinet/tcp_input.c 1.217.2.2 src/sys/netinet/tcp_subr.c1.169.2.4 src/sys/netinet/tcp_var.h 1.93.2.2 RELENG_4_9 src/UPDATING 1.73.2.89.2.4 src/sys/conf/newvers.sh 1.44.2.32.2.4 src/sys/netinet/tcp_input.c 1.107.2.38.2.1 src/sys/netinet/tcp_subr.c1.73.2.31.4.1 src/sys/netinet/tcp_var.h 1.56.2.13.4.1 RELENG_4_8 src/UPDATING 1.73.2.80.2.19 src/sys/conf/newvers.sh 1.44.2.29.2.17 src/sys/netinet/tcp_input.c 1.107.2.37.2.1 src/sys/netinet/tcp_subr.c1.73.2.31.2.1 src/sys/netinet/tcp_var.h 1.56.2.13.2.1 -
Re: source routing
FreeBSD root.x86.co.za 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 #0: Tue Oct 21 15:11:48 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys.altq/i386/compile/X86 i386 I will try cvsup all my source and recompile world/kernel I'm not loafing. I work so fast I'm always finished On Sat, 25 Oct 2003, Pyun YongHyeon wrote: On Fri, Oct 24, 2003 at 04:53:20PM +0200, Daniel Hartmeier wrote: On Fri, Oct 24, 2003 at 04:44:54PM +0200, Mark Bojara wrote: blowfish:~# tcpdump -s 1600 - -i tun0 tcpdump: listening on tun0 16:37:33.073615 truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request (ttl 64, id 18799, len 21504, bad cksum c89!) That looks suspiciously like a byte order problem, the packet has a size of 84 bytes. If you switch byte order (0*256 + 84 vs. 84*256 + 0) you get 21504, and tcpdump reports 21420 (21504 - 84) bytes missing. Max, does that ring a bell? ;) Do you run pf on -CURRENT? What FreeBSD pf version do you use? This is a small delta that cksum mismatch can show up on -CURRENT. (__FreeBSD_version 501105) -- Pyun YongHyeon http://www.kr.freebsd.org/~yongari
Re: source routing
Hello Daniel, I want option a. It must route the packet to 192.168.0.1 exactly how it is without modifying any headers. on 192.168.0.1 there is NAT on it wich will handle translation. On 192.168.0.2 (localhost): x86:~# tcpdump -e -i tun1 tcpdump: listening on tun1 16:03:31.375841 ip 84: 192.168.0.2 apollo.is.co.za: icmp: echo request 16:03:32.383138 ip 84: 192.168.0.2 apollo.is.co.za: icmp: echo request 16:03:33.393145 ip 84: 192.168.0.2 apollo.is.co.za: icmp: echo request On 192.168.0.1 (remote gateway): blowfish:~# tcpdump -e -i tun0 tcpdump: listening on tun0 16:00:25.851705 ip 84: truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request 16:00:26.859140 ip 84: truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request 16:00:27.868135 ip 84: truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request Thank you for your time Mark The best defense against logic is stupidity. On Fri, 24 Oct 2003, Daniel Hartmeier wrote: On Thu, Oct 23, 2003 at 03:36:22PM +0200, Mark Bojara wrote: rdr on ! tun1 inet from 192.168.0.2 to any - 192.168.0.1 rdr and route-to do two different things in your setup, it's not clear yet what you really want: a) route-to will not modify the IP layer, it will just cause the packets to get sent to the MAC address of 192.168.0.1 on ethernet layer. Run tcpdump with -e on tun1 and check the destination MAC address of outgoing packets. Without the route-to rule, everything should go to the default route's MAC address. With the route-to rule, packets from 192.168.0.0/30 should go to 192.168.0.1's MAC address. The IP destination addresses should be the same, as route-to doesn't change them. And the packet will end up at the same IP endpoint, as the destination IP address wasn't modified. b) rdr (on the interface where the packets come in, tun0) can replace the IP destination address of packets. This redirects the packets to another endpoint (not just through other routes). Of course, a different destination IP address might cause the intermediate routers to chose different paths, so a redirection will affect routing in that sense. For example, redirecting a HTTP query (port 80) with rdr to a router not running a web server would be wrong. If you just want to route through that router (reaching the original web server), use route-to. So, do you want a) or b) or something else? Daniel
Re: source routing
On Fri, 24 Oct 2003, Daniel Hartmeier wrote: On Fri, Oct 24, 2003 at 04:07:20PM +0200, Mark Bojara wrote: I want option a. It must route the packet to 192.168.0.1 exactly how it is without modifying any headers. on 192.168.0.1 there is NAT on it wich will handle translation. Ok, so let's look at the destination MAC addresses. On 192.168.0.2 (localhost): x86:~# tcpdump -e -i tun1 tcpdump: listening on tun1 16:03:31.375841 ip 84: 192.168.0.2 apollo.is.co.za: icmp: echo request It seems FreeBSD tcpdump uses different parameters (-e doesn't print ethernet addresses, obviously). Can you check your manpage and re-run these with the option that prints the ethernet addresses (link-level header)? On OpenBSD, it's # tcpdump -nei gem0 16:14:00.852256 0:10:a7:17:1a:c0 0:a:95:6d:aa:98 0800 102: 10.1.1.145 10.1.1.60: icmp: echo request (DF) This works on fxp0 but on tun1 it doesnt work.. probably because its a virtual interface.. I am using vtund to open this tunnel. On 192.168.0.1 (remote gateway): blowfish:~# tcpdump -e -i tun0 tcpdump: listening on tun0 16:00:25.851705 ip 84: truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request Oh, so the packets do arrive at the other gateway (the one you want route-to to send them to, not the default gateway)? In that case the route-to rule worked fine. Is the other gateway just dropping them (because of truncation or invalid checksums)? Run tcpdump with options that increase snaplen to 1600 (-s 1600) and print checksum mismatches (-vvv), to check. Yes it must send them to 192.168.0.1 like you said :-) looks like a invalud checksum.. blowfish:~# tcpdump -s 1600 - -i tun0 tcpdump: listening on tun0 16:37:33.073615 truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request (ttl 64, id 18799, len 21504, bad cksum c89!) 16:37:34.081416 truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request (ttl 64, id 62063, len 21504, bad cksum 6388!) 16:37:35.091243 truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request (ttl 64, id 44413, len 21504, bad cksum a87a!) 16:37:36.101231 truncated-ip - 21420 bytes missing! 192.168.0.2 apollo.is.co.za: icmp: echo request (ttl 64, id 6685, len 21504, bad cksum 3bdb!) Daniel Mark
source routing
Hello All, I bet this subject has come up a couple of times. But searching through the previous threads i could not find a working solution for me. I recently compiled pf/altq in FreeBSD 5.1 to see how it runs. I am trying to set up so that all traffic comming from 192.168.0.2 is routed to 192.168.0.1. My default route points to tun0 and 192.168.0.0/30 sits on tun1. in FreeBSD's ipfw i do: ipfw add fwd 192.168.0.1 ip from 192.168.0.0/30 to any via tun0 (this works fine) in PF i do: pass out quick on tun0 route-to (tun1 192.168.0.1) from 192.168.0.0/30 to any This does not work.. I reall dislike ipfw and would like to get the whole system working on PF. Thanks alot Mark Bojara
Re: pf tagging - squid
Hello Henning, Maybe this is a long shot, But how about creating a virtual interface (suggestions?) Then in squid setting the tcp_outgoing_address to the same as the virtual interface and doing the tagging on that virtual interface.. Let me know what you think. Thanks Mark Make up a language and ask people for directions. On Wed, 15 Oct 2003, Henning Brauer wrote: all mbuf tags get lost (of course) when the packets travels through userland. well, in fact, all mbuf tags get lost as soon as the packet leaves the kernel, in either direction - userland, or network. not really a way around it. On Wed, Oct 15, 2003 at 10:15:07PM +0200, Mark Bojara wrote: Hello All, Im running a HFSC setup with a squid server hosted on the same machine. I am having problems putting this traffic in a queue. So I decided to make it a transparent proxy. On my pf I tagged the packets on the internal interface comming into the squid server then tried to match it on the external interface. This doesnt work because the internal tags gets lost when squid makes the request to fetch the object.. fxp0 being internal and tun0 the external.. pass out on fxp0 all tagged opium keep state queue opium pass in on tun0 inet from 10.10.10.2 to any tag opium keep state (tried it the other way around aswell) If i could use PF to set a TOS on the internal interface then i could easily match it on the external inferface when squid fetch's the object. But there is no such option. Anybody have any idea's? Maybe even a completely new solution? Thanks Alot Mark Bojara -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: packet filtering
Just some feedback on this.. I did get it to work after endless nights ;-) my rules: block in log on fxp0 from any to opium pass in on vlan1 from opium to any tag outgoing keep state queue opium_d_l pass on fxp0 all tagged outgoing keep state pass in on fxp0 proto tcp from any to opium port 22 keep state queue opium_u_l pass in on fxp0 proto tcp from any to opium port 80 keep state queue opium_u_l opium_d_l is located on xl0 (xl0 is parent vlan interface) opium_u_l is located on fxp0 I can shape traffic both incoming and outgoing with packet filtering.. hope this helps somebody.. Regards Mark What do batteries run on? On Sun, 3 Aug 2003, Mark Bojara wrote: Hello Trevor/Daniel, Sorry for late reply I was on leave. When I only have a pass log rule and telnet to 196.4.160.2 53 I get this: 23:18:54.694500 opium.co.za.4774 apollo.is.co.za.domain: S 4194577793:4194577793(0) win 65535 mss 1460,nop,wscale 0,[|tcp] (DF) [tos 0x10] 23:18:54.694504 opium.co.za.4774 apollo.is.co.za.domain: S 4194577793:4194577793(0) win 65535 mss 1460,nop,wscale 0,[|tcp] (DF) [tos 0x10] 23:18:54.695252 apollo.is.co.za.domain opium.co.za.4774: S 600052628:600052628(0) ack 4194577794 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) 23:18:54.695256 apollo.is.co.za.domain opium.co.za.4774: S 600052628:600052628(0) ack 4194577794 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) Connection is successful.. What I am trying to achieve is stateful filtering on seperate interface's for one host. The reason why I am doing this is so that my queueing can operate for incoming and outgoing traffic. traffic for 196.34.165.210 first comes into fxp0 then is routed to vlan1 (xl0 parent).. When I use the below filter rules I get the blocked matches on pflog0 that i sent in my previous email. block in log on fxp0 from any to 196.34.165.210 pass in on fxp0 proto tcp from any to 196.34.165.210 port 22 pass out on vlan1 from 196.34.165.210 to any keep state If I would swop the pass out rule so that it is on fxp0 it will work fine but that defeats the purpose I need it for. Any ideas? Thanks Mark Shin: A device for finding furniture in the dark. On Thu, 31 Jul 2003, Trevor Talbot wrote: On Wednesday, Jul 30, 2003, at 16:24 US/Pacific, Mark Bojara wrote: Here is my tcpdump of pflog0: Jul 31 01:23:48.272259 rule 1/0(match): block in on fxp0: 196.4.160.2.53 196.34.165.210.1588: S 1318784553:1318784553(0) ack 1889327994 win 65535 mss 1380,nop,nop,timestamp[|tcp] Jul 31 01:23:56.876904 rule 1/0(match): block in on fxp0: 196.4.160.2.53 196.34.165.210.1589: S 1764338029:1764338029(0) ack 4153205723 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) that is what i am getting when i try and telnet to 196.4.160.2 53 from 196.34.165.210 The second filter rule must be a block rule that affects fxp0? Daniel's suggestion was for a single pass log-all rule, with no other rules. That way you can follow all packets in both directions through all interfaces pf sees. It should be easy to build a ruleset after that.
Re: packet filtering
Hello Trevor/Daniel, Sorry for late reply I was on leave. When I only have a pass log rule and telnet to 196.4.160.2 53 I get this: 23:18:54.694500 opium.co.za.4774 apollo.is.co.za.domain: S 4194577793:4194577793(0) win 65535 mss 1460,nop,wscale 0,[|tcp] (DF) [tos 0x10] 23:18:54.694504 opium.co.za.4774 apollo.is.co.za.domain: S 4194577793:4194577793(0) win 65535 mss 1460,nop,wscale 0,[|tcp] (DF) [tos 0x10] 23:18:54.695252 apollo.is.co.za.domain opium.co.za.4774: S 600052628:600052628(0) ack 4194577794 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) 23:18:54.695256 apollo.is.co.za.domain opium.co.za.4774: S 600052628:600052628(0) ack 4194577794 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) Connection is successful.. What I am trying to achieve is stateful filtering on seperate interface's for one host. The reason why I am doing this is so that my queueing can operate for incoming and outgoing traffic. traffic for 196.34.165.210 first comes into fxp0 then is routed to vlan1 (xl0 parent).. When I use the below filter rules I get the blocked matches on pflog0 that i sent in my previous email. block in log on fxp0 from any to 196.34.165.210 pass in on fxp0 proto tcp from any to 196.34.165.210 port 22 pass out on vlan1 from 196.34.165.210 to any keep state If I would swop the pass out rule so that it is on fxp0 it will work fine but that defeats the purpose I need it for. Any ideas? Thanks Mark Shin: A device for finding furniture in the dark. On Thu, 31 Jul 2003, Trevor Talbot wrote: On Wednesday, Jul 30, 2003, at 16:24 US/Pacific, Mark Bojara wrote: Here is my tcpdump of pflog0: Jul 31 01:23:48.272259 rule 1/0(match): block in on fxp0: 196.4.160.2.53 196.34.165.210.1588: S 1318784553:1318784553(0) ack 1889327994 win 65535 mss 1380,nop,nop,timestamp[|tcp] Jul 31 01:23:56.876904 rule 1/0(match): block in on fxp0: 196.4.160.2.53 196.34.165.210.1589: S 1764338029:1764338029(0) ack 4153205723 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) that is what i am getting when i try and telnet to 196.4.160.2 53 from 196.34.165.210 The second filter rule must be a block rule that affects fxp0? Daniel's suggestion was for a single pass log-all rule, with no other rules. That way you can follow all packets in both directions through all interfaces pf sees. It should be easy to build a ruleset after that.
altq with vlan
Hello,
I have set up vlan's on my 3com switch with vlan devices on my openbsd
server to accomodate my altq properly. However I can not seem to tag any
packets on vlan1 or xl0 (parent interface). The prupose is to do both
incoming/outgoing queue's on normal interface's my setup works fine. How
can get around this for vlan setup?
I am running 3.3-current the latest cvsup version.
Thanks in advance
Mark
Beware of Geeks bearing gifs.
table opium { 196.34.165.210 }
set timeout { interval 30, frag 10 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set limit { states 100, frags 15 }
set loginterface none
set optimization normal
set block-policy drop
set require-order yes
scrub in on fxp0 all random-id no-df fragment reassemble
altq on fxp0 bandwidth 10Mb hfsc queue { std_u, local_u }
queue std_u bandwidth 32Kb hfsc(default upperlimit 768Kb) # change this
queue local_u bandwidth 768Kb hfsc(upperlimit 768Kb) { \
opium_u_l \
}
queue opium_u_l bandwidth 32Kb hfsc(upperlimit 32Kb)
altq on xl0 bandwidth 100Mb hfsc queue { mics, std_d, local_d }
queue std_d bandwidth 32Kb hfsc(default upperlimit 768Kb) # change this
queue mics bandwidth 2Mb
# Downstream - Local Bandwidth
queue local_d bandwidth 768Kb hfsc(upperlimit 768Kb) { \
opium_d_l \
}
queue opium_d_l bandwidth 32Kb hfsc(upperlimit 32Kb)
pass in on fxp0 from any to opium keep state queue opium_u_l
pass in on vlan1 from opium to any keep state queue opium_d_l
block in on fxp0 from any to opium
Re: altq with vlan
Hello Daniel, Sorry my mistake, The packets are being tagged. However I do not have any incoming or outgoing access. This is probably a error with my filters. Do you have any advice on what i could try? Thanks Mark (A)bort, (R)etry, (F)orget It! On Wed, 30 Jul 2003, Daniel Hartmeier wrote: First, check whether your rules match: $ pfctl -vsr | grep -A 1 queue If they do, check whether tagged packets get queued: $ pfctl -vsq Daniel
Re: packet filtering
Hello Ryan, fxp0 is the uplink interface and xl0 is the interface that the vlan is connected too. If i tcpdump xl0 I can see traffic from all the vlan's on it. Regards Mark Universe is a big place... perhaps the biggest On Wed, 30 Jul 2003, Ryan McBride wrote: On Thu, Jul 31, 2003 at 12:26:21AM +0200, Daniel Hartmeier wrote: I'm not entirely sure, but the assumption that the same packet will be filtered both on the real and the vlan interface (in both directions) might just be wrong. My experience is that the packet will appear on one interface or the other, but not both. IE if it is tagged with a vlan id which is associated with a vlan interface, it will not appear on the physical interface. -Ryan
Re: packet filtering
Hello Daniel, Here is my tcpdump of pflog0: Jul 31 01:23:48.272259 rule 1/0(match): block in on fxp0: 196.4.160.2.53 196.34.165.210.1588: S 1318784553:1318784553(0) ack 1889327994 win 65535 mss 1380,nop,nop,timestamp[|tcp] Jul 31 01:23:56.876904 rule 1/0(match): block in on fxp0: 196.4.160.2.53 196.34.165.210.1589: S 1764338029:1764338029(0) ack 4153205723 win 65535 mss 1380,nop,nop,timestamp[|tcp] (DF) that is what i am getting when i try and telnet to 196.4.160.2 53 from 196.34.165.210 Regards Mark These shoes look like Frankenstein's hand-me-downs. On Thu, 31 Jul 2003, Daniel Hartmeier wrote: On Thu, Jul 31, 2003 at 12:40:53AM +0200, Mark Bojara wrote: The packets get blocked after fxp0 and do not reach vlan1. Basically I want to do incoming filtering on one interface and outgoing filtering on another interface, reason being that i will eventually use it for queue's to shape incoming/outgoing on top of that. So try the suggested rule. It will tell you what packets get filtered on which interfaces, then we know what rules you'll need to pass what you want... BTW, packets can get sent to bpf for an interface even though pf is not invoked to filter them there, at least theoretically. Daniel
passive ftp
Hello All, How can I allow passive ftp to certain hosts? I know that you can do it by allowing ports 49152-65535 to the host but that isnt very secure, is there a better way? Thanks Mark
virtual interface
Hello, Ive just been thinking of a possible solution to my problem on previous thread. How about I create vlan's and bridge them together. So that it forms something like: fxp0--altq--virtual interface--altq--dc?--host ive tried doing something like: ifconfig vlan0 vlan 1 vlandev dc0 ifconfig vlan1 vlan 1 vlandev dc1 brconfig bridge0 add vlan0 add vlan1 up This doesnt work at all.. I think I have the right idea but im not sure how to implement it. Thanks guys for all your help so far :-) Chow Mark
Re: stateful filters affect queue filters
Hello Trevor, Thanks for the advice, Ive tried to have one rule to catch both directions but if it is outgoing traffic then the keepstate will automatically allocate the incoming packets that are comming back to the same queue. But if the request originated from a incoming request there is no way possible that the same outgoing queue will work for that traffic. Unless im wrong.. Regards Mark Do not fumble with a woman's logic. On Tue, 22 Jul 2003, Trevor Talbot wrote: On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote: On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up. I consider this flags filtering stupid. Well true, if you aren't using modulate state, there isn't much point. Mark's situation could be handled with just rule reorganization. He currently has rules that catch both directions, and my impression is that he didn't really want connections being initiated in both directions. So I ended up suggesting that, instead of realizing both rules aren't necessary now that keep state is present.
Re: stateful filters affect queue filters
Hello Trevor, I understand what you mean but this is only for a outgoing connection with keepstated incoming. If another completely different incoming connection gets established then since it did not orignate as a outgoing connection the keep state will not apply. I mind have two seperate queue's for incoming/outgoing (one would be better tho) but i would like all the shaping to happen on one interface only without shaping on the interface the host is connected too. Regards Mark I smell a rat. Did you bake it or fry it? On Wed, 23 Jul 2003, Trevor Talbot wrote: On Tuesday, Jul 22, 2003, at 23:46 US/Pacific, Mark Bojara wrote: Thanks for the advice, Ive tried to have one rule to catch both directions but if it is outgoing traffic then the keepstate will automatically allocate the incoming packets that are comming back to the same queue. But if the request originated from a incoming request there is no way possible that the same outgoing queue will work for that traffic. When a state entry is created, it saves an internal queue ID tag. Every packet that matches the state gets tagged with that queue ID, no matter which direction it's going. Later, when the packet is about to physically travel out of an interface, ALTQ retrieves the tag and looks for a matching queue on that interface. If it finds one, the packet goes there; if not, it goes in the default queue. The last tag applied is the one ALTQ sees. So, for a given packet, it has two potential tag points: -- [IN tag] ---[ forward ]--- [OUT tag] --[ altq ]-- If it's tagged in the OUT slot, that's the one ALTQ sees, whether it was tagged on the IN slot or not. In your setup, this is what you want to happen every time. It's also possible to tag it on the IN slot, for a queue that actually resides on the OUT interface. You don't do this (and don't need to, from what I see), but it's possible. Anyway, the tagging in the state entry happens no matter which direction the packet is traveling. Thus, when you create a state on an inbound packet, the queue tag will only matter for reply packets (going back out on that interface). The inbound packets will still be tagged, but the tags don't match any queue on the interface they go out on, so nothing happens. Meanwhile, you also have a rule to create state out on that other interface, and that queue tag does apply. You should keep the one-rule-per-interface setup, i.e. pass in on $i01, pass out on $i03. You should also set each rule to use the appropriate queue on that same interface, no matter which direction the rule is for. Does that make sense? On Tue, 22 Jul 2003, Trevor Talbot wrote: On Tuesday, Jul 22, 2003, at 06:43 US/Pacific, Henning Brauer wrote: On Tue, Jul 22, 2003 at 02:55:47AM -0700, Trevor Talbot wrote: Also note that most of your rules are a bit loose as far as TCP goes. The upside is that they'll pick up existing connections when you reboot/reconfigure the firewall, but you may want to get more control over which direction connections are initiated from by using flags S/SA with all of them. It depends on your situation; this is just a heads up. I consider this flags filtering stupid. Well true, if you aren't using modulate state, there isn't much point. Mark's situation could be handled with just rule reorganization. He currently has rules that catch both directions, and my impression is that he didn't really want connections being initiated in both directions. So I ended up suggesting that, instead of realizing both rules aren't necessary now that keep state is present.
incoming outgoing queue on single interface/queue
Hello, I was wondering if its possible to either set up one queue on a single interface to do both incoming and outgoing traffic? (probably not possible) Or maybe possibly having it on split interface's but assigned to one queue. eg: pass out on dc1 from za to 196.34.165.210 keep state queue opium_01_l pass in on fxp0 from za to 196.34.165.210 keep state queue opium_01_l I have tried this but it doesnt work, probably because that specific queue is assigned to fxp0 so the dc1 filter will not work. Does anybody have any ideas on how i could do this? Thanks alot, Mark Trill: The musical equivalent of an epileptic seizure.
Re: stateful filters affect queue filters
this basically boils down to the next thread I began. Since my first question was already answered PS. Thanks alot for your help so far, really appreciated. Regards Mark I am. Therefore, I think. I think. On Wed, 23 Jul 2003, Trevor Talbot wrote: On Wednesday, Jul 23, 2003, at 03:36 US/Pacific, Mark Bojara wrote: I understand what you mean but this is only for a outgoing connection with keepstated incoming. If another completely different incoming connection gets established then since it did not orignate as a outgoing connection the keep state will not apply. I don't follow. If all of your rules specify queues, then the queues will apply. Is there a case where you don't want to specify queues that I missed? On Wed, 23 Jul 2003, Trevor Talbot wrote: On Tuesday, Jul 22, 2003, at 23:46 US/Pacific, Mark Bojara wrote: Thanks for the advice, Ive tried to have one rule to catch both directions but if it is outgoing traffic then the keepstate will automatically allocate the incoming packets that are comming back to the same queue. But if the request originated from a incoming request there is no way possible that the same outgoing queue will work for that traffic. Anyway, the tagging in the state entry happens no matter which direction the packet is traveling. Thus, when you create a state on an inbound packet, the queue tag will only matter for reply packets (going back out on that interface). The inbound packets will still be tagged, but the tags don't match any queue on the interface they go out on, so nothing happens. Meanwhile, you also have a rule to create state out on that other interface, and that queue tag does apply. You should keep the one-rule-per-interface setup, i.e. pass in on $i01, pass out on $i03. You should also set each rule to use the appropriate queue on that same interface, no matter which direction the rule is for.
Re: incoming outgoing queue on single interface/queue
Hello Trevor, Basically why I want them to have the same name is because there are multiple interfaces on this server were clients are connected too, So if I want borrowing (HFSC) to work overall for everybody it has to be assigned under a single parent. Regards Mark On Wed, 23 Jul 2003, Trevor Talbot wrote: On Wednesday, Jul 23, 2003, at 10:21 US/Pacific, Mark Bojara wrote: I was wondering if its possible to either set up one queue on a single interface to do both incoming and outgoing traffic? No, not at present. Or maybe possibly having it on split interface's but assigned to one queue. eg: pass out on dc1 from za to 196.34.165.210 keep state queue opium_01_l pass in on fxp0 from za to 196.34.165.210 keep state queue opium_01_l A queue must be tied to an interface; it can't be floating for use with any flow. One thing you can do is specify queues with the same name on different interfaces (this ties in with the IN tagging I mentioned in the last thread), but this probably isn't what you're after.
stateful filters affect queue filters
Hello All,
I am running OpenBSD 3.3-current with HFSC queueing and stateful filters.
If I enable my stateful filters anything defined via those filters does
not go through my queue filters and gets unlimited bandwidth.
Below is my pf.conf file, When I access 196.34.165.210 via ftp my
bandwidth is limited but as soon as I access it via port 80 I have
unlimited bandwidth.
Have a great day
Mark
# Interface Variables
i01=fxp0 # uplink
i02=dc0 # hosting
i03=dc1 # access00
i04=dc2 # shell
#
localbw=512Kb
internationalbw=192Kb
icmp={ !196.34.165.210 }
table mics { 196.34.165.0/24, 196.23.168.0/24 }
table za file /usr/local/etc/zaip
set timeout { interval 30, frag 10 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, other.multiple 60 }
set limit { states 10, frags 15000 }
set loginterface none
set optimization normal
set block-policy drop
set require-order yes
scrub in on fxp0 all random-id no-df fragment reassemble
### ALTQ
Uplink Interface - Peering
altq on $i01 bandwidth 10Mb hfsc queue { std_01, lan_01, local_01 }
queue std_01 bandwidth 32Kb hfsc(default upperlimit 512Kb) # change this
queue lan_01 bandwidth 2Mb
# Uplink - Local Bandwidth
queue local_01 bandwidth $localbw hfsc(upperlimit $localbw) { ssh_01, opium_01_l,
jobsd_01_l }
queue ssh_01 bandwidth 16Kb hfsc(realtime 16Kb)
queue opium_01_l bandwidth 128Kb hfsc(upperlimit 32Kb)
queue jobsd_01_l bandwidth 128Kb hfsc(realtime 128Kb)
# Uplink - International Bandwidth
#queue intl_01 bandwidth $internationalbw hfsc(upperlimit $internationalbw) \
# { opium_01_i, \
# jobsd_01_i }
# queue opium_01_i bandwidth 64Kb hfsc(realtime 64Kb)
# queue jobsd_01_i bandwidth 64Kb hfsc(realtime 16Kb)
Hosting Interface
altq on $i02 bandwidth 100Mb hfsc queue { std_02, lan_02, local_02, intl_02 }
queue std_02 bandwidth 32Kb hfsc(default upperlimit 512Kb) # change this
queue lan_02 bandwidth 2Mb
# Hosting - Local Bandwidth
queue local_02 bandwidth $localbw hfsc(upperlimit $localbw) \
{ ssh_02, \
joxp_02_l, \
jobsd_02_l }
queue ssh_02 bandwidth 16Kb hfsc(realtime 16Kb)
queue joxp_02_l bandwidth 128Kb hfsc(realtime 128Kb)
queue jobsd_02_l bandwidth 128Kb hfsc(realtime 128Kb)
# Hosting - International Bandwidth
queue intl_02 bandwidth $internationalbw hfsc(upperlimit $internationalbw) \
{ joxp_02_i, \
jobsd_02_i }
queue joxp_02_i bandwidth 64Kb hfsc(realtime 64Kb)
queue jobsd_02_i bandwidth 64Kb hfsc(realtime 64Kb)
Access00 Interface
altq on $i03 bandwidth 10Mb hfsc queue { std_03, lan_03, local_03, intl_03 }
queue std_03 bandwidth 32Kb hfsc(default upperlimit 512Kb) # change this
queue lan_03 bandwidth 2Mb
# Access00 - Local Bandwidth
queue local_03 bandwidth $localbw hfsc(upperlimit $localbw) \
{ ssh_03, \
opium_03_l, \
jobsd_03_l }
queue ssh_03 bandwidth 16Kb hfsc(realtime 16Kb)
queue opium_03_l bandwidth 128Kb hfsc(upperlimit 32Kb)
queue jobsd_03_l bandwidth 128Kb hfsc(realtime 128Kb)
# Access00 - International Bandwidth
queue intl_03 bandwidth $internationalbw hfsc(upperlimit $internationalbw) \
{ opium_03_i, \
jobsd_03_i }
queue opium_03_i bandwidth 64Kb hfsc(realtime 16Kb)
queue jobsd_03_i bandwidth 64Kb hfsc(realtime 64Kb)
#
### /ALTQ
#rdr on dc1 proto tcp from any to any port 31337 - 196.23.168.2 port 23
#block in on fxp0 from no-route to any
## ALTQ/Host firewall definers
# unlimited lan
pass out quick on $i01 from mics to mics keep state queue lan_01
pass out quick on $i02 from mics to mics keep state queue lan_02
pass out quick on $i03 from mics to mics keep state queue lan_03
# priority definers
pass out quick on $i01 proto { tcp, udp } from any to any port 22 keep state queue
ssh_01
pass out quick on $i01 proto { tcp, udp } from any port 22 to any keep state queue
ssh_01
pass out quick on $i02 proto { tcp, udp } from any port 22 to any keep state queue
ssh_02
pass out quick on $i02 proto { tcp, udp } from any to any port 22 keep state queue
ssh_02
pass out quick on $i03 proto { tcp, udp } from any port 22 to any keep state queue
ssh_03
pass out quick on $i03 proto { tcp, udp } from any to any port 22 keep state queue
ssh_03
#
pass out on $i01 from 196.34.165.210 to any keep state queue opium_01_i
pass out on $i03 from any
