From holbs at real-life.tm Fri May 2 02:25:12 2008 From: holbs at real-life.tm (Drav Sloan) Date: Fri May 2 02:25:20 2008 Subject: a buildworld yeilds tcpdump oddness Message-ID: <20080502020537.GA70377@real-life.tm> Hiya all! I'm fairly new to pf and have recently set up a firewall using it. After getting things up and running I decided to cvsup and buildworld 7.0-RELEASE branch. However odd things started appaearing with the output of tcpdump when the old 'tcpdump -n -e -ttt -i pflog0" is used. Instead of the usual output I now get: tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 68 bytes 000000 rule 6/0(match): block in on re0: [|ip] 000058 rule 6/0(match): block in on re0: [|ip] 300. 033021 rule 6/0(match): block in on re0: [|ip] 000056 rule 6/0(match): block in on re0: [|ip] 368. 212637 rule 6/0(match): block in on re0: [|ip] 000059 rule 6/0(match): block in on re0: [|ip] As you can see the actual traffic being blocked is not "present", so it's about as much use as Boris in a mayorial election (as I've no idea _what_ is being blocked). Has anyone come across this before? Have I done something dumb with my configs that have nuked the pflog0 output? Any ideas how I can kick this up the arse? _Strangely_ a tcpdump of the /var/log/pflog yeilds the expected behaviour: # tcpdump -n -e -ttt -r /var/log/pflog reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file) . . 368. 212637 rule 6/0(match): block in on re0: 10.0.0.1.138 > 10.0.0.255.138: NBT UDP PACKET(138) 000059 rule 6/0(match): block in on re0: 10.0.0.1.138 > 10.0.0.255.138: NBT UDP PACKET(138) I'm stumped :/ Cheers in advanced for any cl00 offered :D Regards Drav. From holborn-pf at real-life.tm Fri May 2 02:25:13 2008 From: holborn-pf at real-life.tm (Drav Sloan) Date: Fri May 2 02:25:20 2008 Subject: buildworld has resulted in tcpdump oddness Message-ID: <20080502020704.GB70377@real-life.tm> Hiya all! I'm fairly new to pf and have recently set up a firewall using it. After getting things up and running I decided to cvsup and buildworld 7.0-RELEASE branch. However odd things started appaearing with the output of tcpdump when the old 'tcpdump -n -e -ttt -i pflog0" is used. Instead of the usual output I now get: tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 68 bytes 000000 rule 6/0(match): block in on re0: [|ip] 000058 rule 6/0(match): block in on re0: [|ip] 300. 033021 rule 6/0(match): block in on re0: [|ip] 000056 rule 6/0(match): block in on re0: [|ip] 368. 212637 rule 6/0(match): block in on re0: [|ip] 000059 rule 6/0(match): block in on re0: [|ip] As you can see the actual traffic being blocked is not "present", so it's about as much use as Boris in a mayorial election (as I've no idea _what_ is being blocked). Has anyone come across this before? Have I done something dumb with my configs that have nuked the pflog0 output? Any ideas how I can kick this up the arse? _Strangely_ a tcpdump of the /var/log/pflog yeilds the expected behaviour: # tcpdump -n -e -ttt -r /var/log/pflog reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file) . . 368. 212637 rule 6/0(match): block in on re0: 10.0.0.1.138 > 10.0.0.255.138: NBT UDP PACKET(138) 000059 rule 6/0(match): block in on re0: 10.0.0.1.138 > 10.0.0.255.138: NBT UDP PACKET(138) I'm stumped :/ Cheers in advanced for any cl00 offered :D Regards Drav. From fox at verio.net Fri May 2 02:32:34 2008 From: fox at verio.net (David DeSimone) Date: Fri May 2 02:32:39 2008 Subject: a buildworld yeilds tcpdump oddness In-Reply-To: <20080502020537.GA70377@real-life.tm> References: <20080502020537.GA70377@real-life.tm> Message-ID: <20080502023222.GC25833@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Drav Sloan wrote: > > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 68 bytes > 000000 rule 6/0(match): block in on re0: [|ip] > 000058 rule 6/0(match): block in on re0: [|ip] When you see the [|xxx] syntax in tcpdump, that is its way of telling you that the packet you captured is truncated, and it cannot show you more information unless you capture a longer packet. With recent changes to PF, the default capture size (68 bytes as seen above) is insufficient. Try adding "-s128" to capture more of the packets and you should see an improvement. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIGn02FSrKRjX5eCoRApFtAJ93pVFCdW2QJx2IDX3AXVZ6M4ZowQCeMQxQ PkQ0MEWSRSbRh8W2HSHXVXI= =XsE3 -----END PGP SIGNATURE----- From holborn-pf at real-life.tm Fri May 2 02:45:16 2008 From: holborn-pf at real-life.tm (Drav Sloan) Date: Fri May 2 02:45:23 2008 Subject: a buildworld yeilds tcpdump oddness In-Reply-To: <20080502023222.GC25833@verio.net> References: <20080502020537.GA70377@real-life.tm> <20080502023222.GC25833@verio.net> Message-ID: <20080502024515.GC70377@real-life.tm> David DeSimone wrote: > When you see the [|xxx] syntax in tcpdump, that is its way of telling > you that the packet you captured is truncated, and it cannot show you > more information unless you capture a longer packet. > > With recent changes to PF, the default capture size (68 bytes as seen > above) is insufficient. Try adding "-s128" to capture more of the > packets and you should see an improvement. Et volia! Been using tcpdump for years, never knew about that one! Cheers Dave, (and appologies for multiple post, I thought the first one would of been rejected given it's return address...) Regards Drav. From vwe at FreeBSD.org Fri May 2 10:20:25 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Fri May 2 10:20:27 2008 Subject: kern/119661: [pf] "queue (someq, empy_acks)" doesn't work Message-ID: <200805021020.m42AKOxn057419@freefall.freebsd.org> Synopsis: [pf] "queue (someq, empy_acks)" doesn't work State-Changed-From-To: feedback->open State-Changed-By: vwe State-Changed-When: Fri May 2 10:20:09 UTC 2008 State-Changed-Why: Feedback has been provided. http://www.freebsd.org/cgi/query-pr.cgi?pr=119661 From mlaier at FreeBSD.org Fri May 2 12:16:25 2008 From: mlaier at FreeBSD.org (mlaier@FreeBSD.org) Date: Fri May 2 12:16:26 2008 Subject: kern/119661: [pf] "queue (someq, empy_acks)" doesn't work Message-ID: <200805021216.m42CGOxV068852@freefall.freebsd.org> Synopsis: [pf] "queue (someq, empy_acks)" doesn't work State-Changed-From-To: open->closed State-Changed-By: mlaier State-Changed-When: Fri May 2 12:15:18 UTC 2008 State-Changed-Why: Sorry, but PRs are not a free "debug my ruleset"-service. There is no bug here! http://www.freebsd.org/cgi/query-pr.cgi?pr=119661 From max at love2party.net Fri May 2 12:20:07 2008 From: max at love2party.net (Max Laier) Date: Fri May 2 12:20:12 2008 Subject: kern/119661: [pf] "queue (someq, empy_acks)" doesn't work Message-ID: <200805021220.m42CK62s068973@freefall.freebsd.org> The following reply was made to PR kern/119661; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, ino-news@spotteswoode.dnsalias.org Cc: Subject: Re: kern/119661: [pf] "queue (someq, empy_acks)" doesn't work Date: Fri, 2 May 2008 14:10:37 +0200 Sorry, still works for me: %echo 'pass out log (all) proto tcp from any to any flags S/SA modulate state label "27: outbound tcp keep state" queue(interactive, tcp_ack)' | pfctl -vvvf- Loaded 696 passive OS fingerprints @0 pass out log (all) proto tcp all flags S/SA modulate state label "27: outbound tcp keep state" queue(interactive, tcp_ack) %pfctl -vvsr @0 pass out log (all) proto tcp all flags S/SA modulate state label "27: outbound tcp keep state" queue(interactive, tcp_ack) [ Evaluations: 45 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1602 ] -- Max From bugmaster at FreeBSD.org Mon May 5 11:07:10 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 5 11:07:22 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200805051107.m45B79NL070792@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/116610 pf [patch] teach tcpdump(1) to cope with the new-style pf o kern/120281 pf [request] lost returning packets to PF for a rdr rule o kern/122014 pf [panic] FreeBSD 6.2 panic in pf 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf tagged parameter on nat not working on FreeBSD 5.2 o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c f kern/116645 pf [request] pfctl -k does not work in securelevel 3 o kern/118355 pf [pf] [patch] pfctl help message options order false -t o kern/120057 pf [patch] Allow proper settings of ALTQ_HFSC. The check o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to 10 problems total. From artemrts at ukr.net Tue May 6 10:03:45 2008 From: artemrts at ukr.net (Vitaliy Vladimirovich) Date: Tue May 6 10:03:49 2008 Subject: dst_addr and subdomains Message-ID: ? ?????????? Hi! ?How can I specify dst_addr in my rule for all subdomains of server. E.g. example1.server.com, example2.server.com and so on. Something like this: pass out on sk0 inet proto tcp from $MY_LAN to *.example.org port www From koitsu at freebsd.org Tue May 6 10:06:59 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Tue May 6 10:07:01 2008 Subject: dst_addr and subdomains In-Reply-To: References: Message-ID: <20080506100658.GA3813@eos.sc1.parodius.com> On Tue, May 06, 2008 at 12:47:24PM +0300, Vitaliy Vladimirovich wrote: > Hi! > ow can I specify dst_addr in my rule for all subdomains of server. E.g. example1.server.com, example2.server.com and so on. > > Something like this: > > pass out on sk0 inet proto tcp from $MY_LAN to *.example.org port www What you want is basically a layer 7 filter -- pf does not do that. If all the machines within *.example.org are within a specific network block (e.g. 20.30.40.0/24), then you can use that CIDR netblock instead of *.example.org in your above example. But you cannot use wildcards for domains. All hostnames given as a dst/src address will be resolved first. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ansarm at gmail.com Tue May 6 23:39:07 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Tue May 6 23:39:11 2008 Subject: DCE-RPC Message-ID: <03b201c8afce$e0325d60$a0971820$@com> Hello All, Does pf have any higher level application inspection capability such as RPC filtering based on UUID? From Greg.Hennessy at nviz.net Wed May 7 07:39:32 2008 From: Greg.Hennessy at nviz.net (Greg Hennessy) Date: Wed May 7 07:39:37 2008 Subject: DCE-RPC In-Reply-To: <03b201c8afce$e0325d60$a0971820$@com> References: <03b201c8afce$e0325d60$a0971820$@com> Message-ID: <48215CB4.7060907@nviz.net> Ansar Mohammed wrote: > Hello All, > > Does pf have any higher level application inspection capability such as RPC > filtering based on UUID? > No, that is layer 7 style 'deep packet inspection' (tm) voodoo. Greg From ansarm at gmail.com Wed May 7 17:34:03 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Wed May 7 17:34:08 2008 Subject: UDP weirdness Message-ID: <004f01c8b068$89c89350$9d59b9f0$@com> I have a very simple configuration yet I am bemused as to what I am doing wrong. Windows 2003 <- FreeBSD-PF -> Windows 2003 192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130 Here are my rules ext_if="le0" int_if="le1" int_net="192.168.3.0/24" ext_net="192.168.2.0/24" int_addr="192.168.3.1" ext_addr="192.168.2.2" scrub on $ext_if all reassemble tcp scrub on $int_if all reassemble tcp block in log all pass in proto icmp from any to any pass in proto udp from any to any port 53 pass in on $ext_if inet proto tcp from any to any port 3389 DNS traffic is allowed though but the return packet gets blocked. Can anyone explain why? This is true on ALL UDP traffic TCP traffic works well Pflog message: 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 > 192.168.2.130.3837: [|domain] From kkutzko at teksavvy.com Wed May 7 17:55:24 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed May 7 17:55:28 2008 Subject: UDP weirdness In-Reply-To: <004f01c8b068$89c89350$9d59b9f0$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> Message-ID: <005101c8b06b$5f0743c0$1d15cb40$@com> Try pass out proto udp from any to any port 53 > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- > pf@freebsd.org] On Behalf Of Ansar Mohammed > Sent: Wednesday, May 07, 2008 1:34 PM > To: freebsd-pf@freebsd.org > Subject: UDP weirdness > > I have a very simple configuration yet I am bemused as to what I am > doing > wrong. > > > Windows 2003 <- FreeBSD-PF -> Windows 2003 > 192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130 > Here are my rules > > > ext_if="le0" > int_if="le1" > int_net="192.168.3.0/24" > ext_net="192.168.2.0/24" > int_addr="192.168.3.1" > ext_addr="192.168.2.2" > scrub on $ext_if all reassemble tcp > scrub on $int_if all reassemble tcp > block in log all > pass in proto icmp from any to any > pass in proto udp from any to any port 53 > pass in on $ext_if inet proto tcp from any to any port 3389 > > > DNS traffic is allowed though but the return packet gets blocked. Can > anyone > explain why? > This is true on ALL UDP traffic TCP traffic works well > > Pflog message: > > 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 > > 192.168.2.130.3837: [|domain] > > > > > _______________________________________________ > 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 ansarm at gmail.com Wed May 7 20:34:44 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Wed May 7 20:34:48 2008 Subject: UDP weirdness In-Reply-To: <005101c8b06b$5f0743c0$1d15cb40$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> Message-ID: <008b01c8b081$c74692e0$55d3b8a0$@com> Ok, so adding the line as you suggested worked. Thanks Kevin. But why do I need to have both entries in for pass in proto udp from any to any port 53 pass out proto udp from any to any port 53 what makes UDP so special? > -----Original Message----- > From: Kevin K [mailto:kkutzko@teksavvy.com] > Sent: May 7, 2008 1:54 PM > To: 'Ansar Mohammed'; freebsd-pf@freebsd.org > Subject: RE: UDP weirdness > > Try pass out proto udp from any to any port 53 > > > -----Original Message----- > > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- > > pf@freebsd.org] On Behalf Of Ansar Mohammed > > Sent: Wednesday, May 07, 2008 1:34 PM > > To: freebsd-pf@freebsd.org > > Subject: UDP weirdness > > > > I have a very simple configuration yet I am bemused as to what I am > > doing > > wrong. > > > > > > Windows 2003 <- FreeBSD-PF -> Windows 2003 > > 192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130 > > Here are my rules > > > > > > ext_if="le0" > > int_if="le1" > > int_net="192.168.3.0/24" > > ext_net="192.168.2.0/24" > > int_addr="192.168.3.1" > > ext_addr="192.168.2.2" > > scrub on $ext_if all reassemble tcp > > scrub on $int_if all reassemble tcp > > block in log all > > pass in proto icmp from any to any > > pass in proto udp from any to any port 53 > > pass in on $ext_if inet proto tcp from any to any port 3389 > > > > > > DNS traffic is allowed though but the return packet gets blocked. Can > > anyone > > explain why? > > This is true on ALL UDP traffic TCP traffic works well > > > > Pflog message: > > > > 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 > > > 192.168.2.130.3837: [|domain] > > > > > > > > > > _______________________________________________ > > 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 jille at quis.cx Wed May 7 20:50:13 2008 From: jille at quis.cx (Jille) Date: Wed May 7 20:50:17 2008 Subject: UDP weirdness In-Reply-To: <008b01c8b081$c74692e0$55d3b8a0$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> Message-ID: <482215F4.1080806@quis.cx> Ansar Mohammed schreef: > Ok, so adding the line as you suggested worked. > Thanks Kevin. > > But why do I need to have both entries in for > > pass in proto udp from any to any port 53 > pass out proto udp from any to any port 53 > > what makes UDP so special? UDP is stateless, With TCP you've got an connection (identified by: local host:port and remote host:port) With UDP, well, you just trow the packages over the line, and hope the is (still) someone on the other end. So the is (almost) no way to detect whether packets are responses to eachother -- Jille From ansarm at gmail.com Wed May 7 20:54:26 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Wed May 7 20:54:30 2008 Subject: UDP weirdness In-Reply-To: <482215F4.1080806@quis.cx> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> Message-ID: <00a401c8b084$87da9540$978fbfc0$@com> But I thought pf would be tracking state? Isnt that the whole point of statefull firewalls? > -----Original Message----- > From: Jille [mailto:jille@quis.cx] > Sent: May 7, 2008 4:50 PM > To: Ansar Mohammed > Cc: 'Kevin K'; freebsd-pf@freebsd.org > Subject: Re: UDP weirdness > > > > Ansar Mohammed schreef: > > Ok, so adding the line as you suggested worked. > > Thanks Kevin. > > > > But why do I need to have both entries in for > > > > pass in proto udp from any to any port 53 > > pass out proto udp from any to any port 53 > > > > what makes UDP so special? > UDP is stateless, > With TCP you've got an connection (identified by: local host:port and > remote host:port) > With UDP, well, you just trow the packages over the line, and hope the > is (still) someone on the other end. > > So the is (almost) no way to detect whether packets are responses to > eachother > > -- Jille From kkutzko at teksavvy.com Wed May 7 20:56:58 2008 From: kkutzko at teksavvy.com (Kevin K) Date: Wed May 7 20:57:02 2008 Subject: UDP weirdness In-Reply-To: <00a401c8b084$87da9540$978fbfc0$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> <00a401c8b084$87da9540$978fbfc0$@com> Message-ID: <006c01c8b084$e1d82670$a5887350$@com> You cannot track state of stateless protocols such as UDP. > -----Original Message----- > From: Ansar Mohammed [mailto:ansarm@gmail.com] > Sent: Wednesday, May 07, 2008 4:54 PM > To: 'Jille' > Cc: 'Kevin K'; freebsd-pf@freebsd.org > Subject: RE: UDP weirdness > > But I thought pf would be tracking state? > Isnt that the whole point of statefull firewalls? > > > > > -----Original Message----- > > From: Jille [mailto:jille@quis.cx] > > Sent: May 7, 2008 4:50 PM > > To: Ansar Mohammed > > Cc: 'Kevin K'; freebsd-pf@freebsd.org > > Subject: Re: UDP weirdness > > > > > > > > Ansar Mohammed schreef: > > > Ok, so adding the line as you suggested worked. > > > Thanks Kevin. > > > > > > But why do I need to have both entries in for > > > > > > pass in proto udp from any to any port 53 > > > pass out proto udp from any to any port 53 > > > > > > what makes UDP so special? > > UDP is stateless, > > With TCP you've got an connection (identified by: local host:port and > > remote host:port) > > With UDP, well, you just trow the packages over the line, and hope > the > > is (still) someone on the other end. > > > > So the is (almost) no way to detect whether packets are responses to > > eachother > > > > -- Jille From valentin.bud at gmail.com Wed May 7 21:01:28 2008 From: valentin.bud at gmail.com (Valentin Bud) Date: Wed May 7 21:01:58 2008 Subject: UDP weirdness In-Reply-To: <006c01c8b084$e1d82670$a5887350$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> <00a401c8b084$87da9540$978fbfc0$@com> <006c01c8b084$e1d82670$a5887350$@com> Message-ID: <139b44430805071401h664fe840r541afa063b7fe0ca@mail.gmail.com> from pf faq --- http://www.openbsd.org/faq/pf/filter.html#pass quote: " One will sometimes hear it said that, "One can not create state with UDP as UDP is a stateless protocol!" While it is true that a UDP communication session does not have any concept of state (an explicit start and stop of communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the optionssection of the pf.conf file." On Wed, May 7, 2008 at 11:56 PM, Kevin K wrote: > You cannot track state of stateless protocols such as UDP. > > > > > -----Original Message----- > > From: Ansar Mohammed [mailto:ansarm@gmail.com] > > Sent: Wednesday, May 07, 2008 4:54 PM > > To: 'Jille' > > Cc: 'Kevin K'; freebsd-pf@freebsd.org > > Subject: RE: UDP weirdness > > > > But I thought pf would be tracking state? > > Isnt that the whole point of statefull firewalls? > > > > > > > > > -----Original Message----- > > > From: Jille [mailto:jille@quis.cx] > > > Sent: May 7, 2008 4:50 PM > > > To: Ansar Mohammed > > > Cc: 'Kevin K'; freebsd-pf@freebsd.org > > > Subject: Re: UDP weirdness > > > > > > > > > > > > Ansar Mohammed schreef: > > > > Ok, so adding the line as you suggested worked. > > > > Thanks Kevin. > > > > > > > > But why do I need to have both entries in for > > > > > > > > pass in proto udp from any to any port 53 > > > > pass out proto udp from any to any port 53 > > > > > > > > what makes UDP so special? > > > UDP is stateless, > > > With TCP you've got an connection (identified by: local host:port and > > > remote host:port) > > > With UDP, well, you just trow the packages over the line, and hope > > the > > > is (still) someone on the other end. > > > > > > So the is (almost) no way to detect whether packets are responses to > > > eachother > > > > > > -- Jille > > _______________________________________________ > 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" > -- Kind Regards, Valentin Bud www.syk.ro www.spreadbsd.org/aff/86/1 www.spreadbsd.org/aff/86/2 valentin [dot] bud [at] gmail [dot] com valentin [dot] bud [at] dep [dot] upt [dot] ro From valentin.bud at gmail.com Wed May 7 21:14:14 2008 From: valentin.bud at gmail.com (Valentin Bud) Date: Wed May 7 21:14:19 2008 Subject: proftpd and pf weirdness Message-ID: <139b44430805071348x4b20f4b0oe281eaf61380f046@mail.gmail.com> Hello to you all, Last week i've begun to have problem with an HUAWEI E220 HSDPA modem when connecting to proftpd server. First thing i want to mention is that the thing that i'll describe here only happens when i connect from that modem. First of all the topology of the servers: ISP----[bridged modem]-----[FreeBSD mpd4+pf]----[FreeBSD proftpd] the pf rules that redirect traffic to proftpd: rdr pass on $EXT_IF proto tcp from any to $EXT_IF port 21 -> port 21 rdr pass on $EXT_IF proto tcp from any to $EXT_IF port 59000:59100 -> port 59000:59100 DMZ_HOST (192.168.1.2) being the FreeBSD 6.2-RELEASEp6 box that runs - ProFTPD Version 1.3.1 no firewall running on DMZ_HOST here is the relevant ouput that the server gives when the ftp session is closed: 12.34.56.78 (213.233.102.254[213.233.102.254]) - Entering Passive Mode (192,168,1,2,230,167). 12.34.56.78 (213.233.102.254[213.233.102.254]) - dispatching POST_CMD command 'PASV' to mod_sql 12.34.56.78 (213.233.102.254[213.233.102.254]) - dispatching LOG_CMD command 'PASV' to mod_sql 12.34.56.78 (213.233.102.254[213.233.102.254]) - dispatching LOG_CMD command 'PASV' to mod_log 12.34.56.78 (213.233.102.254[213.233.102.254]) - FTP session closed. tcpdump output from the [mpd4+pf] box: 14:04:58.299572 AF IPv4 (2), length 94: 12.34.56.78.21 > 213.233.102.254.40437: P 261:311(50) ack 92 win 65535 0x0000: 4500 005a be9c 4000 3f06 0f55 597a d74a E..Z..@.?..UYz.J 0x0010: d5e9 66fe 0015 9df5 2ded 1879 01dc 346b ..f.....-..y..4k 0x0020: 5018 ffff aea7 0000 3232 3720 456e 7465 P.......227.Ente 0x0030: 7269 6e67 2050 6173 7369 7665 204d 6f64 ring.Passive.Mod 0x0040: 6520 2831 3932 2c31 3638 2c31 2c32 2c32 e.(192,168,1,2,2 0x0050: 3330 2c31 3637 292e 0d0a 30,167)... 14:04:58.348823 AF IPv4 (2), length 94: 213.233.102.254.40437 > 12.34.56.78.21: R 92:142(50) ack 261 win 65535 0x0000: 4500 005a be9c 4000 2806 2655 d5e9 66fe E..Z..@.(.&U..f. 0x0010: 597a d74a 9df5 0015 01dc 346b 2ded 1879 Yz.J......4k-..y 0x0020: 5014 ffff aeab 0000 3232 3720 456e 7465 P.......227.Ente 0x0030: 7269 6e67 2050 6173 7369 7665 204d 6f64 ring.Passive.Mod 0x0040: 6520 2831 3932 2c31 3638 2c31 2c32 2c32 e.(192,168,1,2,2 0x0050: 3330 2c31 3637 292e 0d0a 30,167)... The last snippet from tcpdump shows (as far as i know) that the huawei modem sends an R and that the server (before) that reset sends the PASV port answer. If i am not right please correct me. The ppp connection made from the modem receives an ip from 172.16/12 private class which gets nat-ed to the 213.* ip from the logs. If it matters the modem is from Vodafone. I will attach the proftpd config file. I think that vodafone does some check on packets and it doesn't like that the connection to the ftp server passes through the [mpd4+pf] box. Configuring proftpd on the [mpd4+pf] box works like a charm. This is a viable solution but i want to find out what happens. Any hints to dig further are more than welcomed. Thank you. PS: the 12.34.56.78 ip is bogus to protect my server's identity, everything else is copy paste from server output. -- Kind Regards, Valentin Bud www.syk.ro www.spreadbsd.org/aff/86/1 www.spreadbsd.org/aff/86/2 valentin [dot] bud [at] gmail [dot] com valentin [dot] bud [at] dep [dot] upt [dot] ro From koitsu at freebsd.org Wed May 7 21:43:52 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Wed May 7 21:43:58 2008 Subject: UDP weirdness In-Reply-To: <00a401c8b084$87da9540$978fbfc0$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> <00a401c8b084$87da9540$978fbfc0$@com> Message-ID: <20080507214351.GA74641@eos.sc1.parodius.com> On Wed, May 07, 2008 at 04:54:22PM -0400, Ansar Mohammed wrote: > But I thought pf would be tracking state? > Isnt that the whole point of statefull firewalls? UDP is stateless, however pf still tracks the "state" in the sense that it knows when there's an outbound or inbound initial packet for UDP, thus creates a "state" for it. It can do the same with ICMP. I believe the teardown/state removal is based on a timeout (of when it last sees packets matching that src/dst IP and port). Keep in mind that if you're using RELENG_6, you'll need "keep state" on those pass in/pass out rules you used. If you're using RELENG_7, "keep state" is implicit, so you won't need to specify it in your config. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From oleksandr at samoylyk.sumy.ua Wed May 7 22:02:26 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed May 7 22:02:29 2008 Subject: iptables rule in pf Message-ID: <482226E5.4090802@samoylyk.sumy.ua> Dear Community, I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. After reading man pf.conf for a couple of minutes I couldn't find the realization of such iptables rule in pf: iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport 25 -j DROP iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT --to-destination :25 How it can be rewriting in pf.conf? Thanks! -- Oleksandr Samoylyk OVS-RIPE From oleksandr at samoylyk.sumy.ua Wed May 7 22:05:07 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed May 7 22:05:12 2008 Subject: iptables rule in pf Message-ID: <48222786.3050400@samoylyk.sumy.ua> Dear Community, I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. After reading man pf.conf for a couple of minutes I couldn't find the realization of such iptables rule in pf: iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport 25 -j DROP iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT --to-destination :25 How it can be rewriting in pf.conf? Thanks! -- Oleksandr Samoylyk OVS-RIPE From ansarm at gmail.com Wed May 7 22:06:43 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Wed May 7 22:06:47 2008 Subject: UDP weirdness In-Reply-To: <20080507214351.GA74641@eos.sc1.parodius.com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> <00a401c8b084$87da9540$978fbfc0$@com> <20080507214351.GA74641@eos.sc1.parodius.com> Message-ID: <00bc01c8b08e$a080cf60$e1826e20$@com> So I am using FreeBSD 7 and it doesn't work either way with "keep state" there or not. The only catch here is that everything is running on VMWare, although that should not matter. I have been using pf for about 2 years now. I feel this may be a bit of a bug. I even set the state-policy to floating (which I believe is default) and still I need the second rule. > -----Original Message----- > From: Jeremy Chadwick [mailto:koitsu@freebsd.org] > Sent: May 7, 2008 5:44 PM > To: Ansar Mohammed > Cc: 'Jille'; freebsd-pf@freebsd.org > Subject: Re: UDP weirdness > > On Wed, May 07, 2008 at 04:54:22PM -0400, Ansar Mohammed wrote: > > But I thought pf would be tracking state? > > Isnt that the whole point of statefull firewalls? > > UDP is stateless, however pf still tracks the "state" in the sense that > it knows when there's an outbound or inbound initial packet for UDP, > thus creates a "state" for it. It can do the same with ICMP. I > believe > the teardown/state removal is based on a timeout (of when it last sees > packets matching that src/dst IP and port). > > Keep in mind that if you're using RELENG_6, you'll need "keep state" on > those pass in/pass out rules you used. If you're using RELENG_7, "keep > state" is implicit, so you won't need to specify it in your config. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | From max at love2party.net Wed May 7 22:20:02 2008 From: max at love2party.net (Max Laier) Date: Wed May 7 22:20:05 2008 Subject: UDP weirdness In-Reply-To: <004f01c8b068$89c89350$9d59b9f0$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> Message-ID: <200805080015.27191.max@love2party.net> On Wednesday 07 May 2008 19:34:00 Ansar Mohammed wrote: > I have a very simple configuration yet I am bemused as to what I am > doing wrong. > > > Windows 2003 <- FreeBSD-PF -> Windows 2003 > 192.168.3.2 192.168.3.1 192.168.2.2 192.168.2.130 > Here are my rules > > > ext_if="le0" > int_if="le1" > int_net="192.168.3.0/24" > ext_net="192.168.2.0/24" > int_addr="192.168.3.1" > ext_addr="192.168.2.2" > scrub on $ext_if all reassemble tcp > scrub on $int_if all reassemble tcp > block in log all > pass in proto icmp from any to any > pass in proto udp from any to any port 53 > pass in on $ext_if inet proto tcp from any to any port 3389 > > > DNS traffic is allowed though but the return packet gets blocked. Can > anyone explain why? > This is true on ALL UDP traffic TCP traffic works well > > Pflog message: > > 065276 rule 0/0(match): block in on le1: 192.168.3.2.53 > > 192.168.2.130.3837: [|domain] Here is what happend: 1) You sent a DNS request from 192.168.2.130:3837 to 192.168.3.2:53 this passes on le0 (which I assume is the interface on 192.168.2.0/24) because of the "pass in ... to any port 53" (because the packet is indeed destined to any port 53). This creates a state: le0 IN 192.168.2.130:3837->192.168.3.2:53 2) You forward the packet and it leaves le1 in out direction. This passes because you don't block outgoing packets at all. It doesn't create state either. 3) The server replies from 192.168.3.2:53 to 192.168.2.130:3837 this is blocked on le1 because there is no rule to allow it and the state created above does *NOT* match! Why doesn't it match the state? A state "le0 IN 192.168.2.130:3837->192.168.3.2:53" will match: IN 192.168.2.130:3837->192.168.3.2:53 and OUT 192.168.3.2:53->192.168.2.130:3837 but not IN 192.168.3.2:53->192.168.2.130:3837 if state-policy is set to floating, the interface doesn't matter, but the direction does! This is a FAQ! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From koitsu at freebsd.org Wed May 7 22:44:09 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Wed May 7 22:44:13 2008 Subject: UDP weirdness In-Reply-To: <00bc01c8b08e$a080cf60$e1826e20$@com> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> <00a401c8b084$87da9540$978fbfc0$@com> <20080507214351.GA74641@eos.sc1.parodius.com> <00bc01c8b08e$a080cf60$e1826e20$@com> Message-ID: <20080507224409.GA77067@eos.sc1.parodius.com> On Wed, May 07, 2008 at 06:06:38PM -0400, Ansar Mohammed wrote: > So I am using FreeBSD 7 and it doesn't work either way with "keep state" > there or not. The only catch here is that everything is running on VMWare, > although that should not matter. I have been using pf for about 2 years now. > I feel this may be a bit of a bug. > > I even set the state-policy to floating (which I believe is default) and > still I need the second rule. You don't need "keep state" or "keep state flags S/SA" on any of your rules because you're using RELENG_7. Regarding the need for the "pass out" line, Max has explained the reason/need for it in another Email. It's not a bug. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jon at radel.com Thu May 8 00:43:20 2008 From: jon at radel.com (Jon Radel) Date: Thu May 8 00:43:24 2008 Subject: UDP weirdness In-Reply-To: <482215F4.1080806@quis.cx> References: <004f01c8b068$89c89350$9d59b9f0$@com> <005101c8b06b$5f0743c0$1d15cb40$@com> <008b01c8b081$c74692e0$55d3b8a0$@com> <482215F4.1080806@quis.cx> Message-ID: <48223E86.5010603@radel.com> Jille wrote: > > > > Ansar Mohammed schreef: >> Ok, so adding the line as you suggested worked. Thanks Kevin. >> >> But why do I need to have both entries in for >> pass in proto udp from any to any port 53 >> pass out proto udp from any to any port 53 >> >> what makes UDP so special? > UDP is stateless, > With TCP you've got an connection (identified by: local host:port and > remote host:port) > With UDP, well, you just trow the packages over the line, and hope the > is (still) someone on the other end. > > So the is (almost) no way to detect whether packets are responses to > eachother Other than looking at local host:port and remote host:port and matching things up.... Which PF does just fine ordinarily. (Only exception I can think of right now is if you're using a TFTP server which actually implements the RFC rather than breaking it to make firewalls work....) Current versions also match ICMP up with other traffic with which it is associated. But this has already been addressed in another reply. I have reread this thread and can't find any indication of which version of PF is running. This makes it rather hard to comment on whether a "keep state" would make things better, though I suspect you're using FreeBSD 7.x. So what follows are some thoughts which may or may not apply to your implementation. (Somebody else has already pointed out when the default for keep state changed.) pass in proto udp from any to any port 53 pass out proto udp from any to any port 53 can be combined into pass proto udp from any to any port 53 If the rule set is complete as presented: > > ext_if="le0" > > int_if="le1" > > int_net="192.168.3.0/24" > > ext_net="192.168.2.0/24" > > int_addr="192.168.3.1" > > ext_addr="192.168.2.2" > > scrub on $ext_if all reassemble tcp > > scrub on $int_if all reassemble tcp > > block in log all > > pass in proto icmp from any to any > > pass in proto udp from any to any port 53 > > pass in on $ext_if inet proto tcp from any to any port 3389 then you're making use of the default action of "pass" on all outbound traffic. I wouldn't recommend doing that, particularly on a firewall. To be specific, my firewall rulesets tend to start with block log all If you do that, then you need to do something such as pass in on $int_if proto udp from any to any port 53 [keep state] pass out on $ext_if proto udp all [keep state] if you want machines on the inside to initiate DNS queries, which are allowed to pass in on the internal interface and then out on the external interface. If you want DNS queries to be allowed in both directions (you have an authoritative DNS server on the inside, or something...) you'd want something like pass in proto udp from any to any port 53 [keep state] pass out proto udp all [keep state] and that would cover both directions. In writing this I am struck by an interesting question: Is there a possibility that what you're running into is a difference in the default keep state behavior in the default pass rule between UDP and TCP. The documentation I've looked at has been silent on whether the default pass rule is expected to establish state (for versions of PF recent enough), and I'm not quite curious enough to build a testbed right now. If anyone knows the answer to this one, please do share. :-) --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080508/a7a435f4/smime.bin From gergely.czuczy at harmless.hu Thu May 8 06:52:39 2008 From: gergely.czuczy at harmless.hu (CZUCZY Gergely) Date: Thu May 8 06:52:43 2008 Subject: iptables rule in pf In-Reply-To: <48222786.3050400@samoylyk.sumy.ua> References: <48222786.3050400@samoylyk.sumy.ua> Message-ID: <20080508085234.2cac29ca@twoflower.in.publishing.hu> On Thu, 08 May 2008 01:04:54 +0300 Oleksandr Samoylyk wrote: > Dear Community, > > I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. > > After reading man pf.conf for a couple of minutes I couldn't find the > realization of such iptables rule in pf: > > iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport > 25 -j DROP block in on $interface proto tcp from any to ! my.smtp.server port 25 > iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT > --to-destination :25 rdr on $interface proto tcp from any to port 2525 -> port 25 > How it can be rewriting in pf.conf? be sure to read the openbsd faq: http://www.openbsd.org/faq/pf pf works quite differently then iptables, it has a different logic. you will get used to it. just forget these "tables" which you've got used to with iptables. -- Sincerely, CZUCZY Gergely Harmless Digital Bt mailto: gergely.czuczy@harmless.hu Tel: +36-30-9702963 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080508/cd09a290/signature.pgp From oleksandr at samoylyk.sumy.ua Thu May 8 08:06:47 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Thu May 8 08:06:51 2008 Subject: iptables rule in pf In-Reply-To: <20080508085234.2cac29ca@twoflower.in.publishing.hu> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> Message-ID: <4822B459.6090307@samoylyk.sumy.ua> CZUCZY Gergely wrote: > On Thu, 08 May 2008 01:04:54 +0300 > Oleksandr Samoylyk wrote: > >> Dear Community, >> >> I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. >> >> After reading man pf.conf for a couple of minutes I couldn't find the >> realization of such iptables rule in pf: >> >> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport >> 25 -j DROP > block in on $interface proto tcp from any to ! my.smtp.server port 25 > >> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT >> --to-destination :25 > rdr on $interface proto tcp from any to port 2525 -> > port 25 I meant _any_ destination with 25 port. That iptables rule worked for any destination. >> How it can be rewriting in pf.conf? > be sure to read the openbsd faq: > http://www.openbsd.org/faq/pf > > pf works quite differently then iptables, it has a different logic. you will > get used to it. just forget these "tables" which you've got used to with > iptables. > -- Oleksandr Samoylyk OVS-RIPE From gergely.czuczy at harmless.hu Thu May 8 08:12:58 2008 From: gergely.czuczy at harmless.hu (CZUCZY Gergely) Date: Thu May 8 08:13:02 2008 Subject: iptables rule in pf In-Reply-To: <4822B459.6090307@samoylyk.sumy.ua> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> Message-ID: <20080508101252.4d25b9eb@twoflower.in.publishing.hu> On Thu, 08 May 2008 11:05:45 +0300 Oleksandr Samoylyk wrote: > CZUCZY Gergely wrote: > > On Thu, 08 May 2008 01:04:54 +0300 > > Oleksandr Samoylyk wrote: > > > >> Dear Community, > >> > >> I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. > >> > >> After reading man pf.conf for a couple of minutes I couldn't find the > >> realization of such iptables rule in pf: > >> > >> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport > >> 25 -j DROP > > block in on $interface proto tcp from any to ! my.smtp.server port 25 > > > >> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT > >> --to-destination :25 > > rdr on $interface proto tcp from any to port 2525 -> > > port 25 > > I meant _any_ destination with 25 port. > > That iptables rule worked for any destination. You cannot rewrite a packet's destination address to _any_ destination. It's like you cannot submit a package at the post office with the destination address "any". It's just meaningless. > > >> How it can be rewriting in pf.conf? > > be sure to read the openbsd faq: > > http://www.openbsd.org/faq/pf > > > > pf works quite differently then iptables, it has a different logic. you will > > get used to it. just forget these "tables" which you've got used to with > > iptables. > > > -- ?dv?lettel, Czuczy Gergely Harmless Digital Bt mailto: gergely.czuczy@harmless.hu Tel: +36-30-9702963 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080508/5d720d5f/signature.pgp From jille at quis.cx Thu May 8 08:16:22 2008 From: jille at quis.cx (Jille) Date: Thu May 8 08:16:26 2008 Subject: iptables rule in pf In-Reply-To: <20080508101252.4d25b9eb@twoflower.in.publishing.hu> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> Message-ID: <4822B6CC.1080502@quis.cx> CZUCZY Gergely schreef: > On Thu, 08 May 2008 11:05:45 +0300 > Oleksandr Samoylyk wrote: > > >> CZUCZY Gergely wrote: >> >>> On Thu, 08 May 2008 01:04:54 +0300 >>> Oleksandr Samoylyk wrote: >>> >>> >>>> Dear Community, >>>> >>>> I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. >>>> >>>> After reading man pf.conf for a couple of minutes I couldn't find the >>>> realization of such iptables rule in pf: >>>> >>>> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport >>>> 25 -j DROP >>>> >>> block in on $interface proto tcp from any to ! my.smtp.server port 25 >>> >>> >>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT >>>> --to-destination :25 >>>> >>> rdr on $interface proto tcp from any to port 2525 -> >>> port 25 >>> >> I meant _any_ destination with 25 port. >> >> That iptables rule worked for any destination. >> > You cannot rewrite a packet's destination address to _any_ destination. > > It's like you cannot submit a package at the post office with the destination > address "any". It's just meaningless. > I think he only want to 'change' the port-number, and don't touch the destination address. You could try: rdr on $interface proto tcp from any to port 2525 -> port 25 But that's a wild guess (I'm *not* sure) -- Jille > >>>> How it can be rewriting in pf.conf? >>>> >>> be sure to read the openbsd faq: >>> http://www.openbsd.org/faq/pf >>> >>> pf works quite differently then iptables, it has a different logic. you will >>> get used to it. just forget these "tables" which you've got used to with >>> iptables. >>> >>> > > > From koitsu at freebsd.org Thu May 8 08:20:27 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Thu May 8 08:20:31 2008 Subject: iptables rule in pf In-Reply-To: <4822B6CC.1080502@quis.cx> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822B6CC.1080502@quis.cx> Message-ID: <20080508082027.GA98876@eos.sc1.parodius.com> On Thu, May 08, 2008 at 10:16:12AM +0200, Jille wrote: >>>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT >>>>> --to-destination :25 >>>>> >>>> rdr on $interface proto tcp from any to port 2525 -> >>>> port 25 >>>> >>> I meant _any_ destination with 25 port. >>> >>> That iptables rule worked for any destination. >>> >> You cannot rewrite a packet's destination address to _any_ destination. >> >> It's like you cannot submit a package at the post office with the destination >> address "any". It's just meaningless. >> > I think he only want to 'change' the port-number, and don't touch the > destination address. > You could try: > > rdr on $interface proto tcp from any to port 2525 -> port 25 > > But that's a wild guess (I'm *not* sure) He'll need to specify an IP address for the redirection destination, e.g.: rdr on $interface proto tcp from any to port 2525 -> 127.0.0.1 port 25 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From oleksandr at samoylyk.sumy.ua Thu May 8 08:36:38 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Thu May 8 08:36:42 2008 Subject: iptables rule in pf In-Reply-To: <20080508101252.4d25b9eb@twoflower.in.publishing.hu> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> Message-ID: <4822BB8A.8030507@samoylyk.sumy.ua> CZUCZY Gergely wrote: > On Thu, 08 May 2008 11:05:45 +0300 > Oleksandr Samoylyk wrote: > >> CZUCZY Gergely wrote: >>> On Thu, 08 May 2008 01:04:54 +0300 >>> Oleksandr Samoylyk wrote: >>> >>>> Dear Community, >>>> >>>> I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. >>>> >>>> After reading man pf.conf for a couple of minutes I couldn't find the >>>> realization of such iptables rule in pf: >>>> >>>> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport >>>> 25 -j DROP >>> block in on $interface proto tcp from any to ! my.smtp.server port 25 >>> >>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT >>>> --to-destination :25 >>> rdr on $interface proto tcp from any to port 2525 -> >>> port 25 >> I meant _any_ destination with 25 port. >> >> That iptables rule worked for any destination. > You cannot rewrite a packet's destination address to _any_ destination. > > It's like you cannot submit a package at the post office with the destination > address "any". It's just meaningless. > However it works with iptables. :) What can I do in my situation in order to gain the same functionality by means of pf or other additional daemons? -- Oleksandr Samoylyk OVS-RIPE From gergely.czuczy at harmless.hu Thu May 8 08:43:13 2008 From: gergely.czuczy at harmless.hu (CZUCZY Gergely) Date: Thu May 8 08:43:18 2008 Subject: iptables rule in pf In-Reply-To: <4822BB8A.8030507@samoylyk.sumy.ua> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> Message-ID: <20080508104308.702e8911@twoflower.in.publishing.hu> On Thu, 08 May 2008 11:36:26 +0300 Oleksandr Samoylyk wrote: > >> That iptables rule worked for any destination. > > You cannot rewrite a packet's destination address to _any_ destination. > > > > It's like you cannot submit a package at the post office with the > > destination address "any". It's just meaningless. > > > > However it works with iptables. :) > > What can I do in my situation in order to gain the same functionality by > means of pf or other additional daemons? No, it doesn't. That iptables rule only affects the port number, where it defaults to the original dst address. So it defaults to something, where as pf doesn't. With pf you have to explicitly specify the rewritten dst IP. In my first reply I've told you to read the openbsd FAQ. You haven't done it. I _strongly_ suggest you, before doing your next reply to the list. go and read that FAQ. Here's the URL once more, I bet you've lost it under your desk... http://www.openbsd.org/faq/pf/ -- Sincerely, CZUCZY Gergely Harmless Digital Bt mailto: gergely.czuczy@harmless.hu Tel: +36-30-9702963 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080508/7003a599/signature.pgp From elliott at c7.ca Thu May 8 08:43:35 2008 From: elliott at c7.ca (Elliott Perrin) Date: Thu May 8 08:43:40 2008 Subject: iptables rule in pf In-Reply-To: <48222786.3050400@samoylyk.sumy.ua> References: <48222786.3050400@samoylyk.sumy.ua> Message-ID: <1210236182.5607.138.camel@kensho.c7.ca> On Thu, 2008-05-08 at 01:04 +0300, Oleksandr Samoylyk wrote: > Dear Community, > > I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. > > After reading man pf.conf for a couple of minutes I couldn't find the > realization of such iptables rule in pf: > > iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport > 25 -j DROP > iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT > --to-destination :25 > > How it can be rewriting in pf.conf? > > Thanks! > Its been a while since I worked with iptables but The first rule ? iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport 25 -j DROP says all packets destined for port 25 for any address other than my.smtp.server, jump to the builtin DROP table/chain. The second rule ?iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT --to-destination :25 I would think builds on the first (just like in pf order of rule processing is very important) and says anything with a destination of port 2525, jump to the DNAT table/chain and switch the destination port to port 25, leaving the destination IP address untouched. Essentially you are just doing PAT there. Hard to know exactly what you are trying to do without network topography. Is this on a three legged firewall for LAN to DMZ/Internet connections or is this intended for inbound connections to your SMTP servers? The rules in pf to serve either purpose would be different. Also what does your DNAT table look like? That second rule causes packets to rewrite their destination port, but what then happens in the DNAT table? Cheers, ~e From elliott at c7.ca Thu May 8 08:59:14 2008 From: elliott at c7.ca (Elliott Perrin) Date: Thu May 8 08:59:18 2008 Subject: iptables rule in pf In-Reply-To: <4822BB8A.8030507@samoylyk.sumy.ua> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> Message-ID: <1210237122.5607.149.camel@kensho.c7.ca> On Thu, 2008-05-08 at 11:36 +0300, Oleksandr Samoylyk wrote: > CZUCZY Gergely wrote: > > On Thu, 08 May 2008 11:05:45 +0300 > > Oleksandr Samoylyk wrote: > > > >> CZUCZY Gergely wrote: > >>> On Thu, 08 May 2008 01:04:54 +0300 > >>> Oleksandr Samoylyk wrote: > >>> > >>>> Dear Community, > >>>> > >>>> I want to move some of our firewalls from Linux/iptables to FreeBSD/pf. > >>>> > >>>> After reading man pf.conf for a couple of minutes I couldn't find the > >>>> realization of such iptables rule in pf: > >>>> > >>>> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport > >>>> 25 -j DROP > >>> block in on $interface proto tcp from any to ! my.smtp.server port 25 > >>> > >>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT > >>>> --to-destination :25 > >>> rdr on $interface proto tcp from any to port 2525 -> > >>> port 25 > >> I meant _any_ destination with 25 port. > >> > >> That iptables rule worked for any destination. > > You cannot rewrite a packet's destination address to _any_ destination. > > > > It's like you cannot submit a package at the post office with the destination > > address "any". It's just meaningless. > > > > However it works with iptables. :) > > What can I do in my situation in order to gain the same functionality by > means of pf or other additional daemons? > It doesn't just "work" in iptables. All you are doing is PAT with that rule, rewriting destination ports. What does your DNAT table look like where packets matching this rule then jump to? That iptables rule may have worked for any destination, but it merely jumps (-j) to another table where address rewriting is pretty much a guarantee since by definition DNAT is Destination Network Address Translation. That rule does PAT and nothing more. If those 2 rules alone form the base logic of your firewall structure I would really love to know the address of that machine :-) Cheers ~e From daniel at roe.ch Thu May 8 11:34:56 2008 From: daniel at roe.ch (Daniel Roethlisberger) Date: Thu May 8 11:35:01 2008 Subject: iptables rule in pf In-Reply-To: <1210237122.5607.149.camel@kensho.c7.ca> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> <1210237122.5607.149.camel@kensho.c7.ca> Message-ID: <20080508113524.GA7168@hobbes.ustdmz.roe.ch> Elliott Perrin 2008-05-08: > On Thu, 2008-05-08 at 11:36 +0300, Oleksandr Samoylyk wrote: > > CZUCZY Gergely wrote: > > > On Thu, 08 May 2008 11:05:45 +0300 Oleksandr Samoylyk > > > wrote: > > >> CZUCZY Gergely wrote: > > >>> On Thu, 08 May 2008 01:04:54 +0300 Oleksandr Samoylyk > > >>> wrote: > > >>>> Dear Community, > > >>>> > > >>>> I want to move some of our firewalls from Linux/iptables to > > >>>> FreeBSD/pf. > > >>>> > > >>>> After reading man pf.conf for a couple of minutes I couldn't > > >>>> find the realization of such iptables rule in pf: > > >>>> > > >>>> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p > > >>>> tcp --dport 25 -j DROP > > >>> block in on $interface proto tcp from any to ! my.smtp.server > > >>> port 25 > > >>> > > >>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j > > >>>> DNAT --to-destination :25 > > >>> rdr on $interface proto tcp from any to port 2525 -> > > >>> port 25 > > >> I meant _any_ destination with 25 port. > > >> > > >> That iptables rule worked for any destination. > > > You cannot rewrite a packet's destination address to _any_ > > > destination. > > > > > > It's like you cannot submit a package at the post office with the > > > destination address "any". It's just meaningless. > > > > However it works with iptables. :) > > > > What can I do in my situation in order to gain the same > > functionality by means of pf or other additional daemons? > > It doesn't just "work" in iptables. All you are doing is PAT with that > rule, rewriting destination ports. What does your DNAT table look like > where packets matching this rule then jump to? [...] Your analysis of the two provided netfilter rules is wrong. DNAT is a built-in pseudo-chain which does the actual destination address/port translation, in this case it rewrites the destination port to 25 and leaves the destination address untouched. Just to clear up some of the terms used with netfilter: you don't jump to tables, you jump to chains. Tables in netfilter are "nat", "filter" and "mangle"; like parallel worlds with their own set of chains, each table having a distinct purpose (packet filtering, address/port translations, and other packet mangling/tagging). -- Daniel Roethlisberger http://daniel.roe.ch/ From daniel at roe.ch Thu May 8 11:57:53 2008 From: daniel at roe.ch (Daniel Roethlisberger) Date: Thu May 8 11:57:56 2008 Subject: iptables rule in pf In-Reply-To: <20080508104308.702e8911@twoflower.in.publishing.hu> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> <20080508104308.702e8911@twoflower.in.publishing.hu> Message-ID: <20080508115823.GB7168@hobbes.ustdmz.roe.ch> CZUCZY Gergely 2008-05-08: > On Thu, 08 May 2008 11:36:26 +0300 Oleksandr Samoylyk > wrote: > > >> That iptables rule worked for any destination. > > > You cannot rewrite a packet's destination address to _any_ > > > destination. > > > > > > It's like you cannot submit a package at the post office with the > > > destination address "any". It's just meaningless. > > > > However it works with iptables. :) > > > > What can I do in my situation in order to gain the same > > functionality by means of pf or other additional daemons? > No, it doesn't. That iptables rule only affects the port number, where > it defaults to the original dst address. So it defaults to something, > where as pf doesn't. With pf you have to explicitly specify the > rewritten dst IP. > > In my first reply I've told you to read the openbsd FAQ. You haven't > done it. I _strongly_ suggest you, before doing your next reply to the > list. go and read that FAQ. Here's the URL once more, I bet you've > lost it under your desk... http://www.openbsd.org/faq/pf/ Netfilter allows to rewrite the destination port without rewriting the destination address. It would seem like that this is not possible with pf, at least not using rdr. But it is not necessary, since my.smtp.server is the only destination on port 25 that will not be dropped by the previous rule, so you can just specify my.smtp.server as destination in the rdr rule. Just in case this is about submitting mail around port 25 filters (in contrast to a fixed MTA-MTA "tunnel" on port 2525), you probably want to use SMTP AUTH on the submission port (587) to solve this problem, not just provide plain SMTP on a different port. On the submission port, authentication is mandatory, which prevents it being used by spambots to deliver mail directly to your MTA. Using submission and blocking port 25 for end-user address ranges does have anti-spam benefits. -- Daniel Roethlisberger http://daniel.roe.ch/ From viaprog at gmail.com Thu May 8 14:39:36 2008 From: viaprog at gmail.com (Igor A. Valcov) Date: Thu May 8 14:39:47 2008 Subject: do not work nested unnamed anchor Message-ID: Hello. For example: ==== pf.conf ==== ext_if="xl0" ip_world="nn.nn.nn.nn" # Filter rules block log all anchor in on $ext_if { pass quick proto tcp to $ip_world port 22 keep state # SSH pass quick proto tcp to $ip_world port 25 keep state # SMTP pass quick proto tcp to $ip_world port 110 keep state # POP3 anchor { pass quick proto tcp to $ip_world port 995 keep state # POP3S } } ============ nmap results: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0) 25/tcp open smtp? 110/tcp open pop3 Openwall popa3d I can not understand what the problem... FreeBSD-7.0-RELEASE-p1 i386 -- Igor A. Valcov From ermal.luci at gmail.com Thu May 8 15:47:00 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Thu May 8 15:47:03 2008 Subject: Patch to allow shaping inside ipsec tunnels with ALTQ. Message-ID: <9a542da30805080846v1bcde1afp79293ac3efda2865@mail.gmail.com> This one is for RELENG_7[_0] but should apply ok to CURRENT too. http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/ipsec_altq.diff?rev=1.2;content-type=text%2Fplain For RELENG_6 check the freebsd-ipfw@ list i sent one there in reply to a thread. Ermal From ermal.luci at gmail.com Thu May 8 16:41:30 2008 From: ermal.luci at gmail.com (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Thu May 8 16:41:33 2008 Subject: iptables rule in pf In-Reply-To: <20080508115823.GB7168@hobbes.ustdmz.roe.ch> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> <20080508104308.702e8911@twoflower.in.publishing.hu> <20080508115823.GB7168@hobbes.ustdmz.roe.ch> Message-ID: <9a542da30805080941odbc9f74g1a2367285c5a718a@mail.gmail.com> On Thu, May 8, 2008 at 1:58 PM, Daniel Roethlisberger wrote: > CZUCZY Gergely 2008-05-08: >> On Thu, 08 May 2008 11:36:26 +0300 Oleksandr Samoylyk >> wrote: >> > >> That iptables rule worked for any destination. >> > > You cannot rewrite a packet's destination address to _any_ >> > > destination. >> > > >> > > It's like you cannot submit a package at the post office with the >> > > destination address "any". It's just meaningless. >> > >> > However it works with iptables. :) >> > >> > What can I do in my situation in order to gain the same >> > functionality by means of pf or other additional daemons? >> No, it doesn't. That iptables rule only affects the port number, where >> it defaults to the original dst address. So it defaults to something, >> where as pf doesn't. With pf you have to explicitly specify the >> rewritten dst IP. >> >> In my first reply I've told you to read the openbsd FAQ. You haven't >> done it. I _strongly_ suggest you, before doing your next reply to the >> list. go and read that FAQ. Here's the URL once more, I bet you've >> lost it under your desk... http://www.openbsd.org/faq/pf/ > > Netfilter allows to rewrite the destination port without rewriting the > destination address. It would seem like that this is not possible with > pf, at least not using rdr. But it is not necessary, since > my.smtp.server is the only destination on port 25 that will not be > dropped by the previous rule, so you can just specify my.smtp.server as > destination in the rdr rule. > > Just in case this is about submitting mail around port 25 filters (in > contrast to a fixed MTA-MTA "tunnel" on port 2525), you probably want to > use SMTP AUTH on the submission port (587) to solve this problem, not > just provide plain SMTP on a different port. On the submission port, > authentication is mandatory, which prevents it being used by spambots to > deliver mail directly to your MTA. Using submission and blocking port > 25 for end-user address ranges does have anti-spam benefits. > > -- > Daniel Roethlisberger > http://daniel.roe.ch/ > _______________________________________________ > 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" > How about this patch. I have not really tested it but should do just port rewriting with a rule as rdr on $int proto tcp from any to any port 255 -> port 25 any Ermal Index: contrib/pf/pfctl/parse.y =================================================================== RCS file: /home/ncvs/src/contrib/pf/pfctl/parse.y,v retrieving revision 1.8 diff -u -r1.8 parse.y --- contrib/pf/pfctl/parse.y 3 Jul 2007 12:30:02 -0000 1.8 +++ contrib/pf/pfctl/parse.y 8 May 2008 16:33:30 -0000 @@ -3326,6 +3326,12 @@ $$->host = $2; $$->rport.a = $$->rport.b = $$->rport.t = 0; } + | ARROW PORT rport { + $$ = calloc(1, sizeof(struct redirection)); + if ($$ == NULL) + err(1, "redirection: calloc"); + $$->rport = $4; + } | ARROW redirspec PORT rport { $$ = calloc(1, sizeof(struct redirection)); if ($$ == NULL) @@ -3442,6 +3448,13 @@ pool_opts.marker |= POM_STICKYADDRESS; pool_opts.opts |= PF_POOL_STICKYADDR; } + | ANY { + if (pool_opts.type) { + yyerror("pool type cannot be redefined"); + YYERROR; + } + pool_opts.type = PF_POOL_ANY; + } ; redirection : /* empty */ { $$ = NULL; } @@ -3549,6 +3562,10 @@ YYERROR; } } else { + r.rpool.opts = $10.type; + if ((r.rpool.opts & PF_POOL_TYPEMASK) != + PF_POOL_ANY) { + if ($9 == NULL || $9->host == NULL) { yyerror("translation rule requires '-> " "address'"); @@ -3562,6 +3579,14 @@ YYERROR; if (check_netmask($9->host, r.af)) YYERROR; + } + + if ((r.rpool.opts & PF_POOL_TYPEMASK) == + PF_POOL_ANY && r.action != PF_RDR) { + yyerror("any pool type valid only for rdr" + " action"); + YYERROR; + } r.rpool.proxy_port[0] = ntohs($9->rport.a); @@ -3596,7 +3621,6 @@ break; } - r.rpool.opts = $10.type; if ((r.rpool.opts & PF_POOL_TYPEMASK) == PF_POOL_NONE && ($9->host->next != NULL || $9->host->addr.type == PF_ADDR_TABLE || @@ -3614,7 +3638,7 @@ "is only supported in round-robin " "redirection pools")) YYERROR; - if ($9->host->next != NULL) { + if ($9 != NULL && $9->host != NULL && $9->host->next != NULL) { if ((r.rpool.opts & PF_POOL_TYPEMASK) != PF_POOL_ROUNDROBIN) { yyerror("only round-robin " Index: sys/contrib/pf/net/pf.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/pf.c,v retrieving revision 1.46.2.1 diff -u -r1.46.2.1 pf.c --- sys/contrib/pf/net/pf.c 25 Nov 2007 19:26:46 -0000 1.46.2.1 +++ sys/contrib/pf/net/pf.c 8 May 2008 16:33:31 -0000 @@ -2859,13 +2859,18 @@ } break; case PF_RDR: { - if (pf_map_addr(pd->af, r, saddr, naddr, NULL, sn)) - return (NULL); - if ((r->rpool.opts & PF_POOL_TYPEMASK) == - PF_POOL_BITMASK) - PF_POOLMASK(naddr, naddr, - &r->rpool.cur->addr.v.a.mask, daddr, - pd->af); + if ((r->rpool.opts & PF_POOL_TYPEMASK) == + PF_POOL_ANY) { + PF_ACPY(naddr, daddr, pd->af); + } else { + if (pf_map_addr(pd->af, r, saddr, naddr, NULL, sn)) + return (NULL); + if ((r->rpool.opts & PF_POOL_TYPEMASK) == + PF_POOL_BITMASK) + PF_POOLMASK(naddr, naddr, + &r->rpool.cur->addr.v.a.mask, daddr, + pd->af); + } if (r->rpool.proxy_port[1]) { u_int32_t tmp_nport; Index: sys/contrib/pf/net/pfvar.h =================================================================== RCS file: /home/ncvs/src/sys/contrib/pf/net/pfvar.h,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 pfvar.h --- sys/contrib/pf/net/pfvar.h 12 Apr 2008 18:26:48 -0000 1.16.2.1 +++ sys/contrib/pf/net/pfvar.h 8 May 2008 16:33:31 -0000 @@ -130,7 +130,7 @@ PF_LIMIT_TABLES, PF_LIMIT_TABLE_ENTRIES, PF_LIMIT_MAX }; #define PF_POOL_IDMASK 0x0f enum { PF_POOL_NONE, PF_POOL_BITMASK, PF_POOL_RANDOM, - PF_POOL_SRCHASH, PF_POOL_ROUNDROBIN }; + PF_POOL_SRCHASH, PF_POOL_ROUNDROBIN, PF_POOL_ANY }; enum { PF_ADDR_ADDRMASK, PF_ADDR_NOROUTE, PF_ADDR_DYNIFTL, PF_ADDR_TABLE, PF_ADDR_RTLABEL, PF_ADDR_URPFFAILED }; #define PF_POOL_TYPEMASK 0x0f From elliott at c7.ca Fri May 9 02:16:16 2008 From: elliott at c7.ca (Elliott Perrin) Date: Fri May 9 02:16:21 2008 Subject: iptables rule in pf In-Reply-To: <20080508113524.GA7168@hobbes.ustdmz.roe.ch> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> <1210237122.5607.149.camel@kensho.c7.ca> <20080508113524.GA7168@hobbes.ustdmz.roe.ch> Message-ID: <1210299343.28559.31.camel@kensho.c7.ca> On Thu, 2008-05-08 at 13:35 +0200, Daniel Roethlisberger wrote: > Elliott Perrin 2008-05-08: > > On Thu, 2008-05-08 at 11:36 +0300, Oleksandr Samoylyk wrote: > > > CZUCZY Gergely wrote: > > > > On Thu, 08 May 2008 11:05:45 +0300 Oleksandr Samoylyk > > > > wrote: > > > >> CZUCZY Gergely wrote: > > > >>> On Thu, 08 May 2008 01:04:54 +0300 Oleksandr Samoylyk > > > >>> wrote: > > > >>>> Dear Community, > > > >>>> > > > >>>> I want to move some of our firewalls from Linux/iptables to > > > >>>> FreeBSD/pf. > > > >>>> > > > >>>> After reading man pf.conf for a couple of minutes I couldn't > > > >>>> find the realization of such iptables rule in pf: > > > >>>> > > > >>>> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p > > > >>>> tcp --dport 25 -j DROP > > > >>> block in on $interface proto tcp from any to ! my.smtp.server > > > >>> port 25 > > > >>> > > > >>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j > > > >>>> DNAT --to-destination :25 > > > >>> rdr on $interface proto tcp from any to port 2525 -> > > > >>> port 25 > > > >> I meant _any_ destination with 25 port. > > > >> > > > >> That iptables rule worked for any destination. > > > > You cannot rewrite a packet's destination address to _any_ > > > > destination. > > > > > > > > It's like you cannot submit a package at the post office with the > > > > destination address "any". It's just meaningless. > > > > > > However it works with iptables. :) > > > > > > What can I do in my situation in order to gain the same > > > functionality by means of pf or other additional daemons? > > > > It doesn't just "work" in iptables. All you are doing is PAT with that > > rule, rewriting destination ports. What does your DNAT table look like > > where packets matching this rule then jump to? [...] > > Your analysis of the two provided netfilter rules is wrong. DNAT is a > built-in pseudo-chain which does the actual destination address/port > translation, in this case it rewrites the destination port to 25 and > leaves the destination address untouched. > > Just to clear up some of the terms used with netfilter: you don't jump > to tables, you jump to chains. Tables in netfilter are "nat", "filter" > and "mangle"; like parallel worlds with their own set of chains, each > table having a distinct purpose (packet filtering, address/port > translations, and other packet mangling/tagging). > I was not sure if DNAT was a built in or not. As far as the difference between tables / chains, thanks for clearing that up. I have not firewalled with ipchains/iptables for quite some time so I am not completely up to speed on the semantics surrounding the software's current incarnation. If having used incorrect terminology resulted in difficulties I apologize. However, from a processing perspective my analysis is correct in concept. The second rule does a port address translation switching the destination port from port 2525 to port 25 on packets that match the rule. My analysis of both rules was in a previous reply to the posters original email, I have included that analysis again below. Perhaps if it too is incorrect from a conceptual perspective you could be so kind as to point out why? "?iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server -p tcp --dport 25 -j DROP says all packets destined for port 25 for any address other than my.smtp.server, jump to the builtin DROP table/chain. ?The second rule ?iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 -j DNAT --to-destination :25 I would think builds on the first (just like in pf order of rule processing is very important) and says anything with a destination of port 2525, jump to the DNAT table/chain and switch the destination port to port 25, leaving the destination IP address untouched. Essentially you are just doing PAT there. Hard to know exactly what you are trying to do without network topography. Is this on a three legged firewall for LAN to DMZ/Internet connections or is this intended for inbound connections to your SMTP servers? The rules in pf to serve either purpose would be different." From daniel at roe.ch Fri May 9 09:58:13 2008 From: daniel at roe.ch (Daniel Roethlisberger) Date: Fri May 9 09:58:17 2008 Subject: iptables rule in pf In-Reply-To: <1210299343.28559.31.camel@kensho.c7.ca> References: <48222786.3050400@samoylyk.sumy.ua> <20080508085234.2cac29ca@twoflower.in.publishing.hu> <4822B459.6090307@samoylyk.sumy.ua> <20080508101252.4d25b9eb@twoflower.in.publishing.hu> <4822BB8A.8030507@samoylyk.sumy.ua> <1210237122.5607.149.camel@kensho.c7.ca> <20080508113524.GA7168@hobbes.ustdmz.roe.ch> <1210299343.28559.31.camel@kensho.c7.ca> Message-ID: <20080509095831.GB14550@hobbes.ustdmz.roe.ch> Elliott Perrin 2008-05-08: > On Thu, 2008-05-08 at 13:35 +0200, Daniel Roethlisberger wrote: > > Elliott Perrin 2008-05-08: > > > On Thu, 2008-05-08 at 11:36 +0300, Oleksandr Samoylyk wrote: > > > > CZUCZY Gergely wrote: > > > > > On Thu, 08 May 2008 11:05:45 +0300 Oleksandr Samoylyk > > > > > wrote: > > > > >> CZUCZY Gergely wrote: > > > > >>> On Thu, 08 May 2008 01:04:54 +0300 Oleksandr Samoylyk > > > > >>> wrote: > > > > >>>> Dear Community, > > > > >>>> > > > > >>>> I want to move some of our firewalls from Linux/iptables to > > > > >>>> FreeBSD/pf. > > > > >>>> > > > > >>>> After reading man pf.conf for a couple of minutes I > > > > >>>> couldn't find the realization of such iptables rule in pf: > > > > >>>> > > > > >>>> iptables -t nat -A PREROUTING -i ethX -d ! my.smtp.server > > > > >>>> -p tcp --dport 25 -j DROP > > > > >>> block in on $interface proto tcp from any to ! > > > > >>> my.smtp.server port 25 > > > > >>> > > > > >>>> iptables -t nat -A PREROUTING -i ethX -p tcp --dport 2525 > > > > >>>> -j DNAT --to-destination :25 > > > > >>> rdr on $interface proto tcp from any to port 2525 -> > > > > >>> port 25 > > > > >> I meant _any_ destination with 25 port. > > > > >> > > > > >> That iptables rule worked for any destination. > > > > > You cannot rewrite a packet's destination address to _any_ > > > > > destination. > > > > > > > > > > It's like you cannot submit a package at the post office with > > > > > the destination address "any". It's just meaningless. > > > > > > > > However it works with iptables. :) > > > > > > > > What can I do in my situation in order to gain the same > > > > functionality by means of pf or other additional daemons? > > > > > > It doesn't just "work" in iptables. All you are doing is PAT with > > > that rule, rewriting destination ports. What does your DNAT table > > > look like where packets matching this rule then jump to? [...] > > > > Your analysis of the two provided netfilter rules is wrong. DNAT is > > a built-in pseudo-chain which does the actual destination > > address/port translation, in this case it rewrites the destination > > port to 25 and leaves the destination address untouched. > > > > Just to clear up some of the terms used with netfilter: you don't > > jump to tables, you jump to chains. Tables in netfilter are "nat", > > "filter" and "mangle"; like parallel worlds with their own set of > > chains, each table having a distinct purpose (packet filtering, > > address/port translations, and other packet mangling/tagging). > > > > I was not sure if DNAT was a built in or not. As far as the difference > between tables / chains, thanks for clearing that up. I have not > firewalled with ipchains/iptables for quite some time so I am not > completely up to speed on the semantics surrounding the software's > current incarnation. If having used incorrect terminology resulted in > difficulties I apologize. > > However, from a processing perspective my analysis is correct in > concept. The second rule does a port address translation switching the > destination port from port 2525 to port 25 on packets that match the > rule. > [...] You are right in that aspect, I apologize for my bad choice of words. -- Daniel Roethlisberger http://daniel.roe.ch/ From viaprog at gmail.com Fri May 9 12:54:44 2008 From: viaprog at gmail.com (Igor A. Valcov) Date: Fri May 9 12:54:47 2008 Subject: do not work nested unnamed anchor Message-ID: Hello. For example: ==== pf.conf ==== ext_if="xl0" ip_world="nn.nn.nn.nn" # Filter rules block log all anchor in on $ext_if { pass quick proto tcp to $ip_world port 22 keep state # SSH pass quick proto tcp to $ip_world port 25 keep state # SMTP pass quick proto tcp to $ip_world port 110 keep state # POP3 anchor { pass quick proto tcp to $ip_world port 995 keep state # POP3S } } ============ nmap results: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0) 25/tcp open smtp? 110/tcp open pop3 Openwall popa3d I can not understand what the problem... FreeBSD-7.0-RELEASE-p1 i386 -- Igor A. Valcov From salvador_d13 at yahoo.com.ph Mon May 12 05:55:27 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Mon May 12 05:55:30 2008 Subject: Using ALTQ without PF in FreeBSD Message-ID: <326998.93432.qm@web76107.mail.sg1.yahoo.com> To Whom It May Concerned: Hi! Is it possible to use ALTQ in FreeBSD without PF? Because what I want to achieve is to build a QoS system/machine in a Diffserv or Intserv network without firewall. It seems like ALTQ is tightly coupled with PF. I have read this http://pf4freebsd.love2party.net/altq.html that ALTQ integration in FreeBSD is in PF-Mode not in COMPAT Mode? Can someone elaborate the difference between these types of modes? The info describes FreeBSD-5, Is it still affecting FreeBSD-6.2/6.3 and FreeBSD-7.0 releases? In NetBSD, ALTQ can be used without PF or other means of firewall. Thank you very much! Diego Salvador --------------------------------- Support Victims of the Cyclone in Myanmar (Burma). Donate Now. From jille at quis.cx Mon May 12 09:24:51 2008 From: jille at quis.cx (Jille Timmermans) Date: Mon May 12 09:24:53 2008 Subject: Using ALTQ without PF in FreeBSD In-Reply-To: <326998.93432.qm@web76107.mail.sg1.yahoo.com> References: <326998.93432.qm@web76107.mail.sg1.yahoo.com> Message-ID: <4828093D.200@quis.cx> Hello, Diego Salvador wrote: > To Whom It May Concerned: > > Hi! Is it possible to use ALTQ in FreeBSD without PF? I know it is possibly to use ALTQ with IPFW (another firewall), > Because what I want to achieve is to build a QoS system/machine in a Diffserv or Intserv network > without firewall. It seems like ALTQ is tightly coupled with PF. But not whether you can use it entirely without any firewall. > I have read this > http://pf4freebsd.love2party.net/altq.html that ALTQ integration in FreeBSD > is in PF-Mode not in COMPAT Mode? Can someone elaborate the difference > between these types of modes? The info describes FreeBSD-5, Is it still > affecting FreeBSD-6.2/6.3 and FreeBSD-7.0 releases? In NetBSD, ALTQ > can be used without PF or other means of firewall. Can't you enable PF, add some firewall rules that passes on all data, and apply the altq's ? afaik pf should not screw up your packets (if you leave all other stuff behind) -- Jille > > Thank you very much! > > Diego Salvador > > > --------------------------------- > Support Victims of the Cyclone in Myanmar (Burma). > Donate Now. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon May 12 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 12 11:07:13 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200805121107.m4CB72Tc038096@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/116610 pf [patch] teach tcpdump(1) to cope with the new-style pf o kern/120281 pf [request] lost returning packets to PF for a rdr rule o kern/122014 pf [panic] FreeBSD 6.2 panic in pf 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf tagged parameter on nat not working on FreeBSD 5.2 o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c f kern/116645 pf [request] pfctl -k does not work in securelevel 3 o kern/118355 pf [pf] [patch] pfctl help message options order false -t o kern/120057 pf [patch] Allow proper settings of ALTQ_HFSC. The check o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to 10 problems total. From salvador_d13 at yahoo.com.ph Mon May 12 12:37:41 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Mon May 12 12:37:46 2008 Subject: Using ALTQ without PF in FreeBSD Message-ID: <680753.77770.qm@web76106.mail.sg1.yahoo.com> Hi Jille, Building a DiffServ domain network will require DiffServ Code Point (DSCP) values or bits for packet marking and re-marking for QoS. PF only supports Type-of-Service (TOS) bits. Thanks, Diego Salvador Diego Salvador wrote: > To Whom It May Concerned: > > Hi! Is it possible to use ALTQ in FreeBSD without PF? I know it is possibly to use ALTQ with IPFW (another firewall), > Because what I want to achieve is to build a QoS system/machine in a Diffserv or Intserv network > without firewall. It seems like ALTQ is tightly coupled with PF. But not whether you can use it entirely without any firewall. > I have read this > http://pf4freebsd.love2party.net/altq.html that ALTQ integration in FreeBSD > is in PF-Mode not in COMPAT Mode? Can someone elaborate the difference > between these types of modes? The info describes FreeBSD-5, Is it still > affecting FreeBSD-6.2/6.3 and FreeBSD-7.0 releases? In NetBSD, ALTQ > can be used without PF or other means of firewall. Can't you enable PF, add some firewall rules that passes on all data, and apply the altq's ? afaik pf should not screw up your packets (if you leave all other stuff behind) -- Jille Diego Salvador wrote: To Whom It May Concerned: Hi! Is it possible to use ALTQ in FreeBSD without PF? Because what I want to achieve is to build a QoS system/machine in a Diffserv or Intserv network without firewall. It seems like ALTQ is tightly coupled with PF. I have read this http://pf4freebsd.love2party.net/altq.html that ALTQ integration in FreeBSD is in PF-Mode not in COMPAT Mode? Can someone elaborate the difference between these types of modes? The info describes FreeBSD-5, Is it still affecting FreeBSD-6.2/6.3 and FreeBSD-7.0 releases? In NetBSD, ALTQ can be used without PF or other means of firewall. Thank you very much! Diego Salvador --------------------------------- Support Victims of the Cyclone in Myanmar (Burma). Donate Now. --------------------------------- Support Victims of the Cyclone in Myanmar (Burma). Donate Now. From max at love2party.net Mon May 12 12:58:11 2008 From: max at love2party.net (Max Laier) Date: Mon May 12 12:58:14 2008 Subject: Using ALTQ without PF in FreeBSD In-Reply-To: <326998.93432.qm@web76107.mail.sg1.yahoo.com> References: <326998.93432.qm@web76107.mail.sg1.yahoo.com> Message-ID: <200805121453.32022.max@love2party.net> Hello Diego, On Monday 12 May 2008 07:41:30 Diego Salvador wrote: > Hi! Is it possible to use ALTQ in FreeBSD without PF? Because what I > want to achieve is to build a QoS system/machine in a Diffserv or > Intserv network without firewall. It seems like ALTQ is tightly coupled > with PF. I have read this http://pf4freebsd.love2party.net/altq.html > that ALTQ integration in FreeBSD is in PF-Mode not in COMPAT Mode? Can > someone elaborate the difference between these types of modes? The info > describes FreeBSD-5, Is it still affecting FreeBSD-6.2/6.3 and > FreeBSD-7.0 releases? In NetBSD, ALTQ can be used without PF or other > means of firewall. basically there are two parts to traffic shaping: 1) Classification of traffic 2) The actual queuing ALTQ used to do both, i.e. you could specify classifications based on src/dst/dscp/... in altqd and it would dig into the packets itself. This classification, however, turned out to be absolutely incompatible with the SMPng goals and when I imported ALTQ it was decided to disable it (because nobody had interest in locking it down for SMPng compliance). The classification in "PF-mode" is rather simple: any firewall (or other policy tool plugged into the pfil(9) API) can classify packets for ALTQ by adding a mbuf_tag to the packet. ALTQ only takes care of the actual queuing. Today, IPFW and PF are able to classify packets this way. IIRC, there are patches floating around to teach IPFW about DSCP (they might even be in the tree already). If neither tool meets your requirements, it should be easy enough to plug an application specific filter into pfil(9) that would do the classification. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From salvador_d13 at yahoo.com.ph Mon May 12 14:18:37 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Mon May 12 14:18:42 2008 Subject: Using ALTQ without PF in FreeBSD In-Reply-To: <200805121453.32022.max@love2party.net> Message-ID: <694237.4939.qm@web76113.mail.sg1.yahoo.com> Hi Max, Thanks for your reply and explanation! I now understand why ALTQ is in PF-mode. What are the things needed to be done in order ALTQ to be SMPng compliant? What is the use of the option ALTQ_NOPCC in the kernel? This is described to be used for SMP kernels? Yes, I will look also on the pfil(9). Thanks, Diego Salvador Max Laier wrote: Hello Diego, On Monday 12 May 2008 07:41:30 Diego Salvador wrote: > Hi! Is it possible to use ALTQ in FreeBSD without PF? Because what I > want to achieve is to build a QoS system/machine in a Diffserv or > Intserv network without firewall. It seems like ALTQ is tightly coupled > with PF. I have read this http://pf4freebsd.love2party.net/altq.html > that ALTQ integration in FreeBSD is in PF-Mode not in COMPAT Mode? Can > someone elaborate the difference between these types of modes? The info > describes FreeBSD-5, Is it still affecting FreeBSD-6.2/6.3 and > FreeBSD-7.0 releases? In NetBSD, ALTQ can be used without PF or other > means of firewall. basically there are two parts to traffic shaping: 1) Classification of traffic 2) The actual queuing ALTQ used to do both, i.e. you could specify classifications based on src/dst/dscp/... in altqd and it would dig into the packets itself. This classification, however, turned out to be absolutely incompatible with the SMPng goals and when I imported ALTQ it was decided to disable it (because nobody had interest in locking it down for SMPng compliance). The classification in "PF-mode" is rather simple: any firewall (or other policy tool plugged into the pfil(9) API) can classify packets for ALTQ by adding a mbuf_tag to the packet. ALTQ only takes care of the actual queuing. Today, IPFW and PF are able to classify packets this way. IIRC, there are patches floating around to teach IPFW about DSCP (they might even be in the tree already). If neither tool meets your requirements, it should be easy enough to plug an application specific filter into pfil(9) that would do the classification. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com From max at love2party.net Mon May 12 15:23:08 2008 From: max at love2party.net (Max Laier) Date: Mon May 12 15:23:13 2008 Subject: Using ALTQ without PF in FreeBSD In-Reply-To: <694237.4939.qm@web76113.mail.sg1.yahoo.com> References: <694237.4939.qm@web76113.mail.sg1.yahoo.com> Message-ID: <200805121718.29589.max@love2party.net> Diego, please don't top post! On Monday 12 May 2008 16:06:16 Diego Salvador wrote: > Thanks for your reply and explanation! I now understand why ALTQ is in > PF-mode. What are the things needed to be done in order ALTQ to be > SMPng compliant? I haven't looked at the classifier code in a while. But IIRC it is a mess. I don't remember the details, but I'd stay away from it. That aside, what's wrong with the existing solutions? > What is the use of the option ALTQ_NOPCC in the > kernel? This is described to be used for SMP kernels? This is something completely different. It simply tells ALTQ to not use the TSC for timing directly as it might not be in sync on SMP boxes. > Yes, I will look > also on the pfil(9). This is the right solution, though I really think that either PF or IPFW can do what you need. If not, please be more specific about what your goal is. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From max at love2party.net Mon May 12 19:25:05 2008 From: max at love2party.net (Max Laier) Date: Mon May 12 19:25:09 2008 Subject: do not work nested unnamed anchor In-Reply-To: References: Message-ID: <200805122120.15088.max@love2party.net> Hello Igor, it seems this is a general problem and I can't figure out the cause of it, ATM. It seems that it is the same in OpenBSD (and has been for quite some time, too). Daniel, Ryan, any ideas? Attached is a transcript from OpenBSD 4.3 inside of qemu trying the verbatim pf.conf(5) example. The nested anchor doesn't seem to match for some reason. While here I also discovered that it is obviously impossible to destroy/clean up after nested anchors completely. On Friday 09 May 2008 14:54:43 Igor A. Valcov wrote: > For example: > > ==== pf.conf ==== > > ext_if="xl0" > ip_world="nn.nn.nn.nn" > > # Filter rules > block log all > > anchor in on $ext_if { > pass quick proto tcp to $ip_world port 22 keep state > # SSH > pass quick proto tcp to $ip_world port 25 keep state > # SMTP > pass quick proto tcp to $ip_world port 110 keep state > # POP3 > anchor { > pass quick proto tcp to $ip_world port 995 keep state > # POP3S > } > } > > ============ > > nmap results: > > PORT STATE SERVICE VERSION > 22/tcp open ssh OpenSSH 4.5p1 (FreeBSD 20061110; protocol 2.0) > 25/tcp open smtp? > 110/tcp open pop3 Openwall popa3d > > > I can not understand what the problem... > > FreeBSD-7.0-RELEASE-p1 > i386 -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- Script started on Mon May 12 20:44:12 2008 # cat pf.conf anchor "external" on egress { block anchor out { pass proto tcp from any to port { 25, 80, 443 } } pass in proto tcp to any port 22 } # ifconfig ne3 ne3: flags=8863 mtu 1500 lladdr 52:54:00:12:34:56 groups: egress media: Ethernet 10baseT full-duplex inet6 fe80::5054:ff:fe12:3456%ne3 prefixlen 64 scopeid 0x1 inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255 # pfctl -vef pf.conf anchor "external" on egress all { block drop all anchor out all { pass proto tcp from any to any port = smtp flags S/SA keep state pass proto tcp from any to any port = www flags S/SA keep state pass proto tcp from any to any port = https flags S/SA keep state } pass in proto tcp from any to any port = ssh flags S/SA keep state } pf enabled # telnet 10.0.2.2 80 Trying 10.0.2.2... telnet: connect to address 10.0.2.2: No route to host # pfctl -vvvgsr @0 anchor "external" on egress all [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 1 Packets: 1 Bytes: 64 States: 0 ] # pfctl -vvvgsr -a external @0 block drop all [ Skip steps: i=end f=end p=2 sa=end sp=end da=end dp=2 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 1 Packets: 1 Bytes: 64 States: 0 ] @1 anchor out all { [ Skip steps: i=end f=end sa=end sp=end da=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] @0 pass proto tcp from any to any port = smtp flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @1 pass proto tcp from any to any port = www flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @2 pass proto tcp from any to any port = https flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] } @2 pass in proto tcp from any to any port = ssh flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] # telnet 10.0.2.2 25 Trying 10.0.2.2... telnet: connect to address 10.0.2.2: No route to host # pfctl -vvvgsr -a external @0 block drop all [ Skip steps: i=end f=end p=2 sa=end sp=end da=end dp=2 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 2 Packets: 2 Bytes: 128 States: 0 ] @1 anchor out all { [ Skip steps: i=end f=end sa=end sp=end da=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ] @0 pass proto tcp from any to any port = smtp flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @1 pass proto tcp from any to any port = www flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @2 pass proto tcp from any to any port = https flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] } @2 pass in proto tcp from any to any port = ssh flags S/SA keep state [ Skip steps: i=end d=end f=end p=end sa=end sp=end da=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ] # uname -a OpenBSD foo.laiers.local 4.3 GENERIC#698 i386 # ^D Script done on Mon May 12 20:45:55 2008 Script started on Mon May 12 21:03:04 2008 # pfctl -vvvsA # pfctl -vef pf.conf anchor "external" on egress all { block drop all anchor out all { pass proto tcp from any to any port = smtp flags S/SA keep state pass proto tcp from any to any port = www flags S/SA keep state pass proto tcp from any to any port = https flags S/SA keep state } pass in proto tcp from any to any port = ssh flags S/SA keep state pass out proto tcp from any to any port = smtp flags S/SA keep state } pf enabled # pfctl -vsA external external/_2 external/external external/external/_2 # pfctl -Fa rules cleared nat cleared 0 tables deleted. altq cleared 0 states cleared source tracking entries cleared pf: statistics cleared pf: interface flags reset # pfctl -vsA external external/_2 external/external external/external/_2 # pfctl -Fa -a external rules cleared nat cleared 0 tables deleted. # pfctl -vsA external external/_2 # ^D Script done on Mon May 12 21:03:51 2008 From ansarm at gmail.com Mon May 12 22:38:23 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Mon May 12 22:38:28 2008 Subject: pf + GeoIP Message-ID: <015d01c8b480$e157cb60$a4076220$@com> Hello All, Does anyone have any scripts on integrating pf with GeoIP? Is there an extension api? From m.pagulayan at auckland.ac.nz Tue May 13 02:17:54 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Tue May 13 02:17:58 2008 Subject: smtp not working with state modulation Message-ID: Hi Guys, OS: FreeBSD 7.0-RELEASE I am having trouble Allowing external request SMTP through the firewall with "module state". But with "keep state" it is working fine. Here is my rules below in pf: ext_if="em1" int_if="em0" scrub in on $ext_if block in log on $ext_if all block return out log on $ext_if all pass in log quick on $int_if pass out log quick on $int_if pass log quick on $ext_if proto tcp from any to 192.168.1.1 port 25 modulate state flags S/SA block in log quick on $ext_if proto tcp from any to any port 25 When I to try to telnet from my PC(192.169.1.2) telnet 192.168.1.1 25 I get "Connection Failed" Error. Checking on the tcpdump on interface pflog0, here is what is shows. ======================================================================== ======================= [root@fw4 /home/mark]# tcpdump -netti pflog0 port 25 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 1210641823.095857 rule 4/0(match): pass in on em1: 192.168.1.2.2573 > 192.168.1.1.25: tcp 28 [bad hdr length 0 - too short, < 20] ======================================================================== ============================ Your help would be mostly appreciated. Cheers, Mark From koitsu at freebsd.org Tue May 13 03:02:52 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Tue May 13 03:02:55 2008 Subject: smtp not working with state modulation In-Reply-To: References: Message-ID: <20080513030251.GA47608@eos.sc1.parodius.com> On Tue, May 13, 2008 at 01:53:31PM +1200, Mark Pagulayan wrote: > OS: FreeBSD 7.0-RELEASE > I am having trouble Allowing external request SMTP through the firewall > with "module state". But with "keep state" it is working fine. modulate state is known to be broken; use keep state instead. Here's the thread where I was informed of this fact: http://lists.freebsd.org/pipermail/freebsd-pf/2008-March/004223.html http://lists.freebsd.org/pipermail/freebsd-pf/2008-March/004227.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From m.pagulayan at auckland.ac.nz Tue May 13 03:23:35 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Tue May 13 03:23:39 2008 Subject: smtp not working with state modulation In-Reply-To: <20080513030251.GA47608@eos.sc1.parodius.com> References: <20080513030251.GA47608@eos.sc1.parodius.com> Message-ID: Thanks for the reply Jeremy. This is a big help. Cheers, Mark -----Original Message----- From: Jeremy Chadwick [mailto:koitsu@freebsd.org] Sent: Tuesday, 13 May 2008 3:03 p.m. To: Mark Pagulayan Cc: freebsd-pf@freebsd.org Subject: Re: smtp not working with state modulation On Tue, May 13, 2008 at 01:53:31PM +1200, Mark Pagulayan wrote: > OS: FreeBSD 7.0-RELEASE > I am having trouble Allowing external request SMTP through the firewall > with "module state". But with "keep state" it is working fine. modulate state is known to be broken; use keep state instead. Here's the thread where I was informed of this fact: http://lists.freebsd.org/pipermail/freebsd-pf/2008-March/004223.html http://lists.freebsd.org/pipermail/freebsd-pf/2008-March/004227.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From salvador_d13 at yahoo.com.ph Tue May 13 03:41:39 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Tue May 13 03:41:42 2008 Subject: Using ALTQ without PF in FreeBSD In-Reply-To: <200805121718.29589.max@love2party.net> Message-ID: <732222.17028.qm@web76101.mail.sg1.yahoo.com> Max Laier wrote: Diego, please don't top post! On Monday 12 May 2008 16:06:16 Diego Salvador wrote: > Thanks for your reply and explanation! I now understand why ALTQ is in > PF-mode. What are the things needed to be done in order ALTQ to be > SMPng compliant? I haven't looked at the classifier code in a while. But IIRC it is a mess. I don't remember the details, but I'd stay away from it. That aside, what's wrong with the existing solutions? > What is the use of the option ALTQ_NOPCC in the > kernel? This is described to be used for SMP kernels? This is something completely different. It simply tells ALTQ to not use the TSC for timing directly as it might not be in sync on SMP boxes. > Yes, I will look > also on the pfil(9). This is the right solution, though I really think that either PF or IPFW can do what you need. If not, please be more specific about what your goal is. [Diego] Okay, I really have to dig it up. The goal here is to be able to classify traffic with DSCP using ALTQ because as far as I know the ALTQ framework for QoS is originally designed to handle this. Also, from the Internet service provider (ISP) point of view, classifying traffic for services is very important especially when you provide different Internet services like data, voice and video or what we call triple-play services. Another thing, KAME snap releases kit have Weighted-Fair Queueing (WFQ) scheduler available, it might be better also if it can be integrated to FreeBSD ALTQ (PF-Mode) for hierarchical QoS aside from HFSC. Thanks, Diego Salvador -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --------------------------------- Support Victims of the Cyclone in Myanmar (Burma). Donate Now. From ansarm at gmail.com Tue May 13 15:04:53 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Tue May 13 15:04:58 2008 Subject: authpf win32 client Message-ID: <005b01c8b50a$b12d3710$1387a530$@com> Is there a win32 "client" for authpf? A simple agent to sit in the tray where the user can login and logout without having to deploy a full ssh client? From tom at uffner.com Tue May 13 23:55:33 2008 From: tom at uffner.com (Tom Uffner) Date: Tue May 13 23:55:36 2008 Subject: understanding pfctl state table output Message-ID: <482A2A6F.9060000@uffner.com> is there documentation somewhere (other than reading the source code) of exactly what all of the fields in the output from "pfctl -ss" (and "pfctl -vvvgss") mean, and all of the possible values. most of it seems pretty obvious, but it would still be nice to have a way to be sure i'm not misinterpreting things. thanks, tom From freebsd at violetlan.net Wed May 14 08:29:02 2008 From: freebsd at violetlan.net (Reinhold) Date: Wed May 14 08:29:08 2008 Subject: a few problems with pf Message-ID: <52914.217.41.34.61.1210753817.squirrel@www.violetlan.net> Hi I'm have a few problems with pf on my FreeBSD 7 STABLE systems, I have two running 7 and 4 running 6.3 and the problems are only on my 7 systems. The first problem is that I'm plagued by bad hdr length on both my 7 systems Here are the unames for them FreeBSD host1.name.local 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon May 12 20:22:55 BST 2008 edit@host1.name.local:/usr/obj/usr/src/sys/MYKERN i386 FreeBSD host.name.local 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon May 12 12:45:19 BST 2008 edit@host.name.local:/usr/obj/usr/src/sys/MYKERN i386 >From both of them I see the following when I run tcpdump -n -e -tttt -r /var/log/pflog 2008-05-07 23:42:06.596965 rule 78/0(match): pass in on ng0: 89.240.55.163.3164 > 192.168.1.5.80: tcp 20 [bad hdr length 8 - too short, < 20] 2008-05-07 23:42:07.051043 rule 78/0(match): pass in on ng0: 89.240.55.163.3165 > 192.168.1.5.80: tcp 20 [bad hdr length 8 - too short, < 20] 2008-05-07 23:42:25.697087 rule 76/0(match): pass in on ng0: 80.81.242.13.51145 > 192.168.1.5.22: tcp 36 [bad hdr length 8 - too short, < 20] 2008-05-07 23:42:30.561467 rule 77/0(match): pass in on ng1: 80.81.242.14.63900 > 192.168.1.5.22: tcp 36 [bad hdr length 8 - too short, < 20] And here are the same log again tcpdump -n -e -tttt -r /var/log/pflog 2008-05-07 23:42:06.596965 rule 78/0(match): pass in on ng0: 89.240.55.163.3164 > 192.168.1.5.80: S 3008361134:3008361134(0) win 16384 2008-05-07 23:42:07.051043 rule 78/0(match): pass in on ng0: 89.240.55.163.3165 > 192.168.1.5.80: S 1482992447:1482992447(0) win 16384 2008-05-07 23:42:25.697087 rule 76/0(match): pass in on ng0: 80.81.242.13.51145 > 192.168.1.5.22: S 555277666:555277666(0) win 65535 2008-05-07 23:42:30.561467 rule 77/0(match): pass in on ng1: 80.81.242.14.63900 > 192.168.1.5.22: S 966982942:966982942(0) win 65535 I know these logs are a few days old, but I just enabled pf on host.name.local and I saw the same things on it. I've tried a few variables with my scub rules but none seems to help I've tried all of these #scrub in on $ext_if1 all fragment reassemble max-mss 1452 #scrub out on $ext_if1 all random-id fragment reassemble max-mss 1452 #scrub all random-id max-mss 1452 fragment reassemble scrub all random-id reassemble tcp max-mss 1452 #scrub on $ext_if1 all reassemble tcp Here are the ifconfig for both hosts. host1.name.local ath0: flags=8943 metric 0 mtu 2290 ether 00:0b:6b:0b:62:c8 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: associated ssid somename channel 2 (2417 Mhz 11g) bssid 00:0b:6b:0b:62:c8 authmode WPA privacy MIXED deftxkey 3 TKIP 2:128-bit TKIP 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst dtimperiod 1 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:04:a7:09:81:80 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8843 metric 0 mtu 1500 options=8 ether 00:04:a7:09:81:7f media: Ethernet autoselect (100baseTX ) status: active re0: flags=8943 metric 0 mtu 1500 options=3998 ether 00:04:a7:05:88:c0 media: Ethernet autoselect (1000baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 pflog0: flags=141 metric 0 mtu 33204 bridge0: flags=8843 metric 0 mtu 1500 ether b6:f6:e0:49:1a:ac inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: re0 flags=143 ifmaxaddr 0 port 7 priority 128 path cost 55 member: ath0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 370370 ng0: flags=88d1 metric 0 mtu 1492 inet 217.xx.yy.zz --> 217.xx.yyy.zzz netmask 0xffffffff ng1: flags=88d1 metric 0 mtu 1492 inet 217.xy.yyz.zzz --> 217.xx.xyy.zzz netmask 0xffffffff And for host.name.local em0: flags=8943 metric 0 mtu 1500 options=98 ether 00:13:72:5f:89:b9 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 pflog0: flags=0<> metric 0 mtu 33204 bridge0: flags=8843 metric 0 mtu 1500 ether ce:4a:be:be:bc:cc id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 7 priority 128 path cost 2000000 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 55 tap0: flags=8943 metric 0 mtu 1500 ether 00:bd:e8:60:52:00 Opened by PID 45164 The other weirdness is that on host.name.local /var/log/pflog is not there. tcpdump -n -e -tttt -i pflog0 tcpdump: /var/log/pflog: No such file or directory but tcpdump -n -e -tttt -i pflog0 works fine. In both systems I have the following in the kernel # PF device pf device pflog device pfsync options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ These problems only exists in my FreeBSD 7.0-STABLE machines and not in any of the 6.3-STABLE once. The last bit of help I need is to get pf to allow ssh trough to the qemu host. Any help will be appreciated Thanks Reinhold From koitsu at FreeBSD.org Wed May 14 08:39:10 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed May 14 08:39:14 2008 Subject: a few problems with pf In-Reply-To: <52914.217.41.34.61.1210753817.squirrel@www.violetlan.net> References: <52914.217.41.34.61.1210753817.squirrel@www.violetlan.net> Message-ID: <20080514083909.GA36096@eos.sc1.parodius.com> On Wed, May 14, 2008 at 09:30:17AM +0100, Reinhold wrote: > I'm have a few problems with pf on my FreeBSD 7 STABLE systems, I have two > running 7 and 4 running 6.3 and the problems are only on my 7 systems. > > The first problem is that I'm plagued by bad hdr length on both my 7 systems When using tcpdump with pflog, you'll need to specify a large frame size to analyse/snoop; the default size is too small. Use -s 1024 to address that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd at violetlan.net Wed May 14 10:17:14 2008 From: freebsd at violetlan.net (Reinhold) Date: Wed May 14 10:17:17 2008 Subject: a few problems with pf In-Reply-To: <20080514083909.GA36096@eos.sc1.parodius.com> References: <52914.217.41.34.61.1210753817.squirrel@www.violetlan.net> <20080514083909.GA36096@eos.sc1.parodius.com> Message-ID: <59126.217.41.34.61.1210760310.squirrel@www.violetlan.net> On Wed, May 14, 2008 09:39, Jeremy Chadwick wrote: > On Wed, May 14, 2008 at 09:30:17AM +0100, Reinhold wrote: > >> I'm have a few problems with pf on my FreeBSD 7 STABLE systems, I have >> two running 7 and 4 running 6.3 and the problems are only on my 7 >> systems. >> >> The first problem is that I'm plagued by bad hdr length on both my 7 >> systems > > When using tcpdump with pflog, you'll need to specify a large frame size > to analyse/snoop; the default size is too small. Use -s 1024 to address > that. > Here is the results using -s 1024 2008-05-14 11:09:02.375144 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 2008-05-14 11:09:02.379780 rule 6/0(match): block in on ng0: 71.226.2.26.37654 > 217.41.34.61.64166: UDP, length 20 2008-05-14 11:09:03.019599 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 2008-05-14 11:09:03.672268 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 What I've also noticed is that in pf I have this rule pass in log quick on $ext_if1 reply-to ($ext_if1 $ext_gw1) proto tcp from any to { 192.168.1.2 } port = 22 keep state (max 1024, max-src-conn 15, max-src-conn-rate 2/1, overload flush global) When I'm getting the bad header thingy this rule doesn't work properly. It let all the traffic trough but it never blocks the bad guys. From freebsd at violetlan.net Wed May 14 12:40:46 2008 From: freebsd at violetlan.net (Reinhold) Date: Wed May 14 12:40:52 2008 Subject: a few problems with pf Message-ID: <63902.217.41.34.61.1210768578.squirrel@www.violetlan.net> On Wed, May 14, 2008 09:39, Jeremy Chadwick wrote: > On Wed, May 14, 2008 at 09:30:17AM +0100, Reinhold wrote: > >> I'm have a few problems with pf on my FreeBSD 7 STABLE systems, I have >> two running 7 and 4 running 6.3 and the problems are only on my 7 >> systems. >> >> The first problem is that I'm plagued by bad hdr length on both my 7 >> systems > > When using tcpdump with pflog, you'll need to specify a large frame size > to analyse/snoop; the default size is too small. Use -s 1024 to address > that. > Here is the results using -s 1024 2008-05-14 11:09:02.375144 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 2008-05-14 11:09:02.379780 rule 6/0(match): block in on ng0: 71.226.2.26.37654 > 217.41.34.61.64166: UDP, length 20 2008-05-14 11:09:03.019599 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 2008-05-14 11:09:03.672268 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 What I've also noticed is that in pf I have this rule pass in log quick on $ext_if1 reply-to ($ext_if1 $ext_gw1) proto tcp from any to { 192.168.1.2 } port = 22 keep state (max 1024, max-src-conn 15, max-src-conn-rate 2/1, overload flush global) When I'm getting the bad header thingy this rule doesn't work properly. It let all the traffic trough but it never blocks the bad guys. From jon at radel.com Wed May 14 13:51:44 2008 From: jon at radel.com (Jon Radel) Date: Wed May 14 13:51:55 2008 Subject: a few problems with pf In-Reply-To: <63902.217.41.34.61.1210768578.squirrel@www.violetlan.net> References: <63902.217.41.34.61.1210768578.squirrel@www.violetlan.net> Message-ID: <482AEE64.8020209@radel.com> Reinhold wrote: > > What I've also noticed is that in pf I have this rule > pass in log quick on $ext_if1 reply-to ($ext_if1 $ext_gw1) proto tcp from > any to { 192.168.1.2 } port = 22 keep state (max 1024, max-src-conn 15, > max-src-conn-rate 2/1, overload flush global) > > When I'm getting the bad header thingy this rule doesn't work properly. It > let all the traffic trough but it never blocks the bad guys. Which bad guys are you expecting to block? I just checked a couple day's worth of logs and the fastest rate at which somebody was trying to brute force my ssh server was 1 attempt every 2 seconds. Your rule won't trigger until 2 attempts every 1 second or faster, and I don't think those other limits are likely to get triggered either unless you see a lot more "bad guys" than I do on random addresses. I find that max-src-conn-rate 3/10 tends to cut off the more energetic ones. --Jon Radel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080514/d11b9f4f/smime.bin From freebsd at violetlan.net Wed May 14 15:15:46 2008 From: freebsd at violetlan.net (Reinhold) Date: Wed May 14 15:15:50 2008 Subject: a few problems with pf In-Reply-To: <482AEE64.8020209@radel.com> References: <63902.217.41.34.61.1210768578.squirrel@www.violetlan.net> <482AEE64.8020209@radel.com> Message-ID: <58644.217.41.34.61.1210777821.squirrel@www.violetlan.net> On Wed, May 14, 2008 14:51, Jon Radel wrote: > Reinhold wrote: > > >> >> What I've also noticed is that in pf I have this rule >> pass in log quick on $ext_if1 reply-to ($ext_if1 $ext_gw1) proto tcp >> from any to { 192.168.1.2 } port = 22 keep state (max 1024, max-src-conn >> 15, >> max-src-conn-rate 2/1, overload flush global) >> >> When I'm getting the bad header thingy this rule doesn't work properly. >> It >> let all the traffic trough but it never blocks the bad guys. > > Which bad guys are you expecting to block? I just checked a couple > day's worth of logs and the fastest rate at which somebody was trying to > brute force my ssh server was 1 attempt every 2 seconds. Your rule won't > trigger until 2 attempts every 1 second or faster, and I don't think those > other limits are likely to get triggered either unless you see a lot more > "bad guys" than I do on random addresses. I find that > max-src-conn-rate 3/10 tends to cut off the more energetic ones. > > --Jon Radel > > I have almost the same rule on one of my 6.3 systems with 2/1 set and yesterday it cough 6 bad guys and today 2. I've made the change as you recommended. I actually was looking at a ssh attempt earlier this week and it was connecting at about 3 to 4 per second. From m.pagulayan at auckland.ac.nz Wed May 14 22:46:47 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Wed May 14 22:46:52 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules Message-ID: Hi Guys, OS: FreeBSD 7.0-RELEASE Please correct me if I am wrong that PF 4.1 in FreeBSD 7.0 automatically inserts 'Flags S/SA' to rules? The problem is that when it comes to this rule: pass in quick on $int_if after loading to pf pass in quick on em0 flags S/SA keep state The way I see this is that this rule would be applied to udp traffic as well which will be dropped/blocked because flags only work for tcp and this might be the cause of state-mismatches that I see in the table - state-mismatch 11577272 48.7/s How can we prevent pf from loading the flags S/SA in the rules automatically? Also what is the effect of this on the block rule? 'block in log on $ext_if all' 'block return out log on $ext_if all' Cheers, Mark From tom at uffner.com Wed May 14 23:34:52 2008 From: tom at uffner.com (Tom Uffner) Date: Wed May 14 23:34:57 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: Message-ID: <482B7701.4020901@uffner.com> Mark Pagulayan wrote: > OS: FreeBSD 7.0-RELEASE > > Please correct me if I am wrong that PF 4.1 in FreeBSD 7.0 automatically > inserts 'Flags S/SA' to rules? this is correct. > The problem is that when it comes to this rule: > > pass in quick on $int_if > > after loading to pf > > pass in quick on em0 flags S/SA keep state > > The way I see this is that this rule would be applied to udp traffic as > well which will be dropped/blocked because flags only work for tcp and > this might be the cause of state-mismatches that I see in the table - > > state-mismatch 11577272 48.7/s you are misinterpreting. Pf just does the right thing in most cases. your rule "pass in quick on $int_if" is actually interpreted as the following 3 rules: pass in quick on em0 proto tcp flags S/SA keep state pass in quick on em0 proto udp keep state pass in quick on em0 prote icmp keep state > > How can we prevent pf from loading the flags S/SA in the rules > automatically? add the phrase "flags any". you must also add "no state" now if you do not want stateful filtering for some reason. > Also what is the effect of this on the block rule? > > 'block in log on $ext_if all' > 'block return out log on $ext_if all' you shouldn't have to worry about it. in almost all cases pf will do what you mean with that. tom From kian.mohageri at gmail.com Wed May 14 23:40:57 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Wed May 14 23:41:01 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: Message-ID: On Wed, May 14, 2008 at 3:45 PM, Mark Pagulayan wrote: > Hi Guys, > > > > OS: FreeBSD 7.0-RELEASE > > > > Please correct me if I am wrong that PF 4.1 in FreeBSD 7.0 automatically > inserts 'Flags S/SA' to rules? > > It does... actually 'flags S/SA keep state'. > > The problem is that when it comes to this rule: > > > > pass in quick on $int_if > > > > after loading to pf > > > > pass in quick on em0 flags S/SA keep state > > > > The way I see this is that this rule would be applied to udp traffic as > well which will be dropped/blocked because flags only work for tcp and > this might be the cause of state-mismatches that I see in the table - > 'flags S/SA keep state' will work OK for UDP too. Only the 'keep state' part will be applied to UDP, since no flags are involved. > state-mismatch 11577272 48.7/s > Could be caused by reloading your ruleset to include 'keep state' mid-connections, I think. PF won't be aware of where the state is (especially true if you're using TCP window scaling), so it will fail after a while and you'll see state mismatches. > > > > > How can we prevent pf from loading the flags S/SA in the rules > automatically? > Use 'no state' after the rule if it's necessary. But keep in mind stateful tracking is faster. E.g.: pass in on $ext_if no state > > > Also what is the effect of this on the block rule? > > > > 'block in log on $ext_if all' > > 'block return out log on $ext_if all' > > Not sure what you mean, but read pf.conf(5) man page. -Kian From tom at uffner.com Wed May 14 23:55:27 2008 From: tom at uffner.com (Tom Uffner) Date: Wed May 14 23:55:32 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: Message-ID: <482B7BE6.9080608@uffner.com> Kian Mohageri wrote: > On Wed, May 14, 2008 at 3:45 PM, Mark Pagulayan >> The way I see this is that this rule would be applied to udp traffic as >> well which will be dropped/blocked because flags only work for tcp and >> this might be the cause of state-mismatches that I see in the table - > > 'flags S/SA keep state' will work OK for UDP too. Only the 'keep > state' part will be applied to UDP, since no flags are involved. > >> state-mismatch 11577272 48.7/s > > Could be caused by reloading your ruleset to include 'keep state' > mid-connections, I think. PF won't be aware of where the state is > (especially true if you're using TCP window scaling), so it will fail > after a while and you'll see state mismatches. even if reloading the ruleset to include "keep state" and/or "flags s/sa" didn't sever pre-existing connections, it shouldn't cause that large a number of mismatches. when was the last time you zeroed the statistics? is the mismatch count still increasing w/ the 7.0 stateful rules? you may need to add "log (all)" to find out where the state mismatches are coming from. From m.pagulayan at auckland.ac.nz Thu May 15 00:09:37 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Thu May 15 00:09:41 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: <482B7BE6.9080608@uffner.com> References: <482B7BE6.9080608@uffner.com> Message-ID: Hi Tom, I have just zeroed in the statistics and yes the state-mismatch is still increasing. If I do enable logging, how would I know that packet is mismatched? Cheers, Mark -----Original Message----- From: Tom Uffner [mailto:tom@uffner.com] Sent: Thursday, 15 May 2008 11:55 a.m. To: Kian Mohageri Cc: Mark Pagulayan; freebsd-pf@freebsd.org Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules Kian Mohageri wrote: > On Wed, May 14, 2008 at 3:45 PM, Mark Pagulayan >> The way I see this is that this rule would be applied to udp traffic as >> well which will be dropped/blocked because flags only work for tcp and >> this might be the cause of state-mismatches that I see in the table - > > 'flags S/SA keep state' will work OK for UDP too. Only the 'keep > state' part will be applied to UDP, since no flags are involved. > >> state-mismatch 11577272 48.7/s > > Could be caused by reloading your ruleset to include 'keep state' > mid-connections, I think. PF won't be aware of where the state is > (especially true if you're using TCP window scaling), so it will fail > after a while and you'll see state mismatches. even if reloading the ruleset to include "keep state" and/or "flags s/sa" didn't sever pre-existing connections, it shouldn't cause that large a number of mismatches. when was the last time you zeroed the statistics? is the mismatch count still increasing w/ the 7.0 stateful rules? you may need to add "log (all)" to find out where the state mismatches are coming from. From jille at quis.cx Thu May 15 00:16:25 2008 From: jille at quis.cx (Jille) Date: Thu May 15 00:16:29 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: <482B7BE6.9080608@uffner.com> Message-ID: <482B80D3.4010701@quis.cx> Hello, Mark Pagulayan schreef: > Hi Tom, > > I have just zeroed in the statistics and yes the state-mismatch is still > increasing. > > If I do enable logging, how would I know that packet is mismatched? > If you use tcpdump, the standard flags will also show what rule it matched, so if it is an 'pass all' rule, it mismatched your other rule. -- Jille > Cheers, > > Mark > -----Original Message----- > From: Tom Uffner [mailto:tom@uffner.com] > Sent: Thursday, 15 May 2008 11:55 a.m. > To: Kian Mohageri > Cc: Mark Pagulayan; freebsd-pf@freebsd.org > Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules > > Kian Mohageri wrote: > >> On Wed, May 14, 2008 at 3:45 PM, Mark Pagulayan >> >>> The way I see this is that this rule would be applied to udp traffic >>> > as > >>> well which will be dropped/blocked because flags only work for tcp >>> > and > >>> this might be the cause of state-mismatches that I see in the table - >>> >> 'flags S/SA keep state' will work OK for UDP too. Only the 'keep >> state' part will be applied to UDP, since no flags are involved. >> >> >>> state-mismatch 11577272 48.7/s >>> >> Could be caused by reloading your ruleset to include 'keep state' >> mid-connections, I think. PF won't be aware of where the state is >> (especially true if you're using TCP window scaling), so it will fail >> after a while and you'll see state mismatches. >> > > even if reloading the ruleset to include "keep state" and/or "flags > s/sa" > didn't sever pre-existing connections, it shouldn't cause that large a > number of mismatches. > > when was the last time you zeroed the statistics? is the mismatch count > still increasing w/ the 7.0 stateful rules? you may need to add "log > (all)" > to find out where the state mismatches are coming from. > _______________________________________________ > 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 m.pagulayan at auckland.ac.nz Thu May 15 00:29:33 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Thu May 15 00:29:38 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: <482B80D3.4010701@quis.cx> References: <482B7BE6.9080608@uffner.com> <482B80D3.4010701@quis.cx> Message-ID: Hi Jill, I am using bridge pf: I only allow pass all on my internal interface. So there is no other rule for that interface. How do I know that states are mismatched for both internal and external? Cheers, Mark -----Original Message----- From: Jille [mailto:jille@quis.cx] Sent: Thursday, 15 May 2008 12:16 p.m. To: Mark Pagulayan Cc: Tom Uffner; Kian Mohageri; freebsd-pf@freebsd.org Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules Hello, Mark Pagulayan schreef: > Hi Tom, > > I have just zeroed in the statistics and yes the state-mismatch is still > increasing. > > If I do enable logging, how would I know that packet is mismatched? > If you use tcpdump, the standard flags will also show what rule it matched, so if it is an 'pass all' rule, it mismatched your other rule. -- Jille > Cheers, > > Mark > -----Original Message----- > From: Tom Uffner [mailto:tom@uffner.com] > Sent: Thursday, 15 May 2008 11:55 a.m. > To: Kian Mohageri > Cc: Mark Pagulayan; freebsd-pf@freebsd.org > Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules > > Kian Mohageri wrote: > >> On Wed, May 14, 2008 at 3:45 PM, Mark Pagulayan >> >>> The way I see this is that this rule would be applied to udp traffic >>> > as > >>> well which will be dropped/blocked because flags only work for tcp >>> > and > >>> this might be the cause of state-mismatches that I see in the table - >>> >> 'flags S/SA keep state' will work OK for UDP too. Only the 'keep >> state' part will be applied to UDP, since no flags are involved. >> >> >>> state-mismatch 11577272 48.7/s >>> >> Could be caused by reloading your ruleset to include 'keep state' >> mid-connections, I think. PF won't be aware of where the state is >> (especially true if you're using TCP window scaling), so it will fail >> after a while and you'll see state mismatches. >> > > even if reloading the ruleset to include "keep state" and/or "flags > s/sa" > didn't sever pre-existing connections, it shouldn't cause that large a > number of mismatches. > > when was the last time you zeroed the statistics? is the mismatch count > still increasing w/ the 7.0 stateful rules? you may need to add "log > (all)" > to find out where the state mismatches are coming from. > _______________________________________________ > 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 tom at uffner.com Thu May 15 01:25:44 2008 From: tom at uffner.com (Tom Uffner) Date: Thu May 15 01:25:49 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: <482B7BE6.9080608@uffner.com> <482B80D3.4010701@quis.cx> Message-ID: <482B9117.9070800@uffner.com> Mark Pagulayan wrote: > I am using bridge pf: > > I only allow pass all on my internal interface. So there is no other > rule for that interface. How do I know that states are mismatched for > both internal and external? could you post your full ruleset and a quick description of your net topology? then maybe someone can identify the most likely sources of your state mismatches. From m.pagulayan at auckland.ac.nz Thu May 15 02:54:13 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Thu May 15 02:54:17 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: <482B9117.9070800@uffner.com> References: <482B7BE6.9080608@uffner.com><482B80D3.4010701@quis.cx> <482B9117.9070800@uffner.com> Message-ID: Hi, Sorry guys if somehow the information I post in this thread is incomplete. We are using PF from FreeBSD 7.0 and using the rules we used from openbsd 4.0 PF. With the help of Jeremy chadwick, I found out that modulate state is broken in FreeBSD PF so I replaced all rules that uses modulate state to use keep state. PF runs in bridge mode where one end connects to the Border Router(connected to the internet) and the other end to a Core Switch(connected to the University network). Basically with do a layer 2 firewall with PF. Unfortunately I can't post all of my rules/attach, But I could for some. Would this be helpful? ======================================================================== === set limit states 150000 set timeout tcp.first 120 set timeout tcp.established 86400 set timeout { adaptive.start 90000, adaptive.end 250000} ext_if = "em1" int_if = "em0" set loginterface $ext_if wireless_allowed_tcp = "{515}" blocked_udp = "{7, 67, 68, 69, 111, 134><140, 199, 445, 512, 513, 520, 1993, 2049, 1900, 5000}" blocked_tcp_in = "{7, 11, 15, 67, 68, 87, 111, 134><140, 144, 199, 445, 511><516, 1025, 1993, 1900, 2049, 2766, 5000, 5999><6100}" blocked_tcp_out = "{7, 11, 15, 67, 68, 87, 111, 134><140, 144, 199, 445, 511><516, 1993, 1900, 2049, 2766, 5000, 6000}" scrub in on $ext_if altq on $ext_if cbq bandwidth 200Mb queue { default, unlimited, sponsored, premium, proxy, standard } altq on $int_if cbq bandwidth 800Mb queue { default, unlimited, sponsored, premium, proxy, standard } queue default on $ext_if bandwidth 67% cbq(default) queue default on $int_if bandwidth 67% cbq(default) queue unlimited on $ext_if bandwidth 15% cbq(borrow ecn) queue unlimited on $int_if bandwidth 15% cbq(borrow ecn) queue sponsored on $ext_if bandwidth 9% cbq(borrow ecn) queue sponsored on $int_if bandwidth 9% cbq(borrow ecn) queue premium on $ext_if bandwidth 7% cbq(borrow ecn) queue premium on $int_if bandwidth 7% cbq(borrow ecn) queue standard on $ext_if bandwidth 2% priority 4 cbq(red) queue standard on $int_if bandwidth 2% priority 4 cbq(red) pass in log quick on $int_if pass out log quick on $int_if block in log on $ext_if all block return out log on $ext_if all pass quick on $ext_if proto ospf pass quick on $ext_if proto igmp allow-opts pass quick on $ext_if proto pim allow-opts pass in quick on $ext_if proto udp from any to 224.0.0.0/4 allow-opts keep state pass in quick on $ext_if from any to 224.0.0.0/4 allow-opts keep state pass in quick log on $ext_if from to any keep state pass out quick log on $ext_if from any to keep state pass in quick on $ext_if from any to flags S/SA keep state pass out quick on $ext_if from to any keep state pass out on $ext_if inet proto icmp all icmp-type echoreq keep state pass in on $ext_if inet proto icmp from any to icmp-type echoreq keep state pass in quick on $ext_if proto tcp from to any port $wireless_allowed_tcp block in quick log on $ext_if proto udp from any to any port $blocked_udp block out quick log on $ext_if proto udp from any to any port $blocked_udp block in quick log on $ext_if proto tcp from any to any port $blocked_tcp_in block out quick log on $ext_if proto tcp from any to any port $blocked_tcp_out pass in quick on $ext_if proto tcp from any to {, } port=25 flags S/SA keep state pass out quick on $ext_if proto tcp from {, } to any port=25 keep state pass out quick on $ext_if proto tcp from to any port=53 keep state pass out quick on $ext_if proto udp from to any port=53 keep state pass in quick on $ext_if from any to flags S/SA keep state pass out quick on $ext_if from to any keep state block out quick log on $ext_if proto tcp from any to any port=53 block out quick log on $ext_if proto udp from any to any port=53 block in log quick on $ext_if proto tcp from any to any port=25 block out quick log on $ext_if proto tcp from any to any port=25 block out quick on $ext_if from to any pass out quick on $ext_if from to any keep state pass out quick on $ext_if from to any keep state queue unlimited pass out quick on $ext_if from to any keep state queue sponsored pass out quick on $ext_if from to any keep state queue premium pass out quick on $ext_if from to any keep state queue standard pass in quick on $ext_if from any to flags S/SA keep state ======================================================================== ==== And checking on the state-mismatch [mpag016@fw3 /home/mpag016]# sudo pfctl -si | grep state-mis state-mismatch 12179 3.9/s Also, I want to understand the value that "pfctl -si" command outputs, can someone point me in the right direction? Cheers, Mark -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Tom Uffner Sent: Thursday, 15 May 2008 1:26 p.m. To: freebsd-pf@freebsd.org Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules Mark Pagulayan wrote: > I am using bridge pf: > > I only allow pass all on my internal interface. So there is no other > rule for that interface. How do I know that states are mismatched for > both internal and external? could you post your full ruleset and a quick description of your net topology? then maybe someone can identify the most likely sources of your state mismatches. _______________________________________________ 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 tom at uffner.com Thu May 15 17:18:45 2008 From: tom at uffner.com (Tom Uffner) Date: Thu May 15 17:18:50 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: <482B7BE6.9080608@uffner.com><482B80D3.4010701@quis.cx> <482B9117.9070800@uffner.com> Message-ID: <482C7056.7010809@uffner.com> Mark Pagulayan wrote: > We are using PF from FreeBSD 7.0 and using the rules we used from > openbsd 4.0 PF. With the help of Jeremy chadwick, I found out that > modulate state is broken in FreeBSD PF so I replaced all rules that uses > modulate state to use keep state. FreeBSD 7.0 uses PF 4.1 so a number of your rules could be expressed more compactly and a few of them were redundant even w/ pf 4.0. > PF runs in bridge mode where one end connects to the Border > Router(connected to the internet) and the other end to a Core > Switch(connected to the University network). Basically with do a layer 2 > firewall with PF. i assume you didn't change the default sysctl "net.link.bridge.pfil_member: 1" > Unfortunately I can't post all of my rules/attach, But I could for some. > Would this be helpful? not asking you to give up any sensitive / proprietary information. but obviously we can't help w/ what you don't tell us... > ======================================================================== i don't see any really obvious sources of state mismatches in the rules you have posted. as i said though, many of them could be expressed more concisely. PF will assume stuff like "to any", "from any", and now in FreeBSD 7.0 (PF 4.1) "keep state [flags S/SA]" is implicit in any filter rules that don't unset it. > set limit states 150000 > set timeout tcp.first 120 > set timeout tcp.established 86400 > set timeout { adaptive.start 90000, adaptive.end 250000} # is there a "set skip on {lo0, bridge0}" in here somewhere # or did you set net.link.bridge.pfil_bridge = 0 > ext_if = "em1" > int_if = "em0" > > set loginterface $ext_if > wireless_allowed_tcp = "{515}" > blocked_udp = "{7, 67, 68, 69, 111, 134><140, 199, 445, 512, 513, 520, > 1993, 2049, 1900, 5000}" > blocked_tcp_in = "{7, 11, 15, 67, 68, 87, 111, 134><140, 144, 199, > 445, 511><516, 1025, 1993, 1900, 2049, 2766, 5000, 5999><6100}" > blocked_tcp_out = "{7, 11, 15, 67, 68, 87, 111, 134><140, 144, 199, > 445, 511><516, 1993, 1900, 2049, 2766, 5000, 6000}" > > scrub in on $ext_if > > altq on $ext_if cbq bandwidth 200Mb queue { default, unlimited, > sponsored, premium, proxy, standard } > altq on $int_if cbq bandwidth 800Mb queue { default, unlimited, > sponsored, premium, proxy, standard } > queue default on $ext_if bandwidth 67% cbq(default) > queue default on $int_if bandwidth 67% cbq(default) > queue unlimited on $ext_if bandwidth 15% cbq(borrow ecn) > queue unlimited on $int_if bandwidth 15% cbq(borrow ecn) > queue sponsored on $ext_if bandwidth 9% cbq(borrow ecn) > queue sponsored on $int_if bandwidth 9% cbq(borrow ecn) > queue premium on $ext_if bandwidth 7% cbq(borrow ecn) > queue premium on $int_if bandwidth 7% cbq(borrow ecn) > queue standard on $ext_if bandwidth 2% priority 4 cbq(red) > queue standard on $int_if bandwidth 2% priority 4 cbq(red) > pass in log quick on $int_if > pass out log quick on $int_if pass log quick on $int_if > block in log on $ext_if all > block return out log on $ext_if all > > pass quick on $ext_if proto ospf > pass quick on $ext_if proto igmp allow-opts > pass quick on $ext_if proto pim allow-opts > pass in quick on $ext_if proto udp from any to 224.0.0.0/4 allow-opts > keep state > pass in quick on $ext_if from any to 224.0.0.0/4 allow-opts keep state # redundant unless you want to tag, log, route or queue packets differently pass in quick on $ext_if to 224.0.0.0/4 allow-opts > pass in quick log on $ext_if from to any keep state > pass out quick log on $ext_if from any to keep state pass in quick log on $ext_if from pass out quick log on $ext_if to > pass in quick on $ext_if from any to flags S/SA keep state > pass out quick on $ext_if from to any keep state pass in quick on $ext_if to pass out quick on $ext_if from > pass out on $ext_if inet proto icmp all icmp-type echoreq keep state > pass in on $ext_if inet proto icmp from any to icmp-type > echoreq keep state pass out on $ext_if inet proto icmp icmp-type echoreq pass in on $ext_if inet proto icmp to icmp-type echoreq > pass in quick on $ext_if proto tcp from to any port > $wireless_allowed_tcp > > block in quick log on $ext_if proto udp from any to any port > $blocked_udp > block out quick log on $ext_if proto udp from any to any port > $blocked_udp # redundant block quick log on $ext_if proto udp to any port $blocked_udp > block in quick log on $ext_if proto tcp from any to any port > $blocked_tcp_in > block out quick log on $ext_if proto tcp from any to any port > $blocked_tcp_out block in quick log on $ext_if proto tcp to any port $blocked_tcp_in block out quick log on $ext_if proto tcp to any port $blocked_tcp_out > pass in quick on $ext_if proto tcp from any to {, > } port=25 flags S/SA keep state > pass out quick on $ext_if proto tcp from {, } to > any port=25 keep state pass in quick on $ext_if proto tcp to {, } port=25 pass out quick on $ext_if proto tcp from {, } to any port=25 > pass out quick on $ext_if proto tcp from to any port=53 > keep state > pass out quick on $ext_if proto udp from to any port=53 > keep state pass out quick on $ext_if proto tcp from to any port=53 pass out quick on $ext_if proto udp from to any port=53 > pass in quick on $ext_if from any to flags S/SA keep state > pass out quick on $ext_if from to any keep state pass in quick on $ext_if to pass out quick on $ext_if from > block out quick log on $ext_if proto tcp from any to any port=53 > block out quick log on $ext_if proto udp from any to any port=53 # redundant block quick log on $ext_if to any port=53 > block in log quick on $ext_if proto tcp from any to any port=25 > block out quick log on $ext_if proto tcp from any to any port=25 # redundant block log quick on $ext_if proto tcp to any port=25 > block out quick on $ext_if from to any > pass out quick on $ext_if from to any keep state > pass out quick on $ext_if from to any keep state queue > unlimited > pass out quick on $ext_if from to any keep state queue > sponsored > pass out quick on $ext_if from to any keep state queue > premium > pass out quick on $ext_if from to any keep state queue > standard > pass in quick on $ext_if from any to flags S/SA keep state block out quick on $ext_if from pass out quick on $ext_if from pass out quick on $ext_if from queue unlimited pass out quick on $ext_if from queue sponsored pass out quick on $ext_if from queue premium pass out quick on $ext_if from queue standard pass in quick on $ext_if to > ======================================================================== > And checking on the state-mismatch > > [mpag016@fw3 /home/mpag016]# sudo pfctl -si | grep state-mis > state-mismatch 12179 3.9/s > > Also, I want to understand the value that "pfctl -si" command outputs, > can someone point me in the right direction? they are counts of various filter/state related actions or events since the firewall was started (or since they were last zeroed). i den't know of anywhere it is documented in detail, but most of the items should make sense after reading pf.conf and having an idea of all the things pf can do. you can probably figure out which rules cause the state-mismatches by setting misc debugging "pfctl -xm" and watching the syslog for messages like: kernel: pf: loose state match: ... or kernel: pf: BAD state: ... kernel: pf: State failure on: | From m.pagulayan at auckland.ac.nz Thu May 15 23:27:28 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Thu May 15 23:27:31 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: <482C7056.7010809@uffner.com> References: <482B7BE6.9080608@uffner.com><482B80D3.4010701@quis.cx> <482B9117.9070800@uffner.com> <482C7056.7010809@uffner.com> Message-ID: Hi Tom, Yes I am using net.link.bridge.pfil_member: 1. What is the effect of this on the bridge interface. No there is no such rules below in my ruleset # is there a "set skip on {lo0, bridge0}" in here somewhere Is PF by default doing a filter on bridge0? What is the effect of this rule on the bridge? Thanks for the suggestion on the ruleset. It is much appreciated. Cheers, Mark -----Original Message----- From: Tom Uffner [mailto:tom@uffner.com] Sent: Friday, 16 May 2008 5:18 a.m. To: Mark Pagulayan Cc: freebsd-pf@freebsd.org Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules Mark Pagulayan wrote: > We are using PF from FreeBSD 7.0 and using the rules we used from > openbsd 4.0 PF. With the help of Jeremy chadwick, I found out that > modulate state is broken in FreeBSD PF so I replaced all rules that uses > modulate state to use keep state. FreeBSD 7.0 uses PF 4.1 so a number of your rules could be expressed more compactly and a few of them were redundant even w/ pf 4.0. > PF runs in bridge mode where one end connects to the Border > Router(connected to the internet) and the other end to a Core > Switch(connected to the University network). Basically with do a layer 2 > firewall with PF. i assume you didn't change the default sysctl "net.link.bridge.pfil_member: 1" > Unfortunately I can't post all of my rules/attach, But I could for some. > Would this be helpful? not asking you to give up any sensitive / proprietary information. but obviously we can't help w/ what you don't tell us... > ======================================================================== i don't see any really obvious sources of state mismatches in the rules you have posted. as i said though, many of them could be expressed more concisely. PF will assume stuff like "to any", "from any", and now in FreeBSD 7.0 (PF 4.1) "keep state [flags S/SA]" is implicit in any filter rules that don't unset it. > set limit states 150000 > set timeout tcp.first 120 > set timeout tcp.established 86400 > set timeout { adaptive.start 90000, adaptive.end 250000} # is there a "set skip on {lo0, bridge0}" in here somewhere # or did you set net.link.bridge.pfil_bridge = 0 > ext_if = "em1" > int_if = "em0" > > set loginterface $ext_if > wireless_allowed_tcp = "{515}" > blocked_udp = "{7, 67, 68, 69, 111, 134><140, 199, 445, 512, 513, 520, > 1993, 2049, 1900, 5000}" > blocked_tcp_in = "{7, 11, 15, 67, 68, 87, 111, 134><140, 144, 199, > 445, 511><516, 1025, 1993, 1900, 2049, 2766, 5000, 5999><6100}" > blocked_tcp_out = "{7, 11, 15, 67, 68, 87, 111, 134><140, 144, 199, > 445, 511><516, 1993, 1900, 2049, 2766, 5000, 6000}" > > scrub in on $ext_if > > altq on $ext_if cbq bandwidth 200Mb queue { default, unlimited, > sponsored, premium, proxy, standard } > altq on $int_if cbq bandwidth 800Mb queue { default, unlimited, > sponsored, premium, proxy, standard } > queue default on $ext_if bandwidth 67% cbq(default) > queue default on $int_if bandwidth 67% cbq(default) > queue unlimited on $ext_if bandwidth 15% cbq(borrow ecn) > queue unlimited on $int_if bandwidth 15% cbq(borrow ecn) > queue sponsored on $ext_if bandwidth 9% cbq(borrow ecn) > queue sponsored on $int_if bandwidth 9% cbq(borrow ecn) > queue premium on $ext_if bandwidth 7% cbq(borrow ecn) > queue premium on $int_if bandwidth 7% cbq(borrow ecn) > queue standard on $ext_if bandwidth 2% priority 4 cbq(red) > queue standard on $int_if bandwidth 2% priority 4 cbq(red) > pass in log quick on $int_if > pass out log quick on $int_if pass log quick on $int_if > block in log on $ext_if all > block return out log on $ext_if all > > pass quick on $ext_if proto ospf > pass quick on $ext_if proto igmp allow-opts > pass quick on $ext_if proto pim allow-opts > pass in quick on $ext_if proto udp from any to 224.0.0.0/4 allow-opts > keep state > pass in quick on $ext_if from any to 224.0.0.0/4 allow-opts keep state # redundant unless you want to tag, log, route or queue packets differently pass in quick on $ext_if to 224.0.0.0/4 allow-opts > pass in quick log on $ext_if from to any keep state > pass out quick log on $ext_if from any to keep state pass in quick log on $ext_if from pass out quick log on $ext_if to > pass in quick on $ext_if from any to flags S/SA keep state > pass out quick on $ext_if from to any keep state pass in quick on $ext_if to pass out quick on $ext_if from > pass out on $ext_if inet proto icmp all icmp-type echoreq keep state > pass in on $ext_if inet proto icmp from any to icmp-type > echoreq keep state pass out on $ext_if inet proto icmp icmp-type echoreq pass in on $ext_if inet proto icmp to icmp-type echoreq > pass in quick on $ext_if proto tcp from to any port > $wireless_allowed_tcp > > block in quick log on $ext_if proto udp from any to any port > $blocked_udp > block out quick log on $ext_if proto udp from any to any port > $blocked_udp # redundant block quick log on $ext_if proto udp to any port $blocked_udp > block in quick log on $ext_if proto tcp from any to any port > $blocked_tcp_in > block out quick log on $ext_if proto tcp from any to any port > $blocked_tcp_out block in quick log on $ext_if proto tcp to any port $blocked_tcp_in block out quick log on $ext_if proto tcp to any port $blocked_tcp_out > pass in quick on $ext_if proto tcp from any to {, > } port=25 flags S/SA keep state > pass out quick on $ext_if proto tcp from {, } to > any port=25 keep state pass in quick on $ext_if proto tcp to {, } port=25 pass out quick on $ext_if proto tcp from {, } to any port=25 > pass out quick on $ext_if proto tcp from to any port=53 > keep state > pass out quick on $ext_if proto udp from to any port=53 > keep state pass out quick on $ext_if proto tcp from to any port=53 pass out quick on $ext_if proto udp from to any port=53 > pass in quick on $ext_if from any to flags S/SA keep state > pass out quick on $ext_if from to any keep state pass in quick on $ext_if to pass out quick on $ext_if from > block out quick log on $ext_if proto tcp from any to any port=53 > block out quick log on $ext_if proto udp from any to any port=53 # redundant block quick log on $ext_if to any port=53 > block in log quick on $ext_if proto tcp from any to any port=25 > block out quick log on $ext_if proto tcp from any to any port=25 # redundant block log quick on $ext_if proto tcp to any port=25 > block out quick on $ext_if from to any > pass out quick on $ext_if from to any keep state > pass out quick on $ext_if from to any keep state queue > unlimited > pass out quick on $ext_if from to any keep state queue > sponsored > pass out quick on $ext_if from to any keep state queue > premium > pass out quick on $ext_if from to any keep state queue > standard > pass in quick on $ext_if from any to flags S/SA keep state block out quick on $ext_if from pass out quick on $ext_if from pass out quick on $ext_if from queue unlimited pass out quick on $ext_if from queue sponsored pass out quick on $ext_if from queue premium pass out quick on $ext_if from queue standard pass in quick on $ext_if to > ======================================================================== > And checking on the state-mismatch > > [mpag016@fw3 /home/mpag016]# sudo pfctl -si | grep state-mis > state-mismatch 12179 3.9/s > > Also, I want to understand the value that "pfctl -si" command outputs, > can someone point me in the right direction? they are counts of various filter/state related actions or events since the firewall was started (or since they were last zeroed). i den't know of anywhere it is documented in detail, but most of the items should make sense after reading pf.conf and having an idea of all the things pf can do. you can probably figure out which rules cause the state-mismatches by setting misc debugging "pfctl -xm" and watching the syslog for messages like: kernel: pf: loose state match: ... or kernel: pf: BAD state: ... kernel: pf: State failure on: | From tom at uffner.com Fri May 16 01:16:37 2008 From: tom at uffner.com (Tom Uffner) Date: Fri May 16 01:16:40 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: References: <482B7BE6.9080608@uffner.com><482B80D3.4010701@quis.cx> <482B9117.9070800@uffner.com> <482C7056.7010809@uffner.com> Message-ID: <482CE06D.7070800@uffner.com> Mark Pagulayan wrote: > Yes I am using net.link.bridge.pfil_member: 1. What is the effect of > this on the bridge interface. see if_bridge(4) for full details. in short they control whether or not filtering is available on the member interfaces and/or the bridge. net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.pfil_onlyip: 1 > No there is no such rules below in my ruleset > # is there a "set skip on {lo0, bridge0}" in here somewhere > > Is PF by default doing a filter on bridge0? What is the effect of this > rule on the bridge? i realized too late that you don't need one. i expected to see such a rule due to my style of ruleset writing. i usually start w/ "block log all" to disable the default pass rule on all interfaces, then explicitly allow only the traffic i want. you didn't, so the default for interfaces you don't have any rules for is pass all. "set skip on X" has the same effect as a rule that says "pass quick on X" From m.pagulayan at auckland.ac.nz Fri May 16 02:19:49 2008 From: m.pagulayan at auckland.ac.nz (Mark Pagulayan) Date: Fri May 16 02:19:54 2008 Subject: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules In-Reply-To: <482CE06D.7070800@uffner.com> References: <482B7BE6.9080608@uffner.com><482B80D3.4010701@quis.cx> <482B9117.9070800@uffner.com> <482C7056.7010809@uffner.com> <482CE06D.7070800@uffner.com> Message-ID: Hi Tom, Thanks heaps for the advice I will review and reorganize our ruleset. Cheers, Mark -----Original Message----- From: Tom Uffner [mailto:tom@uffner.com] Sent: Friday, 16 May 2008 1:16 p.m. To: Mark Pagulayan Cc: freebsd-pf@freebsd.org Subject: Re: FreeBSD PF 4.1 Inserts Flags S/SA Automatically to rules Mark Pagulayan wrote: > Yes I am using net.link.bridge.pfil_member: 1. What is the effect of > this on the bridge interface. see if_bridge(4) for full details. in short they control whether or not filtering is available on the member interfaces and/or the bridge. net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.pfil_onlyip: 1 > No there is no such rules below in my ruleset > # is there a "set skip on {lo0, bridge0}" in here somewhere > > Is PF by default doing a filter on bridge0? What is the effect of this > rule on the bridge? i realized too late that you don't need one. i expected to see such a rule due to my style of ruleset writing. i usually start w/ "block log all" to disable the default pass rule on all interfaces, then explicitly allow only the traffic i want. you didn't, so the default for interfaces you don't have any rules for is pass all. "set skip on X" has the same effect as a rule that says "pass quick on X" From johan at stromnet.se Sat May 17 16:18:56 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sat May 17 16:19:01 2008 Subject: connect(): Operation not permitted In-Reply-To: <1211037564.6326.27.camel@porksoda> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> Message-ID: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> First of all, for freebsd-pf subscribers, I posted my original problem (in the bottom) to freebsd-net earlier, but replies seems to point to PF so I'll CC there too.. On May 17, 2008, at 5:19 PM, Alex Trull wrote: > Hi Johan and List, > > In my case a few months ago it was pahu. Don't give that fine fellow > an > account on your precious system ! > > > But seriously, I had a pf-firewalled jail being being used for DNS > testing, with large numbers of udp "connections" hanging around in pf > state. While the default udp timeout settings in PF are lower than > those > of the tcp timeouts, it is was still too high for it to to remove the > states in time before hitting the default 10k state limit! > > If this is the case with you - run 'pfctl -s state | wc -l' - when > there > is traffic load you may see that hitting 10k states if you've not > tuned > that variable. > > What to do next - up the state limit or lower the state timeouts. I > did > both, to be safe. > > in /etc/pf.conf these must be at the very top of the file: > > # options > # 10k is insanely low, lets raise it.. > set limit { frags 16384, states 32768 } > # timeouts - see 'pfctl -s timeouts' for options - you will want to > # change the tcp ones rather than the udp ones for your smtp setup. > # but these are mine, I set them for the dns traffic. > set timeout { udp.first 15, udp.single 5, udp.multiple 30 } > > > don't forget to: > > $ /etc/rc.d/pf check && /etc/rc.d/pf reload Ok, looked over the PF states now, but I'm not quite sure thats what causing it. I have default limit on 10k states, normally I seem to have around ~800 states, and when I start my test script that tries to send as many mails as possible (using PHP's Pear::Mail, creating a connection, sending, disconnecting, creating new connection.. and so on), I can clearly see the PF state counter (pfctl -vsi) increase, but the script aborts with Operation not permitted way before I hit 10k, its rather around 3-4k.. If I then wait a few seconds and run the script again, I can see the number of states increase even more, and if I do this enough times I finally hit around 9700 states. But at this point (states exhausted), I don't get Operation not permitted, instead it just seems that the script blocks up a few seconds while states clear up, then continues running until it gets a Operation not permitted. So, from the above results, I cant say that it looks like its the states? Just tried to disable the altq rule now too, no changes (not that I expected one, since its on bce0 not lo0). Another thing, which might be more approriate in freebsd-pf though.. Why would it create states at all for this traffic, when my pf.conf rule is "pass on lo0 inet from $jail to $jail" (i have a block drop in rule to drop all traffic)? A check with pfctl -vsr reveals that the actual rule inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags S/SA keep state". Where did that "keep state" come from? Thanks for ideas :) > > > HTH, > > Alex > > On Sat, 2008-05-17 at 16:33 +0200, Johan Str?m wrote: >> Hello >> >> I got a FreeBSD 7 machine running mail services (among other things). >> This machine recently replaced a FreeBSD 6.2 machine doing the same >> tasks. >> Now and then I need to send alot of mail to customers (mailing list), >> and one thing i've noticed now after the change is that when I use a >> lot of connections subsequently (high connection rate, even if they >> are very shortlived) inside a jail (dunno if that has anything to do >> with it though), I start to get Operation not permitted in return to >> connect(). >> I've seen this in the PHP app that sends mail, when it tried to >> connect to localhost, as well as from postfix when it have been >> trying >> to connect to amavisd on localhost, but also from postfix when it has >> tried to connect to remote SMTP servers. >> >> I do have PF for filtering, but there are no max-src-conn-rate limits >> enabled for any rules that is used for this. However, from one of the >> jail I do have a hfsc queue limiting the outgoing mail traffic from >> one jailed IP. But I'm not sure that this would be the problem, since >> I've also seen the problem when doing localhost connects in the jail, >> and also in other jails on an entierly different IP that is not >> affected. >> >> Does anyone have any clues about what I can look at and tune to fix >> this? >> >> Thanks! >> >> -- >> Johan Str?m >> Stromnet >> johan@stromnet.se >> http://www.stromnet.se/ >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org >> " From m.seaman at infracaninophile.co.uk Sun May 18 07:19:37 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sun May 18 07:19:43 2008 Subject: connect(): Operation not permitted In-Reply-To: <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> Message-ID: <482FD877.6050707@infracaninophile.co.uk> Johan Str?m wrote: > drop all traffic)? A check with pfctl -vsr reveals that the actual rule > inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 > flags S/SA keep state". Where did that "keep state" come from? 'flags S/SA keep state' is the default now for tcp filter rules -- that was new in 7.0 reflecting the upstream changes made between the 4.0 and 4.1 releases of OpenBSD. If you want a stateless rule, append 'no state'. http://www.openbsd.org/faq/pf/filter.html#state Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080518/3ba12348/signature.pgp From johan at stromnet.se Sun May 18 10:33:58 2008 From: johan at stromnet.se (=?ISO-8859-1?Q?Johan_Str=F6m?=) Date: Sun May 18 10:34:09 2008 Subject: connect(): Operation not permitted In-Reply-To: <482FD877.6050707@infracaninophile.co.uk> References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > Johan Str?m wrote: > >> drop all traffic)? A check with pfctl -vsr reveals that the actual >> rule inserted is "pass on lo0 inet from 123.123.123.123 to >> 123.123.123.123 flags S/SA keep state". Where did that "keep state" >> come from? > > 'flags S/SA keep state' is the default now for tcp filter rules -- > that > was new in 7.0 reflecting the upstream changes made between the 4.0 > and 4.1 > releases of OpenBSD. If you want a stateless rule, append 'no state'. > > http://www.openbsd.org/faq/pf/filter.html#state Thanks! I was actually looking around in the pf.conf manpage but failed to find it yesterday, but looking closer today I now saw it. Applied the no state (and quick) to the rule, and now no state is created. And the problem I had in the first place seems to have been resolved too now, even though it didn't look like a state problem.. (started to deny new connections much earlier than the states was full, altough maybee i wasnt looking for updates fast enough or something). Anyways, thanks to all helping me out, and of course thanks to everybody involved in FreeBSD/pf and all for great products! Cannot be said enough times ;) From vwe at FreeBSD.org Sun May 18 16:59:45 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun May 18 16:59:47 2008 Subject: kern/123726: [panic] [altq] page fault after ppp restart and pf resync Message-ID: <200805181659.m4IGxisL085246@freefall.freebsd.org> Old Synopsis: page fault after ppp restart and pf resync New Synopsis: [panic] [altq] page fault after ppp restart and pf resync Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: vwe Responsible-Changed-When: Sun May 18 16:57:03 UTC 2008 Responsible-Changed-Why: altq is Max' territory - reassign also please note, this PR is a slightly different DUP to similar PRs (problem is caused by altq when interfaces disappear) http://www.freebsd.org/cgi/query-pr.cgi?pr=123726 From kian.mohageri at gmail.com Sun May 18 17:29:21 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Sun May 18 17:29:24 2008 Subject: connect(): Operation not permitted In-Reply-To: References: <678A03F5-5E8A-4CF6-90DF-AA9A4F30FBE1@stromnet.se> <1211037564.6326.27.camel@porksoda> <679DB462-75D6-45CC-949C-1BE8E12C22CD@stromnet.se> <482FD877.6050707@infracaninophile.co.uk> Message-ID: On Sun, May 18, 2008 at 3:33 AM, Johan Str?m wrote: > On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: > >> Johan Str?m wrote: >> >>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >>> S/SA keep state". Where did that "keep state" come from? >> >> 'flags S/SA keep state' is the default now for tcp filter rules -- that >> was new in 7.0 reflecting the upstream changes made between the 4.0 and >> 4.1 >> releases of OpenBSD. If you want a stateless rule, append 'no state'. >> >> http://www.openbsd.org/faq/pf/filter.html#state > > Thanks! I was actually looking around in the pf.conf manpage but failed to > find it yesterday, but looking closer today I now saw it. > Applied the no state (and quick) to the rule, and now no state is created. > And the problem I had in the first place seems to have been resolved too > now, even though it didn't look like a state problem.. (started to deny new > connections much earlier than the states was full, altough maybee i wasnt > looking for updates fast enough or something). > I'd be willing to bet it's because you're reusing the source port on a new connection before the old state expires. You'll know if you check the state-mismatch counter. Anyway, glad you found a resolution. -Kian From max at love2party.net Sun May 18 23:30:04 2008 From: max at love2party.net (Max Laier) Date: Sun May 18 23:30:07 2008 Subject: kern/123726: [panic] [altq] page fault after ppp restart and pf resync Message-ID: <200805182330.m4INU3i4018970@freefall.freebsd.org> The following reply was made to PR kern/123726; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, justinjereza@gmail.com Cc: Subject: Re: kern/123726: [panic] [altq] page fault after ppp restart and pf resync Date: Mon, 19 May 2008 01:22:21 +0200 There is patch for this here: http://people.freebsd.org/~mlaier/pf.dyn_altq.R7.diff It's been committed to RELENG_7, too. I'm not sure it warrents for a errata commit to RELENG_7_0, though. -- Max From linimon at FreeBSD.org Sun May 18 23:42:59 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun May 18 23:43:01 2008 Subject: kern/123726: [panic] [altq] page fault after ppp restart and pf resync Message-ID: <200805182342.m4INgwIF021415@freefall.freebsd.org> Synopsis: [panic] [altq] page fault after ppp restart and pf resync State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Sun May 18 23:42:07 UTC 2008 State-Changed-Why: Already committed to RELENG_7; may need merge to RELENG_6. http://www.freebsd.org/cgi/query-pr.cgi?pr=123726 From linimon at FreeBSD.org Sun May 18 23:46:18 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun May 18 23:46:20 2008 Subject: kern/123726: [panic] [altq] page fault after ppp restart and pf resync Message-ID: <200805182346.m4INkIso021486@freefall.freebsd.org> Synopsis: [panic] [altq] page fault after ppp restart and pf resync Responsible-Changed-From-To: freebsd-pf->mlaier Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 18 23:43:02 UTC 2008 Responsible-Changed-Why: Over to committer of the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=123726 From linimon at FreeBSD.org Mon May 19 00:08:51 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 19 00:08:53 2008 Subject: kern/78090: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Message-ID: <200805190008.m4J08ogu022866@freefall.freebsd.org> Synopsis: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 19 00:08:42 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=78090 From linimon at FreeBSD.org Mon May 19 00:09:56 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 19 00:10:00 2008 Subject: kern/102344: [ipf] Some packets do not pass through network interface Message-ID: <200805190009.m4J09uIm022948@freefall.freebsd.org> Synopsis: [ipf] Some packets do not pass through network interface Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 19 00:09:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=102344 From kian.mohageri at gmail.com Mon May 19 03:38:21 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Mon May 19 03:38:24 2008 Subject: Filtering CARP interface(s) and 'set skip on lo0' Message-ID: Hey all, I'm trying to clean up my PF rulesets, and I noticed today that a CARP master connecting to itself (on the CARP IP address) appears to be filtered even when 'set skip on lo0' is in effect. At first I suspected that maybe CARP Master to itself is routed differently in FreeBSD (so it wouldn't actually be on lo0), but a tcpdump seems to say otherwise. That is: > ifconfig carp0 carp0: flags=49 metric 0 mtu 1500 inet 67.201.255.210 netmask 0xffffffe0 carp: MASTER vhid 1 advbase 1 advskew 10 > sudo tcpdump -c 3 -n -i lo0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes 20:36:40.522108 IP 67.201.255.210.65404 > 67.201.255.210.53: 2673+ A? daapiak-mtv.flux.com. (38) 20:36:40.522569 IP 67.201.255.210.53 > 67.201.255.210.65404: 2673 4/9/3 CNAME[|domain] 20:36:40.724506 IP 67.201.255.210.65404 > 67.201.255.210.53: 20823+ PTR? 240.189.73.209. I tried the archives but couldn't find an explanation about why 'set skip on lo0' wouldn't apply here, so I'm wondering if any of you could point me in the right direction. The simple answer would be for me to simply filter a little differently so the MASTER can talk to itself, but I figured this could be a learning experience too. Is this intended FreeBSD-specific behavior, and if so, what is the recommended way to deal with it? Thanks for any pointers, Kian From max at love2party.net Mon May 19 09:11:28 2008 From: max at love2party.net (Max Laier) Date: Mon May 19 09:11:36 2008 Subject: Filtering CARP interface(s) and 'set skip on lo0' In-Reply-To: References: Message-ID: <200805191111.18113.max@love2party.net> On Monday 19 May 2008 05:38:20 Kian Mohageri wrote: > Hey all, > > I'm trying to clean up my PF rulesets, and I noticed today that a CARP > master connecting to itself (on the CARP IP address) appears to be > filtered even when 'set skip on lo0' is in effect. > > At first I suspected that maybe CARP Master to itself is routed > differently in FreeBSD (so it wouldn't actually be on lo0), but a > > tcpdump seems to say otherwise. That is: > > ifconfig carp0 > > carp0: flags=49 metric 0 mtu 1500 > inet 67.201.255.210 netmask 0xffffffe0 > carp: MASTER vhid 1 advbase 1 advskew 10 > > > sudo tcpdump -c 3 -n -i lo0 > > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode listening on lo0, link-type NULL (BSD loopback), capture size 96 > bytes 20:36:40.522108 IP 67.201.255.210.65404 > 67.201.255.210.53: > 2673+ A? daapiak-mtv.flux.com. (38) > 20:36:40.522569 IP 67.201.255.210.53 > 67.201.255.210.65404: 2673 > 4/9/3 CNAME[|domain] > 20:36:40.724506 IP 67.201.255.210.65404 > 67.201.255.210.53: 20823+ > PTR? 240.189.73.209. Just because the packets show up on lo0 "sometime" doesn't mean that they won't pass through other interfaces before or after. CARP is special in that respect and needs special attention. > I tried the archives but couldn't find an explanation about why 'set > skip on lo0' wouldn't apply here, so I'm wondering if any of you could > point me in the right direction. The simple answer would be for me to > simply filter a little differently so the MASTER can talk to itself, > but I figured this could be a learning experience too. > > Is this intended FreeBSD-specific behavior, and if so, what is the > recommended way to deal with it? The usual advise on how to debug rulesets that block stuff you want to allow: 1) Add "log" to all block rules 2) Listen on pflog0 3) Generate the traffic pattern you want to pass 4) Find this offending rule (and also the interface and direction the traffic was blocked on) 5) Insert a rule to allow the traffic in question 6) Repeat until everything works as required -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From mlaier at FreeBSD.org Mon May 19 09:14:33 2008 From: mlaier at FreeBSD.org (mlaier@FreeBSD.org) Date: Mon May 19 09:14:36 2008 Subject: kern/78090: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Message-ID: <200805190914.m4J9EXq8000504@freefall.freebsd.org> Synopsis: [ipf] ipf filtering on bridged packets doesn't work if ipfw is loaded Responsible-Changed-From-To: freebsd-pf->freebsd-net Responsible-Changed-By: mlaier Responsible-Changed-When: Mon May 19 09:12:31 UTC 2008 Responsible-Changed-Why: This is not a pf problem. Also note that the old bridge implementation, to which this PR relates to, is obsolete by if_bridge(4) and likely no longer maintained. Over to freebsd-net in case somebody is still interested. http://www.freebsd.org/cgi/query-pr.cgi?pr=78090 From mlaier at FreeBSD.org Mon May 19 09:17:11 2008 From: mlaier at FreeBSD.org (mlaier@FreeBSD.org) Date: Mon May 19 09:17:14 2008 Subject: kern/102344: [ipf] Some packets do not pass through network interface Message-ID: <200805190917.m4J9HAMx000563@freefall.freebsd.org> Synopsis: [ipf] Some packets do not pass through network interface State-Changed-From-To: open->feedback State-Changed-By: mlaier State-Changed-When: Mon May 19 09:15:26 UTC 2008 State-Changed-Why: The submitter has been asked for configuration details over a year ago. Responsible-Changed-From-To: freebsd-pf->freebsd-net Responsible-Changed-By: mlaier Responsible-Changed-When: Mon May 19 09:15:26 UTC 2008 Responsible-Changed-Why: Not a pf problem. Reassign to freebsd-net. http://www.freebsd.org/cgi/query-pr.cgi?pr=102344 From bugmaster at FreeBSD.org Mon May 19 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 19 11:07:45 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200805191106.m4JB6vf3011667@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/116610 pf [patch] teach tcpdump(1) to cope with the new-style pf o kern/120281 pf [request] lost returning packets to PF for a rdr rule o kern/122014 pf [panic] FreeBSD 6.2 panic in pf 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf tagged parameter on nat not working on FreeBSD 5.2 o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c f kern/116645 pf [request] pfctl -k does not work in securelevel 3 o kern/118355 pf [pf] [patch] pfctl help message options order false -t o kern/120057 pf [patch] Allow proper settings of ALTQ_HFSC. The check o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to 10 problems total. From kian.mohageri at gmail.com Mon May 19 14:27:10 2008 From: kian.mohageri at gmail.com (Kian Mohageri) Date: Mon May 19 14:27:15 2008 Subject: Filtering CARP interface(s) and 'set skip on lo0' In-Reply-To: <200805191111.18113.max@love2party.net> References: <200805191111.18113.max@love2party.net> Message-ID: On Mon, May 19, 2008 at 2:11 AM, Max Laier wrote: > On Monday 19 May 2008 05:38:20 Kian Mohageri wrote: >> Hey all, >> >> I'm trying to clean up my PF rulesets, and I noticed today that a CARP >> master connecting to itself (on the CARP IP address) appears to be >> filtered even when 'set skip on lo0' is in effect. >> >> At first I suspected that maybe CARP Master to itself is routed >> differently in FreeBSD (so it wouldn't actually be on lo0), but a >> >> tcpdump seems to say otherwise. That is: >> > ifconfig carp0 >> >> carp0: flags=49 metric 0 mtu 1500 >> inet 67.201.255.210 netmask 0xffffffe0 >> carp: MASTER vhid 1 advbase 1 advskew 10 >> >> > sudo tcpdump -c 3 -n -i lo0 >> >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode listening on lo0, link-type NULL (BSD loopback), capture size 96 >> bytes 20:36:40.522108 IP 67.201.255.210.65404 > 67.201.255.210.53: >> 2673+ A? daapiak-mtv.flux.com. (38) >> 20:36:40.522569 IP 67.201.255.210.53 > 67.201.255.210.65404: 2673 >> 4/9/3 CNAME[|domain] >> 20:36:40.724506 IP 67.201.255.210.65404 > 67.201.255.210.53: 20823+ >> PTR? 240.189.73.209. > > Just because the packets show up on lo0 "sometime" doesn't mean that they > won't pass through other interfaces before or after. CARP is special in > that respect and needs special attention. > Does it pass through the CARP interface or does PF just think so? Tcpdump on carp0 doesn't show anything, and tcpdump on a CARP interface that's in "backup" only shows the advertisements of the master, which is why I am/was confused. -Kian PS: Thank you for updating pf in 7.0! From linimon at FreeBSD.org Mon May 19 18:02:34 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 19 18:02:37 2008 Subject: kern/116645: [request] pfctl -k does not work in securelevel 3 Message-ID: <200805191802.m4JI2YLA050955@freefall.freebsd.org> Synopsis: [request] pfctl -k does not work in securelevel 3 State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Mon May 19 18:02:09 UTC 2008 State-Changed-Why: Feedback indicates that this behavior is by design; no one has stepped up to disagree, so far. http://www.freebsd.org/cgi/query-pr.cgi?pr=116645 From cbredi at bofhserver.net Tue May 20 15:55:55 2008 From: cbredi at bofhserver.net (Cristian Bradiceanu) Date: Tue May 20 15:56:00 2008 Subject: pf reply-to tcp connections stall Message-ID: <2f12f40a0805200830l7836d640s69c55af837d475d9@mail.gmail.com> Hello, I am trying to set up split routing on two Internet links, each with one IP address: em0 = wan1, $em0_gw gateway em1 = lan, NATed on em0 and em2 em2 = wan2, default gateway pass in on em0 reply-to (em0 $em0_gw) inet proto tcp from any to em0 flags S/SA keep state pass in on em0 reply-to (em0 $em0_gw) inet proto udp from any to em0 keep state pass in on em0 reply-to (em0 $em0_gw) inet proto icmp from any to em0 keep state wan2 connections are working correct, no pf rules for policy routing wan1 tcp connections to IP of em0 (e.g. ssh) stall when a large amount of data is sent (e.g. running dmesg or cat file). States are created correctly. When ssh stalls there are some icmp packets out on lo0 with source and destination ip address of em0, which I believe is not correct (set skip on lo0 does not help). Also tried with tcp ... modulate state but same result. If I change default gateway to $em0_gw and disable pf all connections on wan1 are ok. I also tried to use route-to instead of reply-to with: pass out on em2 route-to (em0 $em0_gw) from em0 to any both with keep state and no state options - same ssh connection stall. System is FreeBSD 7.0-STABLE amd64. Kind regards, Cristian From koitsu at FreeBSD.org Tue May 20 16:20:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue May 20 16:20:33 2008 Subject: pf reply-to tcp connections stall In-Reply-To: <2f12f40a0805200830l7836d640s69c55af837d475d9@mail.gmail.com> References: <2f12f40a0805200830l7836d640s69c55af837d475d9@mail.gmail.com> Message-ID: <20080520162029.GA41273@eos.sc1.parodius.com> On Tue, May 20, 2008 at 06:30:58PM +0300, Cristian Bradiceanu wrote: > I am trying to set up split routing on two Internet links, each with > one IP address: > > em0 = wan1, $em0_gw gateway > em1 = lan, NATed on em0 and em2 > em2 = wan2, default gateway > > pass in on em0 reply-to (em0 $em0_gw) inet proto tcp from any to em0 flags S/SA keep state > pass in on em0 reply-to (em0 $em0_gw) inet proto udp from any to em0 keep state > pass in on em0 reply-to (em0 $em0_gw) inet proto icmp from any to em0 keep state > > wan2 connections are working correct, no pf rules for policy routing > > wan1 tcp connections to IP of em0 (e.g. ssh) stall when a large amount > of data is sent (e.g. running dmesg or cat file). States are created > correctly. When ssh stalls there are some icmp packets out on lo0 with > source and destination ip address of em0, which I believe is not > correct (set skip on lo0 does not help). Also tried with tcp ... > modulate state but same result. modulate state is known to be broken: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Regarding the "when large amounts of data is sent, the connection breaks" issue: I've reproduced this a few times on our systems (using the exact same method you do: dmesg, cat'ing large files, or scp'ing -- anything using large TCP packets), and it's always been caused by improper pf(4) rules where state was broken. In every case, the "state mismatch" counter shown in pfctl -s info would increase. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From tom at uffner.com Tue May 20 20:48:45 2008 From: tom at uffner.com (Tom Uffner) Date: Tue May 20 20:48:50 2008 Subject: /etc/pf.conf missing from 7.0 minimal install Message-ID: <4833392B.70002@uffner.com> the sample config file /etc/pf.conf is not included in the 7.0-STABLE minimal installation. was this an accidental omission, as it appears to be since the rest of the pf files including /etc/pf.os are included, or was it done by design? tom From cbredi at bofhserver.net Tue May 20 20:49:56 2008 From: cbredi at bofhserver.net (Cristian Bradiceanu) Date: Tue May 20 20:50:00 2008 Subject: pf reply-to tcp connections stall In-Reply-To: <20080520162029.GA41273@eos.sc1.parodius.com> References: <2f12f40a0805200830l7836d640s69c55af837d475d9@mail.gmail.com> <20080520162029.GA41273@eos.sc1.parodius.com> Message-ID: <2f12f40a0805201349g6ee6be5cxa6f2a029b5150bec@mail.gmail.com> On Tue, May 20, 2008 at 7:20 PM, Jeremy Chadwick wrote: > On Tue, May 20, 2008 at 06:30:58PM +0300, Cristian Bradiceanu wrote: >> I am trying to set up split routing on two Internet links, each with >> one IP address: >> >> em0 = wan1, $em0_gw gateway >> em1 = lan, NATed on em0 and em2 >> em2 = wan2, default gateway >> >> pass in on em0 reply-to (em0 $em0_gw) inet proto tcp from any to em0 flags S/SA keep state >> pass in on em0 reply-to (em0 $em0_gw) inet proto udp from any to em0 keep state >> pass in on em0 reply-to (em0 $em0_gw) inet proto icmp from any to em0 keep state >> >> wan2 connections are working correct, no pf rules for policy routing >> >> wan1 tcp connections to IP of em0 (e.g. ssh) stall when a large amount >> of data is sent (e.g. running dmesg or cat file). States are created >> correctly. When ssh stalls there are some icmp packets out on lo0 with >> source and destination ip address of em0, which I believe is not >> correct (set skip on lo0 does not help). Also tried with tcp ... >> modulate state but same result. > > modulate state is known to be broken: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Regarding the "when large amounts of data is sent, the connection > breaks" issue: > > I've reproduced this a few times on our systems (using the exact same > method you do: dmesg, cat'ing large files, or scp'ing -- anything using > large TCP packets), and it's always been caused by improper pf(4) rules > where state was broken. In every case, the "state mismatch" counter > shown in pfctl -s info would increase. state-mismatch counter does not increase, all "Counters" are 0 except match (pfctl -si). When large amounts of data is sent the connection stalls and continues from time to time very slow; when it continues there are logged icmp packets out on lo0 from (em0) to (em0) which looks pretty weird to me. Cristian From reinhard.haller at interactive-net.de Tue May 20 21:09:24 2008 From: reinhard.haller at interactive-net.de (Reinhard Haller) Date: Tue May 20 21:09:27 2008 Subject: NAT problem with pppoe Message-ID: <48333B05.9090203@interactive-net.de> Hi, I suspect pf is caching invalid outdated dynamic addresses. After this happens, all requests sent from internal hosts are sent with the previous dynamic address as source address and are ignored by our provider. Requests sent directly from our pf-box use the new dynamic address as expected. /etc/pf.conf ext_if="tun0" external_net="!192.168.0.0/16" nat on $ext_if from !($ext_if) -> ($ext_if) anchor portupgrade out on $ext_if pass out on $ext_if from ($ext_if) to $external_net tagged FORWARD pass quick proto { tcp, udp } from $dns_server to port domain tag FORWARD the anchor portupgrade is filled with the ppp-linkup script (DNS0/1) pass quick inet proto udp from (tun0) to 212.18.3.5 port = domain keep state Sending HUP to ppp does'nt eliminate the problem, pfctl -d/-e and a restart of the internal server solve it. The pf-box uses freebsd 7.0 stable, usermode-ppp is used to connect with the provider. Any suggestions? Thanks Reinhard From stefan.lambrev at moneybookers.com Tue May 20 21:11:28 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue May 20 21:11:31 2008 Subject: /etc/pf.conf missing from 7.0 minimal install In-Reply-To: <4833392B.70002@uffner.com> References: <4833392B.70002@uffner.com> Message-ID: <48333A91.2030308@moneybookers.com> Tom Uffner wrote: > the sample config file /etc/pf.conf is not included in the 7.0-STABLE > minimal installation. > > was this an accidental omission, as it appears to be since the rest > of the pf files including /etc/pf.os are included, or was it done by > design? I think it was moved in /usr/share/examples/etc/ because mergemaster can override it incidentally ... which is not the case with other pf.XX files :) > > tom > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From brix at FreeBSD.org Tue May 20 21:43:21 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Tue May 20 21:43:29 2008 Subject: /etc/pf.conf missing from 7.0 minimal install In-Reply-To: <4833392B.70002@uffner.com> References: <4833392B.70002@uffner.com> Message-ID: <20080520212446.GB20926@tirith.brixandersen.dk> On Tue, May 20, 2008 at 04:48:43PM -0400, Tom Uffner wrote: > the sample config file /etc/pf.conf is not included in the 7.0-STABLE > minimal installation. > > was this an accidental omission, as it appears to be since the rest > of the pf files including /etc/pf.os are included, or was it done by > design? By design. It was moved to /usr/share/examples/pf/pf.conf Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080520/119514c5/attachment.pgp From dudu at dudu.ro Tue May 20 22:52:09 2008 From: dudu at dudu.ro (Vlad GALU) Date: Tue May 20 22:52:13 2008 Subject: pf reply-to tcp connections stall In-Reply-To: <2f12f40a0805201349g6ee6be5cxa6f2a029b5150bec@mail.gmail.com> References: <2f12f40a0805200830l7836d640s69c55af837d475d9@mail.gmail.com> <20080520162029.GA41273@eos.sc1.parodius.com> <2f12f40a0805201349g6ee6be5cxa6f2a029b5150bec@mail.gmail.com> Message-ID: On 5/20/08, Cristian Bradiceanu wrote: > On Tue, May 20, 2008 at 7:20 PM, Jeremy Chadwick wrote: > > On Tue, May 20, 2008 at 06:30:58PM +0300, Cristian Bradiceanu wrote: > >> I am trying to set up split routing on two Internet links, each with > >> one IP address: > >> > >> em0 = wan1, $em0_gw gateway > >> em1 = lan, NATed on em0 and em2 > >> em2 = wan2, default gateway > >> > >> pass in on em0 reply-to (em0 $em0_gw) inet proto tcp from any to em0 flags S/SA keep state > >> pass in on em0 reply-to (em0 $em0_gw) inet proto udp from any to em0 keep state > >> pass in on em0 reply-to (em0 $em0_gw) inet proto icmp from any to em0 keep state > >> > >> wan2 connections are working correct, no pf rules for policy routing > >> > >> wan1 tcp connections to IP of em0 (e.g. ssh) stall when a large amount > >> of data is sent (e.g. running dmesg or cat file). States are created > >> correctly. When ssh stalls there are some icmp packets out on lo0 with > >> source and destination ip address of em0, which I believe is not > >> correct (set skip on lo0 does not help). Also tried with tcp ... > >> modulate state but same result. > > > > modulate state is known to be broken: > > > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > > > Regarding the "when large amounts of data is sent, the connection > > breaks" issue: > > > > I've reproduced this a few times on our systems (using the exact same > > method you do: dmesg, cat'ing large files, or scp'ing -- anything using > > large TCP packets), and it's always been caused by improper pf(4) rules > > where state was broken. In every case, the "state mismatch" counter > > shown in pfctl -s info would increase. > > > state-mismatch counter does not increase, all "Counters" are 0 except > match (pfctl -si). When large amounts of data is sent the connection > stalls and continues from time to time very slow; when it continues > there are logged icmp packets out on lo0 from (em0) to (em0) which > looks pretty weird to me. > > > Cristian This may be a PMTUD issue. Make sure your ICMP packets can travel back and forth unhindered and that there are no scrub rules that may clear out the DF flag on them. > > _______________________________________________ > 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" > -- ~/.signature: no such file or directory From jcw at highperformance.net Wed May 21 01:54:28 2008 From: jcw at highperformance.net (Jason C. Wells) Date: Wed May 21 01:54:33 2008 Subject: nat pass and state Message-ID: <48337A93.9090003@highperformance.net> I have these rules (and others) in pf.conf: nat pass on $ext_if from $int_net to any -> ($ext_if) block in all block out all I cannot connect to websites unless I also add: pass proto { tcp, udp } from any to any port http keep state My understanding is that nat rules are inherently stateful. I also understand that a packet that matches state bypasses filter rules. A hit on a web page should generate a state on the way out and then match that state on the way back in, avoiding the block rules. By testing, I show that the pass http rule is needed to complete the connection. Would someone please explain why the nat rule is not sufficient to allow me to access a web page? I must have a gross conceptual error on how PF works. This is too simple, but I just don't get it. Regards, Jason From rea-fbsd at codelabs.ru Wed May 21 04:15:08 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed May 21 04:15:15 2008 Subject: /etc/pf.conf missing from 7.0 minimal install In-Reply-To: <20080520212446.GB20926@tirith.brixandersen.dk> References: <4833392B.70002@uffner.com> <20080520212446.GB20926@tirith.brixandersen.dk> Message-ID: Tue, May 20, 2008 at 11:24:46PM +0200, Henrik Brix Andersen wrote: > On Tue, May 20, 2008 at 04:48:43PM -0400, Tom Uffner wrote: > > was this an accidental omission, as it appears to be since the rest > > of the pf files including /etc/pf.os are included, or was it done by > > design? > > By design. It was moved to /usr/share/examples/pf/pf.conf ...and substantially stipped down (synced with OpenBSD examples, as commit message says). I would say that this is a step backwards, because the old /etc/pf.conf had more options and provided a better comments. -- Eygene From koitsu at FreeBSD.org Wed May 21 04:28:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed May 21 04:28:46 2008 Subject: nat pass and state In-Reply-To: <48337A93.9090003@highperformance.net> References: <48337A93.9090003@highperformance.net> Message-ID: <20080521042841.GA69249@eos.sc1.parodius.com> On Tue, May 20, 2008 at 06:27:47PM -0700, Jason C. Wells wrote: > I have these rules (and others) in pf.conf: > > nat pass on $ext_if from $int_net to any -> ($ext_if) > > block in all > block out all > > I cannot connect to websites unless I also add: > > pass proto { tcp, udp } from any to any port http keep state > > My understanding is that nat rules are inherently stateful. I also > understand that a packet that matches state bypasses filter rules. A hit > on a web page should generate a state on the way out and then match that > state on the way back in, avoiding the block rules. By testing, I show > that the pass http rule is needed to complete the connection. > > Would someone please explain why the nat rule is not sufficient to allow me > to access a web page? I must have a gross conceptual error on how PF > works. This is too simple, but I just don't get it. I believe it's because pf(4) doesn't make assumptions about what you want to filter. NAT is stateful (it has to be, because packets are being re-written, and the WAN-side port numbers are going to be different than the LAN-side), but filtering rules still apply **after** the translation has been done. What's happening is that your nat rule results in pf re-writing the packet, then the packet is immediately blocked by one of your block rules (I'm assuming "block out"). The pf.conf manpage documents this, more or less: Since translation occurs before filtering the filter engine will see packets as they look after any addresses and ports have been translated. Filter rules will therefore have to filter based on the translated address and port number. Packets that match a translation rule are only automatically passed if the pass modifier is given, otherwise they are still subject to block and pass rules. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jcw at highperformance.net Wed May 21 05:03:36 2008 From: jcw at highperformance.net (Jason C. Wells) Date: Wed May 21 05:03:42 2008 Subject: nat pass and state In-Reply-To: <20080521042841.GA69249@eos.sc1.parodius.com> References: <48337A93.9090003@highperformance.net> <20080521042841.GA69249@eos.sc1.parodius.com> Message-ID: <4833AD24.1040105@highperformance.net> Jeremy Chadwick wrote: > I believe it's because pf(4) doesn't make assumptions about what you > want to filter. NAT is stateful (it has to be, because packets are > being re-written, and the WAN-side port numbers are going to be > different than the LAN-side), but filtering rules still apply **after** > the translation has been done. > > What's happening is that your nat rule results in pf re-writing the > packet, then the packet is immediately blocked by one of your block > rules (I'm assuming "block out"). > > The pf.conf manpage documents this, more or less: > > Since translation occurs before filtering the filter engine will see > packets as they look after any addresses and ports have been translated. > Filter rules will therefore have to filter based on the translated > address and port number. Packets that match a translation rule are only > automatically passed if the pass modifier is given, otherwise they are > still subject to block and pass rules. I guess my misunderstanding comes in where the pass modifier is concerned. I also have a weak understand of what "state" actually means. The "automatically passsed" part of your citation isn't automatically passing. I think I'll just drop the pass modifier on the NAT rule. Then it becomes precisely clear to me that I need a filter rule after the nat rule. Regards, Jason From koitsu at FreeBSD.org Wed May 21 05:12:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed May 21 05:12:56 2008 Subject: nat pass and state In-Reply-To: <4833AD24.1040105@highperformance.net> References: <48337A93.9090003@highperformance.net> <20080521042841.GA69249@eos.sc1.parodius.com> <4833AD24.1040105@highperformance.net> Message-ID: <20080521051252.GA70840@eos.sc1.parodius.com> On Tue, May 20, 2008 at 10:03:32PM -0700, Jason C. Wells wrote: > Jeremy Chadwick wrote: > >> I believe it's because pf(4) doesn't make assumptions about what you >> want to filter. NAT is stateful (it has to be, because packets are >> being re-written, and the WAN-side port numbers are going to be >> different than the LAN-side), but filtering rules still apply **after** >> the translation has been done. >> >> What's happening is that your nat rule results in pf re-writing the >> packet, then the packet is immediately blocked by one of your block >> rules (I'm assuming "block out"). >> >> The pf.conf manpage documents this, more or less: >> >> Since translation occurs before filtering the filter engine will see >> packets as they look after any addresses and ports have been translated. >> Filter rules will therefore have to filter based on the translated >> address and port number. Packets that match a translation rule are only >> automatically passed if the pass modifier is given, otherwise they are >> still subject to block and pass rules. > > I guess my misunderstanding comes in where the pass modifier is concerned. > I also have a weak understand of what "state" actually means. The > "automatically passsed" part of your citation isn't automatically passing. Oh! I'm sorry, I missed the "pass" word that was in your nat rule. I don't ultimately know what that does internally to pf. There does not appear to be any actual documentation on what the "pass" entry in a nat rule actually does. This sounds like it could be a bug; even the pf examples in /usr/share/examples/pf don't use "pass" in a nat rule. I'll leave the bug comment up to the pf experts here to analyse, though. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From fox at verio.net Wed May 21 08:38:48 2008 From: fox at verio.net (David DeSimone) Date: Wed May 21 08:38:52 2008 Subject: nat pass and state In-Reply-To: <48337A93.9090003@highperformance.net> References: <48337A93.9090003@highperformance.net> Message-ID: <20080521083846.GB5072@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason C. Wells wrote: > > Would someone please explain why the nat rule is not sufficient to > allow me to access a web page? I must have a gross conceptual error > on how PF works. This is too simple, but I just don't get it. The first packet arrives on $int_if and is blocked by "block in all". It never has a chance to route to $ext_if, and thus never matches the nat rule. The "nat pass" does not apply because the initial packet is not arriving on $ext_if so it can't match the rule (yet). You have to allow the connection in on $int_if first, then when it routes out $ext_if it will match the nat rule and set up state. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIM9+WFSrKRjX5eCoRAjWPAJ9+rZ6aqUVEEiRulw+nQD2swM84QACcDE5e x0MSmBXcgbFqPmUkjRIAO60= =bzw3 -----END PGP SIGNATURE----- From fox at verio.net Wed May 21 08:40:01 2008 From: fox at verio.net (David DeSimone) Date: Wed May 21 08:40:06 2008 Subject: NAT problem with pppoe In-Reply-To: <48333B05.9090203@interactive-net.de> References: <48333B05.9090203@interactive-net.de> Message-ID: <20080521084000.GC5072@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinhard Haller wrote: > > Sending HUP to ppp does'nt eliminate the problem, pfctl -d/-e and a > restart of the internal server solve it. I suggest that your ppp "if_down" script make use of the "pfctl -k" command to kill state entries that have to do with the IP that is being removed. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIM9/gFSrKRjX5eCoRAjHFAJ9cP5HofxhWmLNKSdJu24bAKdEtXACffMr7 fxdCGLjx8AhS4NVw8foXUqY= =FD6I -----END PGP SIGNATURE----- From cbredi at bofhserver.net Wed May 21 13:19:18 2008 From: cbredi at bofhserver.net (Cristian Bradiceanu) Date: Wed May 21 13:19:22 2008 Subject: pf reply-to tcp connections stall In-Reply-To: References: <2f12f40a0805200830l7836d640s69c55af837d475d9@mail.gmail.com> <20080520162029.GA41273@eos.sc1.parodius.com> <2f12f40a0805201349g6ee6be5cxa6f2a029b5150bec@mail.gmail.com> Message-ID: <2f12f40a0805210619t4aae9fa0w43737b2098f7d042@mail.gmail.com> On Wed, May 21, 2008 at 1:27 AM, Vlad GALU wrote: > On 5/20/08, Cristian Bradiceanu wrote: >> On Tue, May 20, 2008 at 7:20 PM, Jeremy Chadwick wrote: >> > On Tue, May 20, 2008 at 06:30:58PM +0300, Cristian Bradiceanu wrote: >> >> I am trying to set up split routing on two Internet links, each with >> >> one IP address: >> >> >> >> em0 = wan1, $em0_gw gateway >> >> em1 = lan, NATed on em0 and em2 >> >> em2 = wan2, default gateway >> >> >> >> pass in on em0 reply-to (em0 $em0_gw) inet proto tcp from any to em0 flags S/SA keep state >> >> pass in on em0 reply-to (em0 $em0_gw) inet proto udp from any to em0 keep state >> >> pass in on em0 reply-to (em0 $em0_gw) inet proto icmp from any to em0 keep state >> >> >> >> wan2 connections are working correct, no pf rules for policy routing >> >> >> >> wan1 tcp connections to IP of em0 (e.g. ssh) stall when a large amount >> >> of data is sent (e.g. running dmesg or cat file). States are created >> >> correctly. When ssh stalls there are some icmp packets out on lo0 with >> >> source and destination ip address of em0, which I believe is not >> >> correct (set skip on lo0 does not help). Also tried with tcp ... >> >> modulate state but same result. >> > >> > modulate state is known to be broken: >> > >> > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues >> > >> > Regarding the "when large amounts of data is sent, the connection >> > breaks" issue: >> > >> > I've reproduced this a few times on our systems (using the exact same >> > method you do: dmesg, cat'ing large files, or scp'ing -- anything using >> > large TCP packets), and it's always been caused by improper pf(4) rules >> > where state was broken. In every case, the "state mismatch" counter >> > shown in pfctl -s info would increase. >> >> >> state-mismatch counter does not increase, all "Counters" are 0 except >> match (pfctl -si). When large amounts of data is sent the connection >> stalls and continues from time to time very slow; when it continues >> there are logged icmp packets out on lo0 from (em0) to (em0) which >> looks pretty weird to me. >> >> >> Cristian > > This may be a PMTUD issue. Make sure your ICMP packets can travel > back and forth unhindered and that there are no scrub rules that may > clear out the DF flag on them. There's no no-df scrub flag, also no icmp filters. Cristian From ansarm at gmail.com Thu May 22 01:03:05 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Thu May 22 01:03:10 2008 Subject: ALTQ and bandwidth limiting Message-ID: <002d01c8bba7$96128db0$c237a910$@com> Hello All, Is there a way using PF and ALTQ that I can set a policy to restrict a particular host to a maximum network speed? I would like to simulate low speed connection using pf. From koitsu at FreeBSD.org Thu May 22 04:29:37 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu May 22 04:29:44 2008 Subject: ALTQ and bandwidth limiting In-Reply-To: <002d01c8bba7$96128db0$c237a910$@com> References: <002d01c8bba7$96128db0$c237a910$@com> Message-ID: <20080522042936.GA24418@eos.sc1.parodius.com> On Wed, May 21, 2008 at 09:02:59PM -0400, Ansar Mohammed wrote: > Hello All, > > Is there a way using PF and ALTQ that I can set a policy to restrict a > particular host to a maximum network speed? > > I would like to simulate low speed connection using pf. I believe ipfw dummynet has the capability you're looking for. See the ipfw manpage, section "TRAFFIC SHAPER". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ansarm at gmail.com Thu May 22 06:20:15 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Thu May 22 06:20:18 2008 Subject: ALTQ and bandwidth limiting In-Reply-To: <20080522042936.GA24418@eos.sc1.parodius.com> References: <002d01c8bba7$96128db0$c237a910$@com> <20080522042936.GA24418@eos.sc1.parodius.com> Message-ID: <006601c8bbd3$e3b654d0$ab22fe70$@com> Ok, I got a bit further. I compiled in ALTQ and I am using Class Based Queueing. Here is a snippet of my pf.conf altq on le1 cbq bandwidth 100Mb queue { std, cifs, http } queue std bandwidth 88.5Mb cbq(default) queue cifs bandwidth 1500Kb cbq queue http bandwidth 1Mb cbq Here is the problem, no matter what value I set for the CBQ Queue, its at least 1/4 of the actual configured maximum. So I configured http for 1Mb, the max throughput I get is 288Mb. Can anyone explain why? > -----Original Message----- > From: Jeremy Chadwick [mailto:koitsu@FreeBSD.org] > Sent: May 22, 2008 12:30 AM > To: Ansar Mohammed > Cc: freebsd-pf@freebsd.org > Subject: Re: ALTQ and bandwidth limiting > > On Wed, May 21, 2008 at 09:02:59PM -0400, Ansar Mohammed wrote: > > Hello All, > > > > Is there a way using PF and ALTQ that I can set a policy to restrict > a > > particular host to a maximum network speed? > > > > I would like to simulate low speed connection using pf. > > I believe ipfw dummynet has the capability you're looking for. See the > ipfw manpage, section "TRAFFIC SHAPER". > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | From artemrts at ukr.net Fri May 23 11:24:24 2008 From: artemrts at ukr.net (Vitaliy Vladimirovich) Date: Fri May 23 11:24:29 2008 Subject: How specify range IP? In-Reply-To: Message-ID: Hi,all! I need specify a range IP addresses in may spamd-whitelist table, e.g. 209.85.128.0-209.85.255.255. How can I do this correctly? Thanks in advance! From artemrts at ukr.net Fri May 23 13:34:13 2008 From: artemrts at ukr.net (Vitaliy Vladimirovich) Date: Fri May 23 13:34:16 2008 Subject: How specify range IP? In-Reply-To: <200805231307.m4ND7Ip1065546@lava.sentex.ca> Message-ID: --- Original Message --- From: Mike Tancsa To: "Vitaliy Vladimirovich" , freebsd-pf@freebsd.org Date: 23 may, 16:07:12 Subject: Re: How specify range IP? At 07:24 AM 5/23/2008, Vitaliy Vladimirovich wrote: >Hi,all! >I need specify a range IP addresses in may spamd-whitelist table, >e.g. 209.85.128.0-209.85.255.255. >How can I do this correctly? Hi, Try in CIDR notation. e.g. 209.85.128.0/17 I know about CIDR notation, and what about if I need specify something similary 10.0.10.1-10.0.10.8?? From mike at sentex.net Fri May 23 14:14:47 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri May 23 14:14:51 2008 Subject: How specify range IP? In-Reply-To: References: Message-ID: <200805231307.m4ND7Ip1065546@lava.sentex.ca> At 07:24 AM 5/23/2008, Vitaliy Vladimirovich wrote: >Hi,all! >I need specify a range IP addresses in may spamd-whitelist table, >e.g. 209.85.128.0-209.85.255.255. >How can I do this correctly? Hi, Try in CIDR notation. e.g. 209.85.128.0/17 ---Mike > >Thanks in advance! >_______________________________________________ >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 mike at sentex.net Fri May 23 14:20:23 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri May 23 14:20:27 2008 Subject: How specify range IP? In-Reply-To: References: <200805231307.m4ND7Ip1065546@lava.sentex.ca> Message-ID: <200805231420.m4NEKHrN065857@lava.sentex.ca> At 09:34 AM 5/23/2008, Vitaliy Vladimirovich wrote: >Hi, >Try in CIDR notation. e.g. 209.85.128.0/17 > > >I know about CIDR notation, and what about if I need specify >something similary 10.0.10.1-10.0.10.8?? I usually do it in a series of CIDR notations when it does not match normal boundaries. I know on ports you have range operators (see pf.conf) but I am not sure there is the equiv for IP addresses. Is there some reason you dont want to use CIDR notation ? in your case, (10.0.10.0/29,10.0.10.8) ---Mike From tevans.uk at googlemail.com Fri May 23 14:46:54 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri May 23 14:46:59 2008 Subject: How specify range IP? In-Reply-To: References: Message-ID: <1211552463.10665.16.camel@localhost> On Fri, 2008-05-23 at 16:34 +0300, Vitaliy Vladimirovich wrote: > > --- Original Message --- > From: Mike Tancsa > To: "Vitaliy Vladimirovich" , freebsd-pf@freebsd.org > Date: 23 may, 16:07:12 > Subject: Re: How specify range IP? > > At 07:24 AM 5/23/2008, Vitaliy Vladimirovich wrote: > > >Hi,all! > >I need specify a range IP addresses in may spamd-whitelist table, > >e.g. 209.85.128.0-209.85.255.255. > >How can I do this correctly? > > Hi, > Try in CIDR notation. e.g. 209.85.128.0/17 > I know about CIDR notation, and what about if I need specify something similary 10.0.10.1-10.0.10.8?? > 10.0.10.1 - 10.0.10.8 can't be represented as a single CIDR range, therefore you would need to specify multiple addresses to represent it in CIDR notation. It would therefore be the combination of the 4 ranges 10.0.10.1/32 10.0.10.2/31 10.0.10.4/30 10.0.10.8/32 10.0.10.0 - 10.0.10.7 can be represented as the single range 10.0.10.0/29 Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080523/e31ea262/attachment.pgp From 000.fbsd at quip.cz Fri May 23 15:03:29 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Fri May 23 15:03:36 2008 Subject: How specify range IP? In-Reply-To: References: Message-ID: <4836D872.9080804@quip.cz> Vitaliy Vladimirovich wrote: > > --- Original Message --- >>Hi,all! >>I need specify a range IP addresses in may spamd-whitelist table, >>e.g. 209.85.128.0-209.85.255.255. >>How can I do this correctly? > > > Hi, > Try in CIDR notation. e.g. 209.85.128.0/17 > I know about CIDR notation, and what about if I need specify something similary 10.0.10.1-10.0.10.8?? You can use net/tableutil from ports to convert your ranges in to CIDR. http://www.freebsd.org/cgi/url.cgi?ports/net/tableutil/pkg-descr http://expiretable.fnord.se/ Miroslav Lachman From fedex_courierbenin201 at yahoo.fr Sat May 24 01:37:36 2008 From: fedex_courierbenin201 at yahoo.fr (Barr Daniel Obiora (ESQ)) Date: Sat May 24 01:37:43 2008 Subject: ATTENTION Message-ID: <20080523154349.AD0138794E8@austin.pins-web.net> Hello Dear, I have Paid the fee for your Cheque Draft.but the manager of Eko Bankn Benin told me that before the check will get to you that it will expire.So i told him to cash $1.5M USA DOLLar all the necessary arrangement of delivering the $1.5M USA DOLLar in cash was made with FedEX DELIVERY COURIER COMPANY. This is the information they need to delivery your package to you.with FEDEX DELIVERY COURIER COMPANY, contact them now. NAME:FEDEX COURIER DELIVERING COMPANY. ATTANTION: PERSON: DR.JERRY LAWRENCE POSITION: FOREIGN DELIVERY DEPARTMENT. ADDRESS: COTONOU BENIN REPUBLIC E-MAIL:fedex_courierbenin201@yahoo.fr Phone number: PHONE NUMBER: +229 9374 0412 Please, Send them your contacts information to able them locate you immediately they arrived in your country with your BOX .This is what they need from you. 1.YOUR FULL NAME 2.YOUR HOME ADDRESS. 3.YOUR CURRENT HOME TELEPHONE NUMBER. 4.YOUR CURRENT OFFICE TELEPHONE. 5. YOUR CURRENT HOME TELEPHONE NUMBER. 6.A COPY OF YOUR PICTURE Note that this is there E-mail contact (fedex_courierbenin201@yahoo.fr) Please make sure you send this needed info's to the Director general of FEDEX DELIVERY COURIER COMPANY BENIN REPUBLIC,DR.JERRY Lawrence with the address given to you. Note. The Fedex Delivery Courier Company don't know the contents of the Box. I registered it as a Box of an African cloths. They don't know it contents money, this is to avoid them delaying with the Box.don't let them know that is money that is in that Box. Thanks and Remain Blessed. Barr Daniel Obiora (ESQ) From peter at bsdly.net Sat May 24 08:25:03 2008 From: peter at bsdly.net (Peter N. M. Hansteen) Date: Sat May 24 08:25:06 2008 Subject: How specify range IP? In-Reply-To: (Vitaliy Vladimirovich's message of "Fri, 23 May 2008 14:24:22 +0300") References: Message-ID: <87wslkt8h0.fsf@thingy.bsdly.net> "Vitaliy Vladimirovich" writes: > I need specify a range IP addresses in may spamd-whitelist table, e.g. 209.85.128.0-209.85.255.255. > How can I do this correctly? The address/netmask notation works, ie 209.85.128.0/17 -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From ighighi at gmail.com Sun May 25 08:39:54 2008 From: ighighi at gmail.com (Ighighi Ighighi) Date: Sun May 25 08:39:58 2008 Subject: blackhole in PF possible? Message-ID: blackhole(4) is hardly a feature if it applies to loopback interfaces as well. Its intended functionality ("to slow down anyone who is port scanning a system", according to the manpage) also slows down internal services because those TCP RST's and ICMP Port Unreachable's are never seen. Is there a way to get the same functionality in PF so I can restrict those packets to external interfaces ? Thanks in advance, Igh. From delphij at delphij.net Sun May 25 08:49:36 2008 From: delphij at delphij.net (Xin LI) Date: Sun May 25 08:49:38 2008 Subject: blackhole in PF possible? In-Reply-To: References: Message-ID: <4839280B.3000704@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ighighi Ighighi wrote: | blackhole(4) is hardly a feature if it applies to loopback interfaces | as well. Its intended functionality | ("to slow down anyone who is port scanning a system", according to the | manpage) also slows down | internal services because those TCP RST's and ICMP Port Unreachable's | are never seen. | | Is there a way to get the same functionality in PF so I can restrict | those packets to external interfaces ? | | Thanks in advance, skip on lo0? - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg5KAoACgkQi+vbBBjt66ArMwCdHenJHci+folJJjVjvNcajyXl MjYAoI38do4rJt9U5JG5R96nYd6vNqmA =5iuk -----END PGP SIGNATURE----- From peter at bsdly.net Sun May 25 14:07:33 2008 From: peter at bsdly.net (Peter N. M. Hansteen) Date: Sun May 25 14:07:36 2008 Subject: blackhole in PF possible? In-Reply-To: (Ighighi Ighighi's message of "Mon, 26 May 2008 03:44:19 +1930") References: Message-ID: <87r6bqqxy6.fsf@thingy.bsdly.net> "Ighighi Ighighi" writes: > Is there a way to get the same functionality in PF so I can restrict > those packets to external interfaces ? block drop in all on $ext_ifs or something like that would have some of the desired effect. not sure how much it actually buys you, but it's quite similar to blackhole. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From jamesoff at gmail.com Sun May 25 14:24:50 2008 From: jamesoff at gmail.com (James Seward) Date: Sun May 25 14:24:53 2008 Subject: blackhole in PF possible? In-Reply-To: References: Message-ID: <720051dc0805250700y54fa58b7yd63b279af177b8bb@mail.gmail.com> On Sun, May 25, 2008 at 9:14 AM, Ighighi Ighighi wrote: > blackhole(4) is hardly a feature if it applies to loopback interfaces > as well. Its intended functionality > ("to slow down anyone who is port scanning a system", according to the > manpage) also slows down > internal services because those TCP RST's and ICMP Port Unreachable's > are never seen. > > Is there a way to get the same functionality in PF so I can restrict > those packets to external interfaces ? Have a look at "set block-policy" and "block return" in the man page for pf.conf. /JMS From oleksandr at samoylyk.sumy.ua Sun May 25 18:44:26 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Sun May 25 18:44:30 2008 Subject: Strange messages in dmesg In-Reply-To: <9a542da30804161257h6d80efafqa5aec8442811c984@mail.gmail.com> References: <48065337.3080805@samoylyk.sumy.ua> <9a542da30804161257h6d80efafqa5aec8442811c984@mail.gmail.com> Message-ID: <4839B378.40005@samoylyk.sumy.ua> Ermal Lu?i wrote: > 2008/4/16 Oleksandr Samoylyk : >> Dear freebsd-pf subscribers, >> >> What can such messages from system message buffer mean? >> >> ULLpf >> _tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL N >> ULLpf_ >> tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL >> NULpLf_t >> esptf:_ tpefs_tg:e tp_fm_tgaegt _rmettaugr nreedt uNrUnLeLd N >> ULpLf_ >> tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL N >> ULLpf >> _tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL NU >> LLpf >> _tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetudr nNeUdL LN >> ULLpf >> _tepsft_:t epsft_: gpeft__gmetta_gm traegtu rrneetdu rNnUeLdL N >> ULLpf >> _tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL N >> ULLpf_ >> tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL >> NULpLf_t >> esptf:_ tpefs_tg:e tp_fm_tgaegt _rmettaugr nreedt uNrUnLeLd N >> ULpLf_t >> esptf:_ tpefs_tg:e tp_fm_tgaegt _rmettaugr nreedt uNrUnLeLd >> NULpLf_ >> tesptf:_ tpefs_tg:e tp_fm_tgaegt _rmettaugr nreedt uNrUnLeLd N >> ULpLf_ >> tesptf:_ tpefs_tg:e tp_fm_tgaegt _rmettaugr nreedt uNrUnLeLd N >> ULpLf_ >> tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL N >> ULpLf_ >> tesptf:_ tpefs_tg:e tp_fm_tgaegt _rmettaugr nreedt uNrUnLeLd N >> ULLpf >> _tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL NU >> LLp >> f_tpefs_tt:e sptf:_ gpeft__gmetta_gm traegt urrenteudr nNeUdL LNUL >> L >> pf_ptfe_stte:s tp:f _pgfe_tg_emtt_amgt arge truertnuerdn eNdU LNLULL >> >> pf_ptfe_stte:s tp:f _pgfe_tg_emtt_amgt arge truertnuerdn eNdU LNLULL >> >> pf_ptfe_stte:s tp:f _pgfe_tg_emtt_amgt arge truertnuerdn eNdU LNLULL >> >> pf_ptfe_stte:s tp:f _pgfe_tg_emtt_amtga gr erteutrunrende dNU LNLUL >> L >> pf_ptfe_stte:st :p fp_fg_egte_tm_tmatg arge truertnuerdn eNdU LNLUL >> L >> pf_ptfe_stte:s tp:f _pgfe_tg_emtt_amgt arge truertnuerdn eNdU LNLUL >> Lp >> f_ptfe_stte:s tp:f _pgfe_tg_emtt_amgt arge truertnuerdn eNdU LNLU >> LLpf >> _tpefs_tt:e sptf:_ gpeft__gmetta_gm traegt urrenteudr nNeUdL LNUL >> Lpf >> _tpefs_tt:e sptf:_ gpeft__gmetta_gm traegt urrenteudr nNeUdL LNU >> LLp >> f_tpefs_tt:e sptf:_ gpeft__gmetta_gm traegt urrenteudr nNeUdL LNUL >> Lp >> f_tpefs_tt:e sptf:_ gpeft__gmetta_gm traegt urrenteudr nNeUdL LN >> ULLpf >> _tepsft_:t epsft_:g eptf__gmetta_gm traegt urrenetdu rNnUeLdL N >> ULLpf >> >> The system is: >> > uname -a >> FreeBSD xxxx.yyyyyyy.zzz 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Apr 10 >> 13:38:24 EEST 2008 root@xxxx.yyyyyyy.zzz:/usr/obj/usr/src/sys/PF i386 >> >> Any tip-off? :) > > It is just a message telling that pf_get_mtag function could not > allocate a tag for PF and without that pf checking is skipped iirc. > > Why it happens it is not easily findable with this information. Is this also pf-related errors: May 25 20:41:01 router kernel: mUtLaLg May 25 20:41:01 router kernel: rpeft_utrensetd: NpUfL_Lge May 25 20:41:01 router kernel: t_pmft_atge srte:t uprfn_egde tN_UmLtLag May 25 20:41:01 router kernel: rpeft_utrensetd: NpUfL_Lget May 25 20:41:01 router kernel: _mptfa_gt ersett:u rpnfe_dg eNtU_LmLta May 25 20:41:01 router kernel: g prfe_ttuersnte:d pNfU_LgLet_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lm May 25 20:41:01 router kernel: tapgf _rteetsutr:n epdf _NgUeLtL_m May 25 20:41:01 router kernel: tapgf _rteetsutr:ne dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e pdf _NgUeLtL_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_m May 25 20:41:01 router kernel: tpafg_ treesttu:r npefd_ gNeUtL_Lm May 25 20:41:01 router kernel: tapgf _rteetsutr:n epdf _NgUeLtL_mt May 25 20:41:01 router kernel: agp fr_teetsutr:n epdf _NgUeLtL_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmta May 25 20:41:01 router kernel: g prfe_ttuersnte:d pNfU_gLeLt May 25 20:41:01 router kernel: _mptfa_gt ersett:u rpnfe_dg eNtU_LmLtag May 25 20:41:01 router kernel: prfe_ttuersnte:d pNfU_LgLet May 25 20:41:01 router kernel: _mptfa_gt ersett:u rpnfe_dg eNtU_LmLtag May 25 20:41:01 router kernel: rpeft_utrensetd: NpUfL_Lget May 25 20:41:01 router kernel: _pmft_atge srte:t uprfn_egde tN_UmLtLa May 25 20:41:01 router kernel: g prfe_ttuersnte:d pNfU_LgLet_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_m May 25 20:41:01 router kernel: tpafg_ treesttu:r npefd_ gNeUtL_Lm May 25 20:41:01 router kernel: tapgf _rteetsutr:n epdf _NgUeLtL_mt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mtpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_ May 25 20:41:01 router kernel: mptfa_gt ersett:u rpnfe_dg eNtU_LmLt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_m May 25 20:41:01 router kernel: tpafg_ treesttu:r npefd_ gNeUtL_Lm May 25 20:41:01 router kernel: tapgf _rteetsutr:n epdf _NgUeLtL_mt May 25 20:41:01 router kernel: apgf _rteetsutr:n epdf _NgUeLtL_m May 25 20:41:01 router kernel: tapgf _rteetsutr:n epdf _NgUeLtL_mt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_m May 25 20:41:01 router kernel: tpafg_ treesttu:r npefd_ gNeUtL_Lmt May 25 20:41:01 router kernel: agp fr_etteusrtn:e dp fN_UgLeLt_m ? Thank you! -- Oleksandr Samoylyk OVS-RIPE From koitsu at FreeBSD.org Sun May 25 19:54:10 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun May 25 19:54:13 2008 Subject: Strange messages in dmesg In-Reply-To: <4839B378.40005@samoylyk.sumy.ua> References: <48065337.3080805@samoylyk.sumy.ua> <9a542da30804161257h6d80efafqa5aec8442811c984@mail.gmail.com> <4839B378.40005@samoylyk.sumy.ua> Message-ID: <20080525195410.GA28558@eos.sc1.parodius.com> On Sun, May 25, 2008 at 09:44:08PM +0300, Oleksandr Samoylyk wrote: > Ermal Lu?i wrote: >> 2008/4/16 Oleksandr Samoylyk : >>> Dear freebsd-pf subscribers, >>> >>> What can such messages from system message buffer mean? >>> >>> ULLpf >>> _tepsft_:t epsft_:g eptf__mgteatg_ mrteatgu rrneetdu rNnUeLdL N >>> ULLpf_ If you're referring to the two strings being intermixed, yes, this is a known problem. I have it documented, as well as a workaround, on my Wiki; see "Scrambled or garbled kernel output": http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues With regards to the errors from pf: no idea. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From comp.john at googlemail.com Mon May 26 01:46:27 2008 From: comp.john at googlemail.com (John .) Date: Mon May 26 01:46:33 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts Message-ID: Hi, I'm running freebsd 7-RELEASE I see this, for example, in my auth log: May 15 02:00:39 www sshd[9180]: Invalid user web from 201.18.232.30 May 15 02:00:41 www sshd[9182]: Invalid user web from 201.18.232.30 May 15 02:00:43 www sshd[9184]: Invalid user web from 201.18.232.30 May 15 02:00:45 www sshd[9186]: Invalid user web from 201.18.232.30 May 15 02:00:48 www sshd[9188]: Invalid user web from 201.18.232.30 May 15 02:00:50 www sshd[9190]: Invalid user web from 201.18.232.30 May 15 02:00:52 www sshd[9192]: Invalid user web from 201.18.232.30 May 15 02:00:54 www sshd[9194]: Invalid user web from 201.18.232.30 May 15 02:00:56 www sshd[9196]: Invalid user web from 201.18.232.30 May 15 02:00:58 www sshd[9198]: Invalid user web from 201.18.232.30 May 15 02:01:00 www sshd[9200]: Invalid user web from 201.18.232.30 May 15 02:01:02 www sshd[9205]: Invalid user web from 201.18.232.30 May 15 02:01:04 www sshd[9207]: Invalid user account from 201.18.232.30 May 15 02:01:06 www sshd[9209]: Invalid user account from 201.18.232.30 May 15 02:01:08 www sshd[9211]: Invalid user account from 201.18.232.30 May 15 02:01:10 www sshd[9213]: Invalid user account from 201.18.232.30 May 15 02:01:12 www sshd[9218]: Invalid user account from 201.18.232.30 May 15 02:01:14 www sshd[9220]: Invalid user account from 201.18.232.30 May 15 02:01:39 www sshd[9244]: Invalid user apache from 201.18.232.30 May 15 02:01:41 www sshd[9246]: Invalid user apache from 201.18.232.30 May 15 02:01:43 www sshd[9248]: Invalid user apache from 201.18.232.30 May 15 02:01:45 www sshd[9250]: Invalid user apache from 201.18.232.30 May 15 02:01:47 www sshd[9252]: Invalid user apache from 201.18.232.30 I'd like it to be so that if an IP tries to connect to sshd more than once in a 30 second period, that they are immediately blackholed. Should I be using pf for this or would it be done better in some other utility? cheers -- John From koitsu at FreeBSD.org Mon May 26 02:24:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon May 26 02:24:52 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts In-Reply-To: References: Message-ID: <20080526022448.GA47206@eos.sc1.parodius.com> On Mon, May 26, 2008 at 02:20:45AM +0100, John . wrote: > I see this, for example, in my auth log: > > May 15 02:00:39 www sshd[9180]: Invalid user web from 201.18.232.30 > > I'd like it to be so that if an IP tries to connect to sshd more than > once in a 30 second period, that they are immediately blackholed. > Should I be using pf for this or would it be done better in some other > utility? ports/security/sshguard-pf ports/security/blocksshd -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From linimon at FreeBSD.org Mon May 26 02:51:48 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 26 02:51:50 2008 Subject: kern/123965: [pf] tcpdump(1) does not see outgoing RST when pf is enabled Message-ID: <200805260251.m4Q2plsu098911@freefall.freebsd.org> Old Synopsis: tcpdump does not see outgoing RST when pf is enabled New Synopsis: [pf] tcpdump(1) does not see outgoing RST when pf is enabled Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 26 02:50:58 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123965 From lyndon at orthanc.ca Mon May 26 02:54:24 2008 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon May 26 02:54:28 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts In-Reply-To: References: Message-ID: > > I'd like it to be so that if an IP tries to connect to sshd more than > once in a 30 second period, that they are immediately blackholed. > Should I be using pf for this or would it be done better in some other > utility? /usr/ports/security/bruteforceblocker. From elliott at c7.ca Mon May 26 07:05:29 2008 From: elliott at c7.ca (Elliott Perrin) Date: Mon May 26 07:05:32 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts In-Reply-To: References: Message-ID: <1211785451.91794.19.camel@kensho.c7.ca> On Mon, 2008-05-26 at 02:20 +0100, John . wrote: > Hi, > > I'm running freebsd 7-RELEASE > > I see this, for example, in my auth log: > > May 15 02:00:39 www sshd[9180]: Invalid user web from 201.18.232.30 > May 15 02:00:41 www sshd[9182]: Invalid user web from 201.18.232.30 > May 15 02:00:43 www sshd[9184]: Invalid user web from 201.18.232.30 > May 15 02:00:45 www sshd[9186]: Invalid user web from 201.18.232.30 > May 15 02:00:48 www sshd[9188]: Invalid user web from 201.18.232.30 > May 15 02:00:50 www sshd[9190]: Invalid user web from 201.18.232.30 > May 15 02:00:52 www sshd[9192]: Invalid user web from 201.18.232.30 > May 15 02:00:54 www sshd[9194]: Invalid user web from 201.18.232.30 > May 15 02:00:56 www sshd[9196]: Invalid user web from 201.18.232.30 > May 15 02:00:58 www sshd[9198]: Invalid user web from 201.18.232.30 > May 15 02:01:00 www sshd[9200]: Invalid user web from 201.18.232.30 > May 15 02:01:02 www sshd[9205]: Invalid user web from 201.18.232.30 > May 15 02:01:04 www sshd[9207]: Invalid user account from 201.18.232.30 > May 15 02:01:06 www sshd[9209]: Invalid user account from 201.18.232.30 > May 15 02:01:08 www sshd[9211]: Invalid user account from 201.18.232.30 > May 15 02:01:10 www sshd[9213]: Invalid user account from 201.18.232.30 > May 15 02:01:12 www sshd[9218]: Invalid user account from 201.18.232.30 > May 15 02:01:14 www sshd[9220]: Invalid user account from 201.18.232.30 > May 15 02:01:39 www sshd[9244]: Invalid user apache from 201.18.232.30 > May 15 02:01:41 www sshd[9246]: Invalid user apache from 201.18.232.30 > May 15 02:01:43 www sshd[9248]: Invalid user apache from 201.18.232.30 > May 15 02:01:45 www sshd[9250]: Invalid user apache from 201.18.232.30 > May 15 02:01:47 www sshd[9252]: Invalid user apache from 201.18.232.30 > > I'd like it to be so that if an IP tries to connect to sshd more than > once in a 30 second period, that they are immediately blackholed. > Should I be using pf for this or would it be done better in some other > utility? > In pf you could write a rule like pass in quick on $ext_if proto tcp from any to $some_ip_address port 22 flags S/SAFR keep state (max-src-conn 1, max-src-conn-rate 1/30, overload flush global) you would have to have setup a table named in your configuration and assign values to both $ext_if and $some_ip_address or replace them with whatever values work for you. This rule would track connections allowing a maximum of 1 connection per source IP address and would allow 1 connection to be initiated every 31 seconds or longer, otherwise it would add the offending IP address to the table and flush the global state table of all entries from the same source IP. You would have to have a rule in your configuration prior to this rule that would block traffic from source IP addresses in the ssh_hacks table. Depending on your policies this could be a block of all services or just ssh. Personally I use a rule like block drop log quick from but block drop log in quick proto tcp from to any port 22 would block ssh traffic from the offending IP to just ssh services on your network. Beware that you can lock yourself out of your servers very quickly with this if you do not have another rule allowing yourself access to your machines setup earlier in your configuration. Cheers, ~e From comp.john at googlemail.com Mon May 26 09:51:10 2008 From: comp.john at googlemail.com (John .) Date: Mon May 26 09:51:18 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts In-Reply-To: <1211785451.91794.19.camel@kensho.c7.ca> References: <1211785451.91794.19.camel@kensho.c7.ca> Message-ID: Thanks everybody for their suggestions! As always, more than one way of doing this ;) -- John From bugmaster at FreeBSD.org Mon May 26 11:06:53 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 26 11:07:38 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200805261106.m4QB6qUE064986@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/116610 pf [patch] teach tcpdump(1) to cope with the new-style pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o kern/118355 pf [pf] [patch] pfctl help message options order false -t o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/123965 pf [pf] tcpdump(1) does not see outgoing RST when pf is e 10 problems total. From ansarm at gmail.com Mon May 26 14:20:28 2008 From: ansarm at gmail.com (Ansar Mohammed) Date: Mon May 26 14:20:33 2008 Subject: SOLVED: ALTQ and bandwidth limiting References: <002d01c8bba7$96128db0$c237a910$@com> <20080522042936.GA24418@eos.sc1.parodius.com> Message-ID: <065801c8bf3b$a4334be0$ec99e3a0$@com> So the problem was that I was running in VMware and the default adapter that vmware configures for the VM is le(AMD PCnet). The le driver did not return the negotiated connection speed when I ran ifconfig. I switched the vm config over to a em (Intel gig) emulation and ifconfig returned the right connection speed. altq now works great. > -----Original Message----- > From: Ansar Mohammed [mailto:ansarm@gmail.com] > Sent: May 22, 2008 2:20 AM > To: 'Jeremy Chadwick' > Cc: 'freebsd-pf@freebsd.org' > Subject: RE: ALTQ and bandwidth limiting > > Ok, I got a bit further. I compiled in ALTQ and I am using Class Based > Queueing. > > Here is a snippet of my pf.conf > > > altq on le1 cbq bandwidth 100Mb queue { std, cifs, http } > > queue std bandwidth 88.5Mb cbq(default) > queue cifs bandwidth 1500Kb cbq > queue http bandwidth 1Mb cbq > > > Here is the problem, no matter what value I set for the CBQ Queue, its > at least 1/4 of the actual configured maximum. So I configured http for > 1Mb, the max throughput I get is 288Mb. Can anyone explain why? > > > > -----Original Message----- > > From: Jeremy Chadwick [mailto:koitsu@FreeBSD.org] > > Sent: May 22, 2008 12:30 AM > > To: Ansar Mohammed > > Cc: freebsd-pf@freebsd.org > > Subject: Re: ALTQ and bandwidth limiting > > > > On Wed, May 21, 2008 at 09:02:59PM -0400, Ansar Mohammed wrote: > > > Hello All, > > > > > > Is there a way using PF and ALTQ that I can set a policy to > restrict > > a > > > particular host to a maximum network speed? > > > > > > I would like to simulate low speed connection using pf. > > > > I believe ipfw dummynet has the capability you're looking for. See > the > > ipfw manpage, section "TRAFFIC SHAPER". > > > > -- > > | Jeremy Chadwick jdc at parodius.com > | > > | Parodius Networking http://www.parodius.com/ > | > > | UNIX Systems Administrator Mountain View, CA, USA > | > > | Making life hard for others since 1977. PGP: 4BD6C0CB > | From max at love2party.net Mon May 26 14:30:05 2008 From: max at love2party.net (Max Laier) Date: Mon May 26 14:30:07 2008 Subject: kern/123965: [pf] tcpdump(1) does not see outgoing RST when pf is enabled Message-ID: <200805261430.m4QEU4HI083906@freefall.freebsd.org> The following reply was made to PR kern/123965; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, kian.mohageri@gmail.com Cc: Subject: Re: kern/123965: [pf] tcpdump(1) does not see outgoing RST when pf is enabled Date: Mon, 26 May 2008 16:21:18 +0200 This has been fixed with rev. 1.193 of sys/net/bpf.c or 1.181.2.2 in RELENG_7. See below for details. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/bpf.c#rev1.181.2.2 -- Max From peter at bsdly.net Mon May 26 16:31:42 2008 From: peter at bsdly.net (Peter N. M. Hansteen) Date: Mon May 26 16:31:45 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts In-Reply-To: (John .'s message of "Mon, 26 May 2008 02:20:45 +0100") References: Message-ID: <87mymdm3h0.fsf@thingy.bsdly.net> "John ." writes: > I'd like it to be so that if an IP tries to connect to sshd more than > once in a 30 second period, that they are immediately blackholed. > Should I be using pf for this or would it be done better in some other > utility? PF offers a very flexible mechanism for that, via state tracking options. See eg http://home.nuug.no/~peter/pf/en/bruteforce.html for a walkthrough. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From kian at restek.wwu.edu Mon May 26 18:40:04 2008 From: kian at restek.wwu.edu (Kian Mohageri) Date: Mon May 26 18:40:10 2008 Subject: kern/123965: [pf] tcpdump(1) does not see outgoing RST when pf is enabled Message-ID: <200805261840.m4QIe3M5003719@freefall.freebsd.org> The following reply was made to PR kern/123965; it has been noted by GNATS. From: Kian Mohageri To: bug-followup@FreeBSD.org, kian.mohageri@gmail.com Cc: Subject: Re: kern/123965: [pf] tcpdump(1) does not see outgoing RST when pf is enabled Date: Mon, 26 May 2008 11:10:21 -0700 Cool, should have searched more thoroughly. Thanks! From ohauer at gmx.de Mon May 26 21:11:36 2008 From: ohauer at gmx.de (Olli Hauer) Date: Mon May 26 21:11:40 2008 Subject: auto-blackholing/blacklisting on multiple hacking attempts In-Reply-To: <1211785451.91794.19.camel@kensho.c7.ca> References: <1211785451.91794.19.camel@kensho.c7.ca> Message-ID: <20080526204454.97610@gmx.net> > > Hi, > > > > I'm running freebsd 7-RELEASE > > > > I see this, for example, in my auth log: > > > > May 15 02:00:39 www sshd[9180]: Invalid user web from 201.18.232.30 > > May 15 02:00:41 www sshd[9182]: Invalid user web from 201.18.232.30 ... > > May 15 02:01:43 www sshd[9248]: Invalid user apache from 201.18.232.30 > > May 15 02:01:45 www sshd[9250]: Invalid user apache from 201.18.232.30 > > May 15 02:01:47 www sshd[9252]: Invalid user apache from 201.18.232.30 > > > > I'd like it to be so that if an IP tries to connect to sshd more than > > once in a 30 second period, that they are immediately blackholed. > > Should I be using pf for this or would it be done better in some other > > utility? > > > > In pf you could write a rule like > > pass in quick on $ext_if proto tcp from any to $some_ip_address port 22 > flags S/SAFR keep state (max-src-conn 1, max-src-conn-rate 1/30, > overload flush global) > > you would have to have setup a table named in your > configuration and assign values to both $ext_if and $some_ip_address or > replace them with whatever values work for you. > > This rule would track connections allowing a maximum of 1 connection per > source IP address and would allow 1 connection to be initiated every 31 > seconds or longer, otherwise it would add the offending IP address to > the table and flush the global state table of all entries > from the same source IP. > > You would have to have a rule in your configuration prior to this rule > that would block traffic from source IP addresses in the ssh_hacks > table. Depending on your policies this could be a block of all services > or just ssh. Personally I use a rule like > > block drop log quick from > > but > > block drop log in quick proto tcp from to any port 22 > > would block ssh traffic from the offending IP to just ssh services on > your network. > > Beware that you can lock yourself out of your servers very quickly with > this if you do not have another rule allowing yourself access to your > machines setup earlier in your configuration. > I have a nice script for my OpenBSD machines aviable, with some small changes it will work also on FreeBSD. The script make usage of a special table dumps and compare the addresses with a run some minutes ago (cron job) and reports the ip's per mail with the help of GeoIP. This reports make it easy to block big network ranges where you don't expect to travel ... You can get the script here: http://sorry.mine.nu/scripts/pftable_to_file.sh.txt ps: In the directoy is also an actual bf_ssh dump from one of my machines regards, olli -- Super-Aktion nur in der GMX Spieleflat: 10 Tage f?r 1 Euro. ?ber 180 Spiele downloaden und spiele: http://flat.games.gmx.de From reinhard.haller at interactive-net.de Tue May 27 07:22:33 2008 From: reinhard.haller at interactive-net.de (Reinhard Haller) Date: Tue May 27 07:22:54 2008 Subject: NAT problem with pppoe In-Reply-To: <20080521084000.GC5072@verio.net> References: <48333B05.9090203@interactive-net.de> <20080521084000.GC5072@verio.net> Message-ID: <483BB699.4040608@interactive-net.de> Hi David, David DeSimone schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Reinhard Haller wrote: > >> Sending HUP to ppp does'nt eliminate the problem, pfctl -d/-e and a >> restart of the internal server solve it. >> > > I suggest that your ppp "if_down" script make use of the "pfctl -k" > command to kill state entries that have to do with the IP that is being > removed. > 16:45 linkdown: pfctl -k 88.217.34.98 16:45 linkup: myaddr=82.135.87.233 16:48 dns-request with 88.217.34.98 as source address to 212.18.0.5 our DNS queries from internal servers are still sent with the old dynamic address as source address where a local dig on the pf-box uses the new dynamic address. Any suggestions where to search? Thanks Reinhard From user at lgkap.com Wed May 28 13:33:53 2008 From: user at lgkap.com (user) Date: Wed May 28 13:33:57 2008 Subject: PF occasionally "losing" packets Message-ID: <483D5BB9.40900@lgkap.com> Hey Everyone, I seem to have a problem with PF "losing" packets. With PF enabled (7.0-RELEASE) allowed traffic will sometimes get through but more often will not. More specifically, from the logs I can see packets passed into the internal interface, but they often do not trigger the outbound rule even though I allow everything out. pass out quick log all pass in quick log on fxp1 proto {tcp,udp} from X.33.195/24 to X.33.10.20 port 53 keep state Sometimes BIND requests will get through and I can see both in/out rule trigger and get logged. More often, I see the following in the logs when the nslookup fails: 4. 835454 rule 21/0(match): pass in on fxp1: X.33.195.244.45453 > X.33.10.20.53: [|domain] 242279 rule 21/0(match): pass in on fxp1: X.33.195.244.45454 > X.33.10.20.53: [|domain] 3. 756975 rule 21/0(match): pass in on fxp1: X.33.195.244.45455 > X.33.10.20.53: [|domain] 242070 rule 21/0(match): pass in on fxp1: X.33.195.244.45454 > X.33.10.20.53: [|domain] 7. 756284 rule 21/0(match): pass in on fxp1: X.33.195.244.45456 > X.33.10.20.53: [|domain] Even though the packets are allowed in, they often never get to the outbound interface. Note that this is not limited to bind requests. I see the same thing with ssh, ping, etc. I've checked the routing table, interfaces, etc.... I can't seem to pinpoint the cause. Has anyone seen this inconsistency? Thanks in advance for any help. Louis From fox at verio.net Wed May 28 16:54:39 2008 From: fox at verio.net (David DeSimone) Date: Wed May 28 16:54:45 2008 Subject: PF occasionally "losing" packets In-Reply-To: <483D5BB9.40900@lgkap.com> References: <483D5BB9.40900@lgkap.com> Message-ID: <20080528162839.GA8700@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 user wrote: > > I seem to have a problem with PF "losing" packets. With PF enabled > (7.0-RELEASE) allowed traffic will sometimes get through but more > often will not. Are you certain that the packets are not passing, or are they simply not being logged? You appear to be assuming that every packet that passes will be logged via pflog(4). > pass out quick log all > pass in quick log on fxp1 proto {tcp,udp} from X.33.195/24 to X.33.10.20 port 53 keep state Both of your rules specify that state be established ("keep state" is now explicit in 7.0). Packet logging is only performed when the rulebase is matched; once that is done, state is established and packets matching that state are passed without being logged. The only way to be sure you are losing traffic is by running tcpdump on both the internal and external interface, and comparing traffic. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIPYg3FSrKRjX5eCoRAhoAAKCgj9IB0LY4Iu3AHrXTZPoF+2ramQCfWeV8 tjLhYkVQ3Tq4FlbnJatf5A0= =wg8t -----END PGP SIGNATURE----- From gerryw at compvia.com Thu May 29 06:13:44 2008 From: gerryw at compvia.com (gerryw@compvia.com) Date: Thu May 29 06:14:01 2008 Subject: Misc PF +ALTQ questions Message-ID: Hello All, I have been looking at the possibility of doing a project to create a C API library for PF + ALTQ and possibly a higher level C++ API. I am new to these components and fairly new to FreeBSD. I have been looking at the man pages and various other docs on the topic. It would seem I can glean most of the ioctl info from the pfctl source. However, I have a few question the I haven't been able to find answers to. I apologize if these have been answered before and I have missed them. 1. Most of the examples I've seen are oriented towards a home or small office user with a DSL or cable Internet connection. My focus is more in the ISP area. I want to support the ability to hard limit bandwidth by IP and/or MAC address. I have read somewhere that MAC addresses can be used as a source, but this can only be done in bridge mode. Is this correct? 2. I can see how a queue could be crated for each IP address and the traffic from that IP sent to the appropriate queue. This would result in quite a few queues when done for an entire /24 subnet. Is there a better way to do this? I have also read somewhere that table lookups are pretty fast. Is there a way to take advantage of this fact where bandwidth limiting is concerned? 3. Would I be better off using one of the existing queueing disciplines as an example and writing some code specifically designed to do what I'm wanting to do? 4. Is there any good info on the bandwidth usage statistics provided by PF + ALTQ? I would like to do as much through the ioctl interface as possible. 5. I am also looking for a way to enumerate the IPs and MACS that are being seen by a particular interface. Again, I would like to do as much through the ioctl interface as possible. The pflog component is not really a possibility because my application will be for embedded use. Comment: I must say I am very impressed with the fact that the ioctl interface is actually provided and documented to some degree. I am really enjoying the fact that there seems to be much more doc in general in this area than of Linux. Many thanks to the folks that took the time to do this work. Thanks in advance, -G