Re: NAT64 troubleshooting
* Torsten Schuchort [2014-12-10 20:34]: > > Am 10.12.2014 um 17:59 schrieb Torsten Schuchort : > > Can you please explain this for me, or us. Only for interest? > Forget my request, found it by myself in the book of pf and it make sense for > me. see? Explaining things to peter (if needed, at all) once, usually during the tech edit phase, is more efficient than repeating explanations on some ML every now and then. At least from my PoV :) -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: NAT64 troubleshooting
* Torsten Schuchort [2014-11-23 20:00]: > Hi, i’ve got trouble with nat64 to until i changed the default state policy > for the nat64 rule. > pf set’s for default „set state-policy if-bound“, so is use for the nat64 > rule: just to make it utterly clear: the default is "floating", and NOT if-bound. For good reasons. if-bound really only makes sense for enc and the like. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: Scrub reassemble tcp
the entire scrubbing idea is pretty much abandoned these days. it was a hot topic in the early 2000s (for everybody, not "just" us). no, don't use tcp reassemble. * Evaldas Auryla [2014-11-21 18:20]: > On 2014-11-14 14:54, Henning Brauer wrote: > >>Is anyone using "reassemble tcp" with scrub ? Been using this for years > >>without problems, > >you just didn't notice the problems or didn't hit them. Reassemble tcp > >isn't 100%, unfortunately, and never was. No changes in ages either. > Well, nobody raised a hand, so let's say I didn't notice. > >hitting it more often now isn't too surprising given the increasing use > >of windows scaling etc. > > > I see, so would you recommend to not use it ? As a workaround I tried > declaring second "scrub" line targeting this specific system with "to IP.." > syntax, and pf accepted it, but then it seems to be ignored. > > Thanks! >
Re: Scrub reassemble tcp
* Evaldas Auryla [2014-11-13 19:30]: > Is anyone using "reassemble tcp" with scrub ? Been using this for years > without problems, you just didn't notice the problems or didn't hit them. Reassemble tcp isn't 100%, unfortunately, and never was. No changes in ages either. hitting it more often now isn't too surprising given the increasing use of windows scaling etc. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: rule def/(short) in tcpdump -e
* Axel Rau [2014-10-20 12:30]: > what does > rule def/(short) [uid 0, pid 0] pass in > mean in the tcpdumped pflog? def: matched the implicit default rule short: the reason why the packet was dropped - it was shorter than it should have been, aka pbly truncated (or malicious). grep for PFRES_SHORT in sys/net/pf*.c for the exact cases. when you see packets being dropped referring to the default rule taht means as much as pf dropped it for non-rule based reasons, i. e. too short packets and the like, that usually happens before ruleset eval. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Re: Problem with carp and "inet alias"
* Sebastian John [2013-11-19 19:00]:
> try to use the correct network mask in alias configuration:
> inet alias 200.200.200.163 255.255.255.240
try to not give wrong advice. all-ones netmask is EXACTLY the right
thing here.
probably even for the first ("main") address, unless carpdev is
unnumbered.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
pgp07t8jYq4FG.pgp
Description: PGP signature
Re: Configuration for discarding specific fragments
* mark.lati...@gmail.com [2013-09-01 08:01]: > Is it possible to reassemble so fragments and not others nope; all or nothing. > or is the best app= > roach to deploy a screening router/another PF to filter but not reassemble = > in addition to the PF reassembling and scrubbing? i think you're mostly fighting ghosts here, esp with the extremely tiny share of fragments we see in real world traffic these days. the reassembly isn't completely dumb, it should be able to protect itself from the cache being filled with junk. if there is still a way we might have to amend these smarts. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: I want to filter some/all inbound traffic twice
* Cameron Simpson [2013-04-05 11:01]: > On 05Apr2013 08:45, Daniel Hartmeier wrote: > | If you need NAT, you have to do that on the external interface, and it > | requires (implies, even) creating states. > > I was imagining NATing on an internal virtual interface to a private > address on some kind of internal virtual interface; this might keep > the necessary state without being the outmost layer. NAT can be applied in any direction and on any interface on recent openbsd, so that won't stop you. the manoage has the caveats for the respective "unnatural" direction. you might get away with 2 routing domains. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Enforcing asymmetric TCP MSS?
* Eric Lee [2011-05-10 10:30]: > I'm trying to use scrub max-mss rules to create asymmetric MSS's. > > Is this supported? So far, I haven't got it to work (hence my post here). > The machine is running OpenBSD 4.9 with 2 network cards. > > I have been trying things like: > match out on $ext proto tcp scrub(max-mss 1000) flags S/SA > match in on $ext proto tcp scrub(max-mss 500) flags SA/SA that doesn't work because only one of those two rules ever matches a given connection, from then on the state decides. using two match rules on different interfaces should work i think. the only other option is stateless, but that is stupid for many many reasons. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Suggestion for a new feature, port code
we will never let that shit even remotely close to our tree. period. * Johan Söderberg [2011-03-04 15:00]: > In my mind this is not security by obscurity, no more than one-time > passwords. > The ports can be compared to the keys of a keyboard when typing a password. > As with passwords, the implementation is not a secret. > The port that is protected is not hidden, it is locked. > It adds security and do not add attack vectors as it is implemented as a > simple > ruleset for pf, protecting sshd. It can also be combined with authpf. > Why waste energy on spammed logs with scans and attacks, banning and luring > with > honeypots on the outside? > Why give sshd unnecessary exposure as it may have weaknesses? > > http://en.wikipedia.org/wiki/Security_through_obscurity > http://stackoverflow.com/questions/4486171/isnt-a-password-a-form-of-security- > through-obscurity > http://security.stackexchange.com/questions/1194/port-knocking-is-it-a-good-idea -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Pfctl -s info and more
* Patrick Lamaiziere [2011-01-17 17:30]: > Hello, > > (PF on openbsd 4.8) > > I've got two small questions about the stats returned by pfctl -s info > > There are several state-mismatch. What does it mean? > state-mismatch 79715 3.3/s you received that mnay packets that failed to match a state entry even tho they should. That is the case with tcp and sequence number out of window. > Same for the normalize counter, I don't have any scrub rule and I don't > know why some packets are normalized? > normalize 7103 0.3/s IPvShit jumbograms are dropped with the normalize counter increased wether scrubbing is there or not. fragments go to the reassembler (which might drop some, increasing the normalize counter) unless you set reassemble to no (defaults to yes). -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: PF messing with my PPPoE test or am I just confused...?
* Jonathan Rogers [2011-01-04 02:30]: > If I had the option of installing a more recent OS I would have done > that, and I would not have posted the question. v3.8 help was > explicitly asked for. A reply of form "well, on a higher version of > the OS there are other ways to do it" is (a) obvious and (b) > completely unhelpful in this context. you are on your own, then. the supported releases right now are 4.7 and 4.8, period. as if anyone remembers details from a release 5 years ago. and... why bother. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf, synproxy, max-src-conn, FIN_WAIT_2
* Nerius Landys [2010-10-26 01:30]: > I'm using synproxy to limit the number simultaneous TCP > connection to a certain application no, you are not. synproxy has NOTHING to do with limiting the # of connections. that is a generic function of the state keeping code. > During the time when a large download is happening using wget, the > pf state table will have "ESTABLISHED:ESTABLISHED". If wget was in the > process of performing a large download and I hit Ctrl+C (or kill it), > the state table will have "TIME_WAIT:TIME_WAIT". If wget successfully > finishes downloading something, I will see "FIN_WAIT_2:FIN_WAIT_2" in > the state table. welcome to tcp > If there is a way to not count the "FIN_WAIT_2:FIN_WAIT_2" > towards my max-src-conn, please do tell! no, and that would be counterproductive. I'm sure you'll see for yourself why if you think about it for a second. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: synproxy and RST (non-listener)
* Ryan McBride [2010-10-23 11:56]: > On Sat, Oct 23, 2010 at 02:51:11AM +0300, Nerius Landys wrote: > > Thanks for the reply. But I don't _completely_ understand. I don't > > know too much about operating system calls, but let's say that I > > have a program that is bound to TCP port 8080 on my local machine > > (same machine that is running the pf in question). Let's say I > > launch another program that tries to listen on this port as well. > > Of course it will fail with "cannot bind to port" or something like > > that. So there _is_ something the operating system tells us > > regarding a > > port being bound on the local system, and this [presumably] does not > > require any packets to be sent. Could we do a similar check before > > completing a handshake with a client via synproxy? > > Yes, in the case where the synproxy rule is protecting connections to > a local machine, in theory PF could be modified to check whether there is > a service listening on that port. It would be a lot of code for not much > benefit, though. last not least because "something listening" does not necessarily imply "will accept a connection". > To be 100% clear, the simplest solution to the synproxy problem you've > described is this: Don't use synproxy if you aren't sure that there will > be a service listening on the port. I'd go further - synproxy isn't there for everyday use, but as a temporarily measure when you're under attack and the synproxy shortcoming are the smaller problem. and for your subscription issues - I strongly believe the right mailing list is m...@openbsd.org anyway.
Re: synproxy and RST (non-listener)
* Nerius Landys [2010-10-20 22:30]: > >Is there a way to get synproxy to send the RST (I _think_ that's what it > >is called) when no service is running on that port? Or is this a feature? > >Or is there a reason it behaves this way? Intentional, bug, oversight, > >or missing modifier to my rule? > > Hrm I think, after doing a little bit more research, I understand why this > isn't possible. Maybe you can tell me if I'm right. Seems that > synproxy completes a TCP connect handshake completely with the client > before even sending anything to the actual service it's proxying. > This is the whole purpose of synproxy. So, it has a completed handshake, > the client thinks he's "connected", and pf tries to "connect" to the > underlying service, but receives an RST or whatnot, which means > the service isn't running. It's probably too late to send an RST > to the client at this point, so pf just lets the connection from the > client "hang". that's about right > I suppose there's not way to get around this problem... right. > Maybe ask the operating system if the port is "bound" before completing > the handshake with the client, otherwise send RST to the client? askin before isn't possible. you do not know that the backend will accept a connection based on a previous connection being accepted. and doing a check before replying with a syn defeats the prupose anyway. sending an RST back if the backend doesn't accept the connection, well, we could do that, but it still doesn't solve anything - clients treat "established connection terminated" very differently then "connection not accepted". there is no way to "solve" this. synproxy is not for everyday use. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf protection against spoofed [source addr] packets
* Nerius Landys [2010-10-20 08:46]: > 1. Why can't I spoof a source address of 127.0.0.1? we have some special protection for 127.0.0.1 in the stack > 2. What specific rules would you recommend for preventing spoofed > packets people spend too much time on this. make sure nobody spoofs your own IPs (or, more precise, any IP you do access control with) and be done with it. really, spoofing has to be fought at the source, you can't layer. so you want to make sure only packets with your own IPs as src leave your network. > By the way I'm using FreeBSD 8.0 and 7.1. as in, ancient and crippled pf. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfsync and policy routing states patch(OpenBSDv46 stable) - version2
* Romey Valadez [2010-01-21 01:38]: > I sent this patch to t...@openbsd.org mail list > This patch apply to OpenBSD v4.6 -stable as I told you before, patches to 4.6 are useless. especially given this stuff changed a lot in -current. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Restricting source with dDNS (dynamic DNS)
* Alvaro Mantilla Gimenez [2009-12-19 12:00]: > It would be awesome if pf could implement some port knocking features over my dead body -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: [4.5] Unable to connect using IPSEC over IPv6
* Helmut Schneider [2009-12-18 08:30]: > Henning Brauer wrote: > > * Stuart Henderson [2009-12-16 16:00]: > > > On 2009/12/16 13:27, Helmut Schneider wrote: > > > > [...] > > > > > Dec 15 13:34:23.640235 rule 11/(match) block in on bge0: > > > > > $SERVER > $CLIENT: frag (0|1448) 500 > 500: isakmp v1.0 > > > > > exchange ID_PROT encrypted cookie: > > > > > 583b9e29ae2a701f->f2257c7575eb8336 msgid: len: 1596 > > > > > Dec 15 13:34:23.640245 rule 11/(match) block in on bge0: > > > > > $SERVER > $CLIENT: frag (1448|156) > > > > > > > > Same with 4.6. With "pass quick log inet6" the connection is > > > > successful. Is the packet incorrectly parsed?! The fact that the > > > > unfragmented packet is passed would confirm that. > > > > > > PF doesn't support IPv6 fragments yet. > > > > "yet". hah. > > "hah" in the sense of "It's cooking" or in the sense of "Are you > kidding"? http://www.mail-archive.com/m...@openbsd.org/msg84332.html > pp. raised hopes. nobody is actively working on anything in that direction afaik. chances are the hole v6 mess is declared obsolete before we get into this mess (heh, mess on top of mess, get dirty). all hail ipv4/64! -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: [4.5] Unable to connect using IPSEC over IPv6
* Stuart Henderson [2009-12-16 16:00]: > On 2009/12/16 13:27, Helmut Schneider wrote: > > [...] > > > Dec 15 13:34:23.640235 rule 11/(match) block in on bge0: $SERVER > > > > $CLIENT: frag (0|1448) 500 > 500: isakmp v1.0 exchange ID_PROT encrypted > > > cookie: 583b9e29ae2a701f->f2257c7575eb8336 msgid: len: > > > 1596 > > > Dec 15 13:34:23.640245 rule 11/(match) block in on bge0: $SERVER > > > > $CLIENT: frag (1448|156) > > > > Same with 4.6. With "pass quick log inet6" the connection is > > successful. Is the packet incorrectly parsed?! The fact that the > > unfragmented packet is passed would confirm that. > > PF doesn't support IPv6 fragments yet. "yet". hah. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: "Brutes" rules with UDP?
* Jordi Espasa Clofent [2009-11-24 17:32]: > >># SSH brutes protection > >>pass quick on $bridge inet proto tcp from any to $vlan10 port 22 > >>keep state \ > >>(max-src-conn 20, max-src-conn-rate 3/12, \ > >>overload flush global) > >> > >>with success. No problem, all works fine. > >> > >>I wonder if I can apply this type of rule to UDP connections (I try > >>to protect some busy DNS servers) > > > >no, there's no way to avoid spoofed requests with UDP. if someone > >sends a bunch of UDP packets spoofed from $BIG_ISP_RESOLVER's IP > >address, their legitimate requests will be blocked. > > I don't understand your response, Stuart. > I wonder if the mentioned rule (using max-src-conn and max-src-rate) > is also applicable to UDP-oriented connections as DNS is. > >no, ^^ quite clear isn't it? the tcp one works based on completed 3way handshakes. now think about it. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pf configuration subleties
* Daniel Malament [2009-09-12 23:04]:
> 1) The big one is what I would call the 'double state problem'. It
> seems to me that the big disadvantage of a default-deny ruleset is that
> because explicit pass rules are required on all interfaces, traffic
> passing through the firewall machine needs state on all interfaces. This
> isn't a problem for most applications, but it seems like it would be a
> memory issue for large routers.
there's no memory problem really. you will have memory bandwidth / bus
bandwidth / interface bandwidth maxed out long before memory for the
states becomes an issue. i am not aware of a _single_ case of state
table size problem in at least 5 years (in the early days the pools
used had limitations that actually made that a bit problematic, but
that is long solved).
you want default deny and double states... really. not bored enough to
write that down again tho.
and if you don't like the double states you can still set skip on one
of the interfaces. but understand the consequences.
> pass on $int_if no state
ugh.
stateless = slow.
> 2) The other (shorter) question:
> If I want one of my internal networks to be able to access the internet,
> but not be able to access my other internal networks, is
>
> ---
> table { 0.0.0.0/0 !$int_net1 !$int_net2 }
> block all
> pass in on $int_net3 from any to
> [etc]
> ---
>
> better or worse in speed and resources than
>
> ---
> block all
> pass in on $int_net3
> block in on $int_net3 from any to $int_net1:network
> block in on $int_net3 from any to $int_net2:network
> [etc]
> ---
won't make a difference that matters.
with just 3 entries they are probably about the same, the more entries
the more advantage for the table.
but then the optimizer will make that a table anyway (exceptions apply)
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: What's the progress of in-kernel proxy for pf NAT?
* hu st [2009-07-23 12:35]: > Hi listers, > > I found many in-kernel proxy resources in ipfilter package(ip_fil4.1.32), such > as ftp/pptp/h323/netbios/irc/rpc etc. > Could these code be used by pf? pf purposefully does not use in-kernel proxies. wrong design. > AFAIK pf has only a ftp-proxy anchor. it has userland helpers for the most relevant protocols. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Does OpenBSD 4.4 PF ALTQ supports HFSC?
* Pui Edylie [2009-01-25 12:33]: > From the website > > http://www.openbsd.org/faq/pf/queueing.html > > It says it only supports FIFO, CBQ and PRIOQ thatis outdated then, HFSC werks. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Using state table with a transparent firewall
* Federico Giannici [2008-12-25 21:31]: > 1) To be as "transparent" as possible, we should use the "flags any" > keyword, because with the default "flags S/SA" keyword the connections > already established would not match the "pass" rule and would be > blocked. Am I right? yup > 2) As we use different queue names for "inside" and "outside" traffic, > every "pass" rule have a "on " parameter and specific "from" > e "to" parameters. In this situation we should use the "set state-policy > if-bound" option. Am I right? no, changes nothing in taht situation > 3) In practice, we will have two separate states, one for "inside" and > one for "outside" packets. In this situation, should we use the "sloppy" > option? no > Or does the server "sees" every packet, so there is no problem > with normal states tracking? yes -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: PF, packet sizes and icmp replies
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-11-18 20:02]: > Admin-generated icmp codes: With IPFW we could return icmp code 1 then > user tried to connect to closed ports (especially with SMTP port for > spammers) . With PF we could block only by silent drop, or ICMP > unreachable. It's not enough. wrong. block return sends an RST for the connection in question for tcp. which is exactly the stack behaviour for closed ports. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: A PF Certification - what do you think?
* Peter GILMAN <[EMAIL PROTECTED]> [2008-07-11 07:49]: > funny - after using openbsd everywhere for years, i finally had to > switch to freebsd on my laptop (tp a31) because things that had worked > fine on previous versions of openbsd stopped working in 4.3... (i > still use openbsd on my gateway/firewall and servers, though.) I don't remember seeing any bug reports or efforts to fix issues from you. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: urpf-failed vs. multiple routing tables?
* Max Laier <[EMAIL PROTECTED]> [2008-05-01 11:33]: > wouldn't it make sense to add a rtableid to urpf-failed? totally. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: block-policy return ignored with ipv6?
* Daniel Hartmeier <[EMAIL PROTECTED]> [2008-02-14 16:37]:
> On Tue, Feb 12, 2008 at 07:40:14PM +0100, Helmut Schneider wrote:
>
> > Is that expected?
>
> No, it's a bug introduced with pf.c 1.534 after 4.1 was released.
>
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.533&r2=1.534&f=h
>
> For IPv6 TCP, calling pf_check_proto_cksum() with AF_INET will always
> fail. No RST will be generated, the 'proto-cksum' counter in pfctl -si
> output will increase instead.
>
> Henning?
this works, tested by Helmut, ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.565
diff -u -p -r1.565 pf.c
--- pf.c22 Nov 2007 02:01:46 - 1.565
+++ pf.c15 Feb 2008 14:20:09 -
@@ -3240,10 +3240,22 @@ pf_test_rule(struct pf_rule **rm, struct
(r->rule_flag & PFRULE_RETURN)) &&
!(th->th_flags & TH_RST)) {
u_int32_tack = ntohl(th->th_seq) + pd->p_len;
- struct ip *h = mtod(m, struct ip *);
+ int len = 0;
+ struct ip *h4;
+ struct ip6_hdr *h6;
- if (pf_check_proto_cksum(m, off,
- ntohs(h->ip_len) - off, IPPROTO_TCP, AF_INET))
+ switch (af) {
+ case AF_INET:
+ h4 = mtod(m, struct ip *);
+ len = ntohs(h4->ip_len) - off;
+ break;
+ case AF_INET6:
+ h6 = mtod(m, struct ip6_hdr *);
+ len = ntohs(h6->ip6_plen) - (off - sizeof(*h6));
+ break;
+ }
+
+ if (pf_check_proto_cksum(m, off, len, IPPROTO_TCP, af))
REASON_SET(&reason, PFRES_PROTCKSUM);
else {
if (th->th_flags & TH_SYN)
Re: block-policy return ignored with ipv6?
* Daniel Hartmeier <[EMAIL PROTECTED]> [2008-02-14 16:37]:
> On Tue, Feb 12, 2008 at 07:40:14PM +0100, Helmut Schneider wrote:
>
> > Is that expected?
>
> No, it's a bug introduced with pf.c 1.534 after 4.1 was released.
>
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.533&r2=1.534&f=h
>
> For IPv6 TCP, calling pf_check_proto_cksum() with AF_INET will always
> fail. No RST will be generated, the 'proto-cksum' counter in pfctl -si
> output will increase instead.
>
> Henning?
looks like I screwed that a bit...
this enough to fix it?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.565
diff -u -p -r1.565 pf.c
--- pf.c22 Nov 2007 02:01:46 - 1.565
+++ pf.c14 Feb 2008 15:57:20 -
@@ -3243,7 +3243,7 @@ pf_test_rule(struct pf_rule **rm, struct
struct ip *h = mtod(m, struct ip *);
if (pf_check_proto_cksum(m, off,
- ntohs(h->ip_len) - off, IPPROTO_TCP, AF_INET))
+ ntohs(h->ip_len) - off, IPPROTO_TCP, pd->af))
REASON_SET(&reason, PFRES_PROTCKSUM);
else {
if (th->th_flags & TH_SYN)
Re: NAT & (interface) = round-robin between IPv4/IPv6 addresses?
* Ed White <[EMAIL PROTECTED]> [2008-01-04 17:01]: > On Friday 04 January 2008 12:17, Henning Brauer wrote: > > > I noticed that with the following NAT rule: > > > nat on sis1 from 10.2.2.0/28 to any -> (sis1) static-port > > > > > > I get the following output: > > > # pfctl -sn > > > nat on sis1 inet from 10.2.2.0/28 to any -> (sis1) round-robin > > > static-port > > > > > > My question is simple: is that "round-robin" actually used? > > > If it really means that PF sees 2 or more IPs, what are these IPs? > > > > it just says that pf will doround roubin _if_ there is more than one > > ip. > > > The problem is that I actually see two IPs: one IPv4 and one IPv6. > Would pf do round robin using one IPv4 and one IPv6? of course not. pf does not translate between different address families. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: NAT & (interface) = round-robin between IPv4/IPv6 addresses?
* Ed White <[EMAIL PROTECTED]> [2008-01-04 07:32]: > Happy new year everybody, > > I have a quick question. I am using OpenBSD 4.2-stable. > > I noticed that with the following NAT rule: > nat on sis1 from 10.2.2.0/28 to any -> (sis1) static-port > > I get the following output: > # pfctl -sn > nat on sis1 inet from 10.2.2.0/28 to any -> (sis1) round-robin static-port > > This is the interface: > sis1: flags=8843 mtu 1500 > lladdr xx:xx:xx:xx:xx:xx > groups: egress > media: Ethernet autoselect (100baseTX full-duplex) > status: active > inet6 ::xxx:::xxx%sis1 prefixlen 64 scopeid 0x2 > inet zz.zz.zz.zz netmask 0xff00 broadcast zz.zz.zz.zzz > > > My question is simple: is that "round-robin" actually used? > If it really means that PF sees 2 or more IPs, what are these IPs? it just says that pf will doround roubin _if_ there is more than one ip. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Packets slip through PF while ruleset is reloaded?
* Henrik Johansen <[EMAIL PROTECTED]> [2008-01-02 13:32]: > Hi list, > > We had an ICMP flood against one of our servers this weekend > and I noticed something strange. > > Whenever I ran '/sbin/pfctl -Fr -f /etc/pf.conf' ICMP packets started > to slip through for a second and a couple of states related to those > ICMP packets were created. > > The only time ICMP packets got through the firewall was when I reloaded > the ruleset. > The box in question is running OpenBSD 4.1-STABLE and > the ruleset in question is using a "default deny" policy. > Is > that expected behaviour ? when you're using -Fr, yes. you should not do so. ruleset reload is atomic when you leave the manual flush out. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: PF and multiple CPUs
* Jordi Espasa Clofent <[EMAIL PROTECTED]> [2007-12-20 13:03]: > Hi all, > > I've read about this tipic in this present list and in the misc@ list. > Currently I'm making performance test in a box which has a pair of > Quad-Core Intel Xeon processor L5320. > > If I use bsd kernel ¿only a 1 Core of the first CPU is used? > If I use a bsd.mp kernel ¿always pf performance decrease? > > Sincerely, nowadays is hard to find out a simple-CPU in servers > environment. so just run the uniprocessor kernel on them, no problem, other cores will idle just fine. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Several questions
* Jordi Espasa Clofent <[EMAIL PROTECTED]> [2007-11-15 19:01]: > Yes Karl, you've the reason. > > I've searched in the archives of the present list and I've found a lot of > useful info about the initial question. > > At present moment I consider the next tips: > > * sk(4)-based NICs have the best performance > * one dedicated data-bus per NIC (I think a PCI-E x8/x16 will be enough > in my environment) > * OpenBSD 4.2 PF's (it seems the performance has been improved until > 50%!!! in relation to previous releases) more like 120% faster actually. > So, now I've one additional question > > ¿Can the hard-disk performance to mean a bootle-neck in the PF-based FW > box? I understand the major part of PF operations are made in RAM memory, > but maybe I'm not right. memory speed is a factor. hdd speed not, unless you want to log a _lot_. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Several questions
* Jordi Espasa Clofent <[EMAIL PROTECTED]> [2007-11-15 12:01]: > * 120/150 MBps outcoming traffic (services as http, dns, smtp...) > * more than 150 servers > > ¿Is capable a simple OpenBSD+PF box to do this amount of work? easily -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Need more performance (FreeBSD or OpenBSD)
* Florin Andrei <[EMAIL PROTECTED]> [2007-11-06 07:45]: >> Does the "em" driver do interrupt mitigation ? > > I would like to know the answer to that question myself. sure it does. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Can pf benefit from multiple cpus?
* pf user <[EMAIL PROTECTED]> [2007-10-26 22:03]: > Henning Brauer wrote: >> * Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 07:36]: >>> Subject says it all: Can pf benefit from multiple cpus? >> no. > > But pf is said to benefit from a larger L2 cache*, my limited research of > reasonably priced CPUs for firewall machines finds that the latest crop of > Intel CPUs have huge honking L2 caches to presumably overcome some other > deficiency... For instance, the Q6600 has 2 x 4MB L2 caches, the new 5400 > series to be announced in November are supposed to have 12MB of L2 cache. > All of them are only available as dual or quad cores though. > > So is L2 cache still an important factor in pf performance with all the > changes that are coming in 4.2 - the rule optimizing and the memory > improvements and late checksumming and things of this nature? well. this statement is not by me, but obviously, having as much as possible of the state table and mbuf + mbuf cluster space in cache of course helps. I bet it helps enourmusly. But how much cache you need ofr that, or where more doesn't make a difference any more, not only depends on your specific application (state table size, pps rates), I don't even have a half-clear idea about what amounts of cache we really talk :) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: linux/iptables/proxy arp to pf/redundant firewall
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-10-26 16:11]: > so u said that u could inject bad things on some level to give trouble and > shake > on stp ? yeah sure. just send a bpdu which makes the switch think it needs to blocksome rather important link. there is no kindof authentication in any form of stp. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Can pf benefit from multiple cpus?
no. kernel runs on one cpu. you cannot change that without solving hundreds or thousands of locking issues. and wether it would be any faster than is all but certain too. * rmkml <[EMAIL PROTECTED]> [2007-10-26 16:32]: > ok maybe is it possible only network interrupt on first proc and pf > (nat/fw) on second proc ? > thx for reply > Regards > Rmkml > > > On Fri, 26 Oct 2007, Henning Brauer wrote: > >> Date: Fri, 26 Oct 2007 13:55:51 +0200 >> From: Henning Brauer <[EMAIL PROTECTED]> >> To: pf@benzedrine.cx >> Subject: Re: Can pf benefit from multiple cpus? >> no. >> >> * rmkml <[EMAIL PROTECTED]> [2007-10-26 13:44]: >>> Hi, >>> maybe it is possible run PF nat on 1 cpu, PF fw on 2 cpu, and for example >>> irq network card on 3 cpu and qos on 4 cpu ? >>> Best Regards >>> Rmkml >>> >>> >>> On Fri, 26 Oct 2007, Henning Brauer wrote: >>> >>>> Date: Fri, 26 Oct 2007 13:06:04 +0200 >>>> From: Henning Brauer <[EMAIL PROTECTED]> >>>> To: pf@benzedrine.cx >>>> Subject: Re: Can pf benefit from multiple cpus? >>>> * Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 07:36]: >>>>> Subject says it all: Can pf benefit from multiple cpus? >>>> >>>> no. >>>> >>>> -- >>>> Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] >>>> BS Web Services, http://bsws.de >>>> Full-Service ISP - Secure Hosting, Mail and DNS Services >>>> Dedicated Servers, Rootservers, Application Hosting - Hamburg & >>>> Amsterdam >>>> >>
Re: Can pf benefit from multiple cpus?
no. * rmkml <[EMAIL PROTECTED]> [2007-10-26 13:44]: > Hi, > maybe it is possible run PF nat on 1 cpu, PF fw on 2 cpu, and for example > irq network card on 3 cpu and qos on 4 cpu ? > Best Regards > Rmkml > > > On Fri, 26 Oct 2007, Henning Brauer wrote: > >> Date: Fri, 26 Oct 2007 13:06:04 +0200 >> From: Henning Brauer <[EMAIL PROTECTED]> >> To: pf@benzedrine.cx >> Subject: Re: Can pf benefit from multiple cpus? >> * Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 07:36]: >>> Subject says it all: Can pf benefit from multiple cpus? >> >> no. >> >> -- >> Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] >> BS Web Services, http://bsws.de >> Full-Service ISP - Secure Hosting, Mail and DNS Services >> Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam >>
Re: linux/iptables/proxy arp to pf/redundant firewall
* Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 10:09]: > Henning Brauer wrote: > > so get a little transfer net and make your upstream adjust his routes > > > > otherwise you need a bridge indeed, but you really want to avoid that > > if you have a chance to go for regular routed with carp etc. > we also run redundant bridges -- we have two physical paths to our ISP > only one of which is ever in use. We have bridges on both these link > and use pfsync to share state. The network uses STP to fail the traffic > between the links. Works well for us. I have never said it does not work. Heck, bridge & (r)stp on OpenBSD are probably better than on most OSes out there. BUT: I hate bridges. They make debugging really darn hard, and come with their own set of problems. (r)stp you cannot run in any remotely secure fashion without filters on the switches (to be honest, you need the same for carp, but there it isn't THAT a disaster because carp uses some crypto, (r)stp does not) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Still dealing with pf performance issues
* Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 07:44]: > I note that "memory" counter is going up at a rate of 0.1/s. My > understanding is that this counter is stepped when pf fails to get > memory for a state entry but we are no where near the state limit: it goes up when pf cannot get memory for something, or something that is somewhat related to memory. grep for PFRES_MEMORY in /usr/src/sys/net. actually, I take that partially back. in 4.2, all PFRES_MEMORY are caused by pool_get failures, except one which is a failing m_copym (and thus a memory error too). the state limit is not too related to that. you can see memory shortage way below your set state limit. I'd say chances are good that 4.2 solves that for you. I bet most of tehse are from memory allocations for pf tags. They are not allocated in 4.2 any more. > Even more of a worry is the congestion counter is at 0.6/s and worse it that is not necessarily a problem. if net.inet.ip.ifq.maxlen is at 50 on your box, 4.2 will solve that too :) (ok. you can just bump it manually too. 4.2 defaults to 256) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Making progress on pf tuning
* Russell Fulton <[EMAIL PROTECTED]> [2007-10-26 06:31]: > I have also been watching the actual counters given by pfctl -si rather > than the rates which remain stubbornly constant no matter what I do. So > even though we now have > > $ sudo pfctl -si | grep congestion > congestion 31640040.6/s > > the congestion counter was 3164004 when I looked first thing this > morning (about 5 hours ago). Something would appear to be amiss with > the rate calculations! nah, teh rate calculation is darn simple, it is counter_total/pf_runtime. it is not a realtime rate or the like. this is probably not optimal. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Can pf benefit from multiple cpus?
* Russell Fulton <[EMAIL PROTECTED]> [2007-10-25 07:36]: > Subject says it all: Can pf benefit from multiple cpus? no. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: linux/iptables/proxy arp to pf/redundant firewall
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-10-24 13:06]: > Selon "Peter N. M. Hansteen" <[EMAIL PROTECTED]>: > > > [EMAIL PROTECTED] writes: > > > > > i was thinking at a bridge firewall with openbsd, and maybe carp to be > > redundant > > > but carp is not working with bridge > > > > I'd think really hard about why you would want to make it a bridge > > then. Bridges generally makes it harder to debug and as you say it > > takes your main redundancy feature off the table. Why not just a > > carp/pfsync setup? > > cause i'm in the same subnet so get a little transfer net and make your upstream adjust his routes otherwise you need a bridge indeed, but you really want to avoid that if you have a chance to go for regular routed with carp etc. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: monitoring performance indicators on pf
* Russell Fulton <[EMAIL PROTECTED]> [2007-10-17 07:43]: > On the monitoring front I have rediscovered symon which I installed when > we first moved to pf years ago but which did not survive an OS upgrade > some time in the past. for monitoring, I use and suggest: -symon -keeping an eye on daily outputs (I actually parse them automagically, but then, you don't want way over a hundred of these per day to read manually) -use /etc/daily.local if you wanna keep an eye on more things -log monitoring. this is very important. I use logsurfer from ports and have *.* |/usr/local/sbin/logsurfer -d /somewhere -s in my syslog.conf on the logserver. -of course, external montoriing, like, ping probes etc - e. g. nagios a subset might do. I have even more :) > One more question: I take it that unintentionally 'dropped packets' > will show up in the interface stats rather then in any pf counters > (which is where I was looking for them)?So symon will show these. well, those dropped at that stage, yes :) in practice, it is good enough to monitor these, and once in a while checking net.inet.ip.ifq.drops and the congestion counter in pfctl -si. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: monitoring performance indicators on pf
* Russell Fulton <[EMAIL PROTECTED]> [2007-10-16 10:03]: > * Is there any tuning that we can do to improve performance of pf yes. install 4.2. seriously, it more than doubles pf performance. > I have heard reports that pf actually performs better on FreeBSD because > some of the NIC drivers are better -- any truth in that? certainly not -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: My PF faults list
* Ilya A. Kovalenko <[EMAIL PROTECTED]> [2007-09-19 16:30]: > 1. States handling > 1.1 Too complex (and weak documented) you must be cofnused here. dunno. people rarely have problems in that area. > 1.2 Too restictive (without option to weak restrictions) > You cannot use PF's stateful inspection, if you're using > asymmetrical and/or dinamic routing well, that is not true as written, but there is some truth to it. It has annoyed me in the past, I plan to fix that somewhen in the future. > 3. Hard to debug ruleset typos >PF silently ignores unknown identifiers for some objects (for >example, tables and queues names), that leave undiscovered posible >typos. > >It is feature, I know, but ?ption to warn user about such possible >errors IMHO would be good idea. i thought we did that with -vv or so > 4. Defaults "keep state" & "flags S/SA" >Considering PF's stateful inspection peculiarities, I noted above, >keeping state by default is not such a good idea ... but it's okay >(no big problem to add "no state" to all or most rules). you are confused. not keeping state is stupid. parts of your mail come pretty offensive... maybe i should not have bothered at all. anyway. you know how things work: if you miss sth, you send a diff. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Real-world production experiences with pf please...
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-05-04 09:12]: > Hi, > > I have some time to come up with a new firewall/router/vpn solution > for our datacentre, and I'm considering a shiny new server with > OpenBSD and pf instead of a costly PIX. On the part of our network > that I'm doing this for we might see maximum 20Mbit/s unencrypted > traffic. > > Is anyone using an OpenBSD/pf solution in a production environment > like this? What hardware are you using? How's it holding up? :-) for breakfast, yeah. with reasonable network cards and a reasonable ruleset pretty much any system made in the last, what, make it 2 years, should able to do several hundred MBit/s. the max I have going thru an OpenBSD box at a customer is in the 750 MBit/s range (and that doesn't max out the machine), but that is without pf and a carefully hand-crafted kernel. with pf, not sure where i have the biggest install... there's certainly customers in the 50 MBit/s range where the machines mostly idle. usually performance is just not a problem, so I don't look at these numbers to closely... our own machines with very big rulesets and pretty mean traffic pattern seldom exceed 50% cpu use either, but desperately need to be upgraded just because of their age (they are in the 1 ghz range) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: using pf to block multiple connections in a given time
* J?r?me Magnin <[EMAIL PROTECTED]> [2007-02-16 21:00]: > you can use expiretable [1] combined with pf to solve this issue. since I added pfctl -t tablename -T expire 3600 to -current/soon 4.1, this is kinda obsolete. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: synproxy create state while no ACK received
* frank hu <[EMAIL PROTECTED]> [2007-02-07 14:31]: > So is it possible to drop every first SYN packet and ask sender to > resend it just like spamd has done? > As such, DoS tool will never create state but legitimate connection > will do. Just some thoughts. :) and to track who has sent the SYN again (or, has sent the ACk, whatever) you need... right, some kind of state. there is no win here. > It ls worth to add some anti-DoS measure in pf now. we have quite a few. I bet you ahven't discovered a 10th of them. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Request for feature: queue assignment for back packets (Was: ACKs queueing)
* Federico Giannici <[EMAIL PROTECTED]> [2006-10-09 12:51]:
> Henning Brauer wrote:
> >* Federico Giannici <[EMAIL PROTECTED]> [2006-10-08 20:32]:
> >>I solved my case in a good way, but I'm currently not using states. I
> >>think that a general, intuitive and efficient solution could be useful.
> >>
> >>The problem: queue assignment of "back" packets of TCP flows when "keep
> >>state" is used and queues are used in both directions. Currently the
> >>only solution seems to be to (almost) replicate the same rules for both
> >>interfaces ("in" and "out"). So the same rules are evaluated two time:
> >>more use of CPU and more rules to maintain.
> >
> >this is untrue, you can just create queues with the same names on both
> >interfaces. queue assignment does not have to happen on the interface
> >where the queue lives.
>
> That's really interesting.
>
> And now the "on _interface_" parameter of the "queue" command start to
> make sense...
well, let me explain (again. I did this before, must be in the
archives).
when a rule matches that has a queue assignment, the packet gets tagged
with the queue name (not really the name, but that is what it comes
down to).
the packet then travels through the system like it always does.
when it hits the outboind queuing stage (i. e. queueing on the
interface where it will leave the machine), the altq routines check for
the tag. if it is not there, the packet goes to teh default queue. if
the tag is there, altq checks wether a queue with that name exists. if
yes, the packet is queued there, otherwise it is put into the default
queue.
you see, it is not like the packets gets put into a queue when a pf
rule assigns it. it happens way later. and thus your cas eis already
covered.
--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Request for feature: queue assignment for back packets (Was: ACKs queueing)
* Federico Giannici <[EMAIL PROTECTED]> [2006-10-08 20:32]:
> I solved my case in a good way, but I'm currently not using states. I
> think that a general, intuitive and efficient solution could be useful.
>
> The problem: queue assignment of "back" packets of TCP flows when "keep
> state" is used and queues are used in both directions. Currently the
> only solution seems to be to (almost) replicate the same rules for both
> interfaces ("in" and "out"). So the same rules are evaluated two time:
> more use of CPU and more rules to maintain.
this is untrue, you can just create queues with the same names on both
interfaces. queue assignment does not have to happen on the interface
where the queue lives.
--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Classification of CPU usage in PF
* Federico Giannici <[EMAIL PROTECTED]> [2006-10-08 20:11]: > Henning Brauer wrote: > >* Federico Giannici <[EMAIL PROTECTED]> [2006-10-08 16:21]: > >>I'm trying to re-phrase this question too: is the PF code executed > >>during the NIC interrupts? > > > >not really, it is executed in soft int context > > Hummm... > Just to be sure, I'm re-re-phrasing it: in which of the four CPU states > shown by "top" it is assigned (interrupt, system, nice, user)? int > And I presume that the same applies to ALTQ. Do it? yup, although altq runs way later -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Classification of CPU usage in PF
* Federico Giannici <[EMAIL PROTECTED]> [2006-10-08 16:21]: > I'm trying to re-phrase this question too: is the PF code executed > during the NIC interrupts? not really, it is executed in soft int context -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Using BGP to multihome on links of different bandwidth
* Alex Thurlow <[EMAIL PROTECTED]> [2006-07-26 06:11]: > New to the list, and with a question I can't seem to find an answer to > anywhere else. A little preface - I have recently switched jobs, so I > am in a new network situation. There are some upcoming changes, and I > wish to switch from our current Linux router to OpenBSD-pf. > > We currently have 2 links that are shared via BGP. One is an OC-12, and > the other is 100Mb ethernet. The reason we have lines of unmatched > speed is that we could get the 100Mb cheap and are wanting to test the > usefulness of multihoming. > > Under just a normal BGP setup, our 100Mb line would be saturated as it > attempted to send traffic there based on routing distance. Because of > this, there are IPtables rules that count how many pps are going on the > 100Mb line, and if there are over a certain amount, they mangle the > packets and send them over the OC-12 instead. In this way, we are able > to share these 2 lines of differing bandwidth. I would just play with local-preference based on source AS for a few big ASes to move them to the OC-12 line and do that until the usage is somewhat balanced. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: pfctl rtlabel expansion
* sfp <[EMAIL PROTECTED]> [2006-07-06 17:32]: > > "Henning Brauer" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > * sfp <[EMAIL PROTECTED]> [2006-07-06 08:22]: > > > Using bgpd to apply labels to prefixes using rtlabel. Given the pf.conf > > > statement: > > > > > > pass in on $int_if02 from route "test" to any keep state > > > > > > How can I see the (rt)labelled prefixes that are actually being acted > upon > > > using pfctl? > > > > you cannot. > > Hmmm > > > > > > When the same statement is (pf)labelled, pfctl fails to expand > > > the prefixes as well. > > > > I cannot parse that sentence ;( > > Sorry if that was ambiguous. If a packet that is identified using 'from > route "test"' is subsequently labelled in pf with 'label > V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport"', there is still no way to > tell which prefix that packet originated from; as evidenced by pfctl -sl: > > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > Is this normal, or have I made a syntactical error? the rule label macros are expanded at ruleset load time, so the information in tehm is pretty static. > > > pass in on $int_if02 from route "test" to any keep state label > > > "V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport" > > > > > > [EMAIL PROTECTED] ~]# pfctl -sl > > > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > > > > > I would prefer not to use a table in pf as prefixes are not removed when > > > they are withdrawn by bgpd. > > > > so you want to label teh routes, and be able to see the route label in > > the pf label for accounting purposes? > > No. I want to be able to make certain that pf is filtering on prefixes that > are valid according to bgpd, and that prefixes that have been withdrawn by > the bgp process are no longer going to be permitted in the ruleset. While > it's true that pf won't necessarily see such packets since the box wouldn't > have a route, it makes troubleshooting more difficult, particularly in the > reverse case of dropped packets. How do I know that a prefix is being acted > on? pf cannot tell me. > > It's not that I don't trust pf's mechanisms, but this seems to be a bit of a > shortcoming - not being able to identify which prefixes 'from route ' > actually refers to. that doesn't make sense, sorry. when you have a rule that refers to a route label pf does a route lookup for the src or dst IP on the routing table, looks for the label and if it is there see if there's a match, then moves on. since the routing table and the packet flows are highly dynamic there pretty much is no way of manually verifying pf does things correctly, you have to trust it here. btw, in your case, a block in from no-route block out to no-route should suffice. > > > Outside of pf, the man pages for route(8) & netstat(1) do not indicate > flags > > > for displaying the kernel routing table based on the label alone. I may > > > have missed it. In the absence of route show synxtax, is there a valid > > > wildcard for 'route get'? > > no. you can't get a list of prefixes by label right now. > Cool. Is support for this planned in the near or distant future? The 3.7 > release notes (http://www.openbsd.org/plus37.html) make mention of route(8) > being able to show labels: > > Display route labels with route(8)'s show command. > > Are these not the same labels, or is the above referring to something else > (route get?). No mention in 3.8 or 3.9 release notes. I'm running 3.9. route show shows labels. you cannot use a label as filter criteria for which routes to display right now. it would make sense tho. I have no plans to implement this in the near future, but a patch would be welcome :) > Thx for the info & nice work on OpenBGPD Henning. as always, we're looking for more success stories for http://www.openbgpd.org/users.html ;) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: pfctl rtlabel expansion
* sfp <[EMAIL PROTECTED]> [2006-07-06 08:22]: > Using bgpd to apply labels to prefixes using rtlabel. Given the pf.conf > statement: > > pass in on $int_if02 from route "test" to any keep state > > How can I see the (rt)labelled prefixes that are actually being acted upon > using pfctl? you cannot. > When the same statement is (pf)labelled, pfctl fails to expand > the prefixes as well. I cannot parse that sentence ;( > > Eg > > pass in on $int_if02 from route "test" to any keep state label > "V115PERMIT:$proto:$srcaddr:$dstaddr:$dstport" > > [EMAIL PROTECTED] ~]# pfctl -sl > V115PERMIT:ip:?:any: 2 37 6334 21 2781 16 3553 > > I would prefer not to use a table in pf as prefixes are not removed when > they are withdrawn by bgpd. so you want to label teh routes, and be able to see the route label in the pf label for accounting purposes? > Outside of pf, the man pages for route(8) & netstat(1) do not indicate flags > for displaying the kernel routing table based on the label alone. I may > have missed it. In the absence of route show synxtax, is there a valid > wildcard for 'route get'? no. you can't get a list of prefixes by label right now. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF inadequacy: queue download
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2006-05-01 02:50]: > I don't think time spent developing PF or ALTQ could be better spent > developing something other than download queueing. it's nice that you think so. now, let me tell you some news: it does not matter what you think. what matters is what we think, the ones that write the code. when we see a clean, well written diff that implements this and makes sense, we might incorporate that. maybe you could get one of us to code that if you fund him to do that (let me tell you beforehands that you're looking at a 4 digit number for sure). endless whining here will make sure we'll never implement it unless we have a reallyt urgent need. since we hadn't had that in the past, what, 4 years, it's kinda unlikely that changes. I'll summarize again for you. pick one: 1) submit a diff 2) pay a developer to do it 3) get over it note that "continue whining on the mailing lists and annoy developers enough so that they eventually might unsubscribe" is not on the list. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF and label expansion limitations
* Per-Olov Sj?holm <[EMAIL PROTECTED]> [2006-04-06 00:31]: > The PF rule... > pass in quick on $EXTERNAL_INT inet from any to $COLOC_IPS_1 label > "TEST:$dstaddr#" keep state > > Gives a label like > TEST:65.45.128.128/25# 230 3099 1511793 1370 148914 1729 1362879 > > > Is there an easy way to do expansion of $COLOC_IPS_1 so that the single > rule above give labels like... > TEST:65.45.128.128/1# 230 3099 1511793 1370 148914 1729 1362879 > TEST:65.45.128.128/2# 230 3099 1511793 1370 148914 1729 1362879 > TEST:65.45.128.128/3# 230 3099 1511793 1370 148914 1729 1362879 > TEST:65.45.128.128/4# 230 3099 1511793 1370 148914 1729 1362879 > TEST:65.45.128.128/n# 230 3099 1511793 1370 148914 1729 1362879 > TEST:65.45.128.128/n+1# 230 3099 1511793 1370 148914 1729 1362879 > TEST:65.45.128.128/254# 230 3099 1511793 1370 148914 1729 1362879 > > > This so we could measure each customers dedicated server statistics. > > > If not. Anybody with a good suggestion? > I know I can add all IPs separately to pf.conf to have these inividual > labels. But that is the last option. It would be really nice if we could > do label expansion of an IP block instead.. > > Possible today or eventual feature request? not possible today, and not easily to be done at all. I think that we need to go to better netflow support for accounting purposes. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF and load
* Per-Olov Sj?holm <[EMAIL PROTECTED]> [2006-04-05 21:50]: > Henning Brauer wrote: > >* Per-Olov Sj?holm <[EMAIL PROTECTED]> [2006-03-31 18:11]: > >>Can PF make use of SMP? > >no. > So a faster cpu (not another cpu) is the only way if we will see to much > cpu usage caused by interrupts then... ? > (if we already have quality nics and hopefully an optimized ruleset) faster single CPU, better NICs, improvements in the software :) > Or are there other things to start to look at if the interrupt usage is > high? Are there for example better nics than our dual gig intel nics? yes, sk(4) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF and load
* Per-Olov Sj?holm <[EMAIL PROTECTED]> [2006-03-31 18:11]: > Can PF make use of SMP? no. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF not keeping state
* Kevin <[EMAIL PROTECTED]> [2005-12-19 10:30]: > With the complexities and such introduced by CARP and the VLANs, it > sounds like you might want to try something like: > > > set state-policy if-bound this is extremely bad advice. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: please publish SPF records
* ed <[EMAIL PROTECTED]> [2005-11-03 19:38]: > On Thu, 3 Nov 2005 15:30:12 +0100 > Henning Brauer <[EMAIL PROTECTED]> wrote: > > it is broken no matter what and deserves to be ignored at least, or > > better yet, actively faught. > It's not entirely broken though. no. it is even worse. > DK is worth a look too, but it's added components to a mail > server. DomainKeys (as in, the original proposal) actually makes a lot of sense and does solve the problem it claims to solve without the gigantic colliteral damage that makes spf worse than useless.
Re: please publish SPF records
* ed <[EMAIL PROTECTED]> [2005-11-02 22:47]: > On Wed, 02 Nov 2005 20:38:22 +0100 > Vincent Immler <[EMAIL PROTECTED]> wrote: > > thanks in advance ;-) > SPF can be very broken with mail lists. it is broken no matter what and deserves to be ignored at least, or better yet, actively faught. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: no NAT, all public ip address
* Neil <[EMAIL PROTECTED]> [2005-10-05 00:10]: > So are you saying that failover will still work on a route setup? eh, yes, of course. in fact, I have never used carp with nat. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: CARP and switches
* Charles Sprickman <[EMAIL PROTECTED]> [2005-09-29 22:51]: > The design seems to assume that one MAC address can > only exist on one port at a time, correct? no, not at all. There have been so-called multicast MAC addresses from the stone age on, and that is what carp uses. besides, switches work exactly the other way around. they have a list of mac addresses, and a list of ports associated with each. look for the broadcast mac address entries for example: (output from an extreme networks switch, slightly obfuscated, lots of other addresses and other vlans cut) swi010:2 # show fdb Index Mac Vlan Age Flags Port List --- 0f000-fdf: ff:ff:ff:ff:ff:ffDefault(0001) s m CPU 0f020-fd9: ff:ff:ff:ff:ff:ff somevlan(0003) s m CPU,29, 49, 17, 45, 14, 25, 15, 13, 16, 23, 20, 26 0f030-fd7: ff:ff:ff:ff:ff:ffanother(0002) s m CPU,28, 29, 49, 19, 39, 37, 24, 22, 21, 46 0f040-fdd: ff:ff:ff:ff:ff:ff yetanother(0005) s m CPU,49, 38, 18, 48 0f050-fdb: ff:ff:ff:ff:ff:fffoo(0004) s m CPU,29, 49, 2, 12, 7, 8, 6, 9, 4, 5, 3, 1, 11 same goes for the switch's own MAC addresses, and - yes, multicast addrs. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: benefits of 'set state-policy if-bound'
whoa, get some things straight here. an if-bound state policy provides no benefits whatsover, unless you absolutely need (usually: certain rules only) states to be bound to interfaces because you are doing weird things with route-to and stuff. leave it off unless you need it. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: [Fwd: Re: nat ip mac]
* Daniel T. Staal <[EMAIL PROTECTED]> [2005-08-15 18:31]: > > how can I create a single nat rule to allow nat to a single machine > using source IP and source MAC > > > > nat on xl0 from 10.1.1.1 to any -> 200.200.200.1 > > > > but I would like to allow just 10.1.1.1 using the MAC address > > 00:ff:0f:ba:54:00. > > > > how can I do it ? with a grain of brain and # arp -s 10.1.1.1 00:ff:0f:ba:54:00 permanent -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: Label-based accounting and keeping state won't mix.
* Sven Ingebrigt Ulland <[EMAIL PROTECTED]> [2005-08-03 09:23]: > On Tue, Aug 02, 2005 at 10:27:57PM +0200, Henning Brauer wrote: > > * Tihomir Koychev <[EMAIL PROTECTED]> [2005-08-02 12:11]: > > > there is patch in current > > > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/pfctl.c > > > which allow counting in/out packets + in/out bytes > > > from labels. > > that is ENTIRELY unrelated to the OPs question. and the pfctl part is, > > well, only a part of it, and the smaller one. > However unrelated, I think it might have been what I was > actually looking for. I gave up trying to patch all the > individual files, and upgraded to the 3.7 snapshot as of > 20th july. Now I'm a happy hippo fiddling with all the > counters I could ever want. It's your work, right, Henning? yeah. entirely hacked on a ferry ride on canada's west coast :) > Good job. thanks -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: Label-based accounting and keeping state won't mix.
* Tihomir Koychev <[EMAIL PROTECTED]> [2005-08-02 12:11]: > > Does this mean that basic label-based IP accounting > > won't mix with > > keeping state at all? no, states have a pointer back to the rule that created it and update the stats on it. > there is patch in current > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/pfctl.c > which allow counting in/out packets + in/out bytes > from labels. that is ENTIRELY unrelated to the OPs question. and the pfctl part is, well, only a part of it, and the smaller one. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: 400Mbps PF based firewall, which hardware?
* Rob <[EMAIL PROTECTED]> [2005-07-09 13:48]: > Henning Brauer wrote: > >* Gustavo A. Baratto <[EMAIL PROTECTED]> [2005-07-08 17:34]: > > > >>Aparently gigabit intel NICs are the best out there, but this is just > >>what I've heard. > > > > > >sk is far better. > > It looks like from the study quoted on the sk website: > http://www.syskonnect.com/syskonnect/performance/gig-over-copper.htm > that the 3Com 3c996BT outperforms the sk at 1500 MTU for most of their > tests. > > Another comparison: > http://www.accs.com/p_and_p/GigaBit/ the 3com seems to be a bge - not exactly first choice, to put it nicely. I don't get what syskonnect they tested, I am not certain this even is an sk. nontheless these test are completely irrelevant. this is not redhat 7.3, and the driver has a great share in performance. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: 400Mbps PF based firewall, which hardware?
* Siju George <[EMAIL PROTECTED]> [2005-07-09 15:50]: > Since your network is only 100Mpbs my recommendation is a dlink ehternet card. no, there is really no reason to buy 100MBit/s cards at all any more if you have the slightest interest in performance. all gigE chips (well, maybe except nge) are better. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: 400Mbps PF based firewall, which hardware?
* Gustavo A. Baratto <[EMAIL PROTECTED]> [2005-07-08 17:34]: > Aparently gigabit intel NICs are the best out there, but this is just what > I've heard. sk is far better. > -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: Newbie question.
* Kelley Reynolds <[EMAIL PROTECTED]> [2005-06-22 15:24]: > One thing to note on a semi-related topic is that when specifying > subnets in tables, as of 3.7-RELEASE, subnets that weren't /24 (or > probably /16 or /8) didn't work. I highly doubt that (and it is the first time I hear this)
Re: Fwd: Re: pf stopped working i think... WORKS. specifying loopback device "lo" no longer works in pf.conf though
* j knight <[EMAIL PROTECTED]> [2005-06-08 18:01]: > b h wrote: > > >pass quick on lo all > > > >used to work before the hackathon. > > > >pass quick on lo0 all > > I'm not sure if I just missed it or if you didn't mention it, but I > didn't realize you were running -current. There's lots of work ongoing > in -current on interface groups. Henning is doing some neat stuff; it's > going to be really cool when he's finished. Until quite recently, the > "interface family" group didn't exist. You're probably running a > snapshot where that's the case. You should be good to go with a recent > -current. atually, the interface family groups have been there for a long time... more or less. they are now there for cloned interfaces like tun, ppp, vlan and the like, but not for hardware interfaces like sk, em etc where they just don't make sense. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: keep state is not keeping state - for one rule
* Jon Hart <[EMAIL PROTECTED]> [2005-05-04 14:35]: > but you should definitely > be specifying which combination of TCP flags can create the initial > state here. Try "flags S/SA" as a start. no, this is bad advice and certainly not related to the problem. this whole flags filtering is mostly masturbation. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: State/queue question
* J. Martin Petersen <[EMAIL PROTECTED]> [2005-04-23 10:49]:
> Henning Brauer wrote:
> > * Kelley Reynolds <[EMAIL PROTECTED]> [2005-03-21 19:40]:
> >
> >>This has come up a few times on the list, and I was wondering how difficult
> >>it would be to alter the pf syntax so that a stateful rule on a firewall
> >>could apply queues on two interfaces so that bidirectional queueing can be
> >>done while tracking state?
> >>
> >>I believe (and please correct me if I'm wrong) that to get bi-directional
> >>queueing, one must have a seperate rule per interface and not keep state
> >>since that would be a single rule (this limiting the state-associated
> >>packets to a single queue, one interface or the other)
> >
> >
> > huh? you should create state and just create queues by the same names n
> > different interfaces, it'll Just Work
>
> Was this introduced recently?
no.
> When I try something something like
>
> altq on $mci_if cbq bandwidth 28Mb qlimit $qs queue { serv bulk}
> queue serv bandwidth 20% priority 6 cbq(borrow)
> queue bulk bandwidth 80% priority 5 cbq(borrow)
>
> altq on $mbh_if cbq bandwidth 28Mb qlimit $qs queue { serv bulk}
> queue serv bandwidth 20% priority 6 cbq(borrow)
> queue bulk bandwidth 80% priority 5 cbq(borrow)
you are specifying teh queues twice.
altq on { $mci_if $mbh_if } cbq bandwidth 28Mb qlimit $qs queue { serv
bulk}
queue serv bandwidth 20% priority 6 cbq(borrow)
queue bulk bandwidth 80% priority 5 cbq(borrow)
will work, or you can limit queue specifications to a certain
interfaces as well, aka queue blah on $someinterface
> Or have I just misunderstood how I should create the queues?
yes.
Re: Feature request - setting TOS
* Kimi Ostro <[EMAIL PROTECTED]> [2005-04-17 17:37]: > On 4/15/05, Henning Brauer <[EMAIL PROTECTED]> wrote: > > last time we looked into that we didn't come up with a good keyword if > > memory serves, and the usefullness was a bit questionable. I have no > > strong opinion here, but without the right keyword this is not going to > > fly no matter what. > > Do we really need keywords for anything other than the most common TOS's? nah, I think we have that already for filtering on tos (or was it numeric only? I had to check). not sure wether pass in on $some_if keep state set-tos 0x10 would be any good maybe set tos doesn't fit well with the current grammar either
Re: Feature request - setting TOS
* Steven Philip Schubiger <[EMAIL PROTECTED]> [2005-04-15 10:51]: > On 13 Apr, Lars Hansson wrote: > > : Naturally TOS is only really usefull on your own network. If you have a > : fairly large internal network, say a campus of some sort, being able to > : mark packets with TOS and also assign packets to queues depending on > : TOS value can come in very handy. > > Could the usability of such an addition be confirmed by familiar > developers, before we step further? last time we looked into that we didn't come up with a good keyword if memory serves, and the usefullness was a bit questionable. I have no strong opinion here, but without the right keyword this is not going to fly no matter what. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: Pfctl for non-root users
* Matt Rowley <[EMAIL PROTECTED]> [2005-04-11 14:05]: > I don't believe it's ever been possible to run pfctl as non-root it is possible and desirable to run pfctl -n as non-root. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: Pfctl for non-root users
* Jason Dixon <[EMAIL PROTECTED]> [2005-04-11 11:06]: > Is the ability to run pfctl (via sudo) as a non-root user still broken? that was never broken. > I've tested this on a 3.6 -release system, and /dev/pf is still > unavailable for non-root users. and that was always the case and likely will not change. > I searched the archives and found > mention of this about a year ago, but nothing else since. you probably found that pfctl -n was broken for a bit as non-root user Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF and IP Precedence
* John Merriam <[EMAIL PROTECTED]> [2005-03-24 16:31]: > What exactly does PF think 'lowdelay' is though? IPTOS_LOWDELAY of course, dunno the numeric value tho > I found buried in the pf.conf man page that I should be able to specify > a TOS value using something like: > > pass out on IF inet proto tcp from any to any tos 0xYY keep state queue > QUEUE > > where YY is, I assume, the hexadecimal TOS byte. with that you can limit the whole rule to matching those indeed > If PF gives priority to packets based on thier IP precedence/DSCP value > automaticly that is not what I said -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: PF and IP Precedence
* John Merriam <[EMAIL PROTECTED]> [2005-03-23 17:50]:
> Hello. I'm using PF on FreeBSD 5.3. I would like to know how PF
> handles precedence information in IP packets. I'm referring to the
> header data described in RFC 1812 sections 5.3.2 and 5.3.3 (part of TOS
> byte).
>
> I guess the first question would be, does PF handle precedence
> automatically?
>
> If not, can prioritization based on IP precedence be achieved with ALTQ
> or some other mechanism?
yes, you can specify two queues per rule, one we call "priority queue",
and packets with precedence set to lowdelay go to said prio queue.
it's not like the manpage wouldn't document that of course
Packets can be assigned to queues based on filter rules by using the
queue keyword. Normally only one queue is specified; when a second one
is specified it will instead be used for packets which have a TOS of
lowdelay and for TCP ACKs with no data payload.
To continue the previous example, the examples below would specify the
four referenced queues, plus a few child queues. Interactive ssh(1) ses-
sions get priority over bulk transfers like scp(1) and sftp(1). The
queues may then be referenced by filtering rules (see PACKET FILTERING
below).
queue std bandwidth 10% cbq(default)
queue http bandwidth 60% priority 2 cbq(borrow red) \
{ employees, developers }
queue developers bandwidth 75% cbq(borrow)
queue employees bandwidth 15%
queue mail bandwidth 10% priority 0 cbq(borrow ecn)
queue ssh bandwidth 20% cbq(borrow) { ssh_interactive, ssh_bulk }
queue ssh_interactive priority 7
queue ssh_bulk priority 0
block return out on dc0 inet all queue std
pass out on dc0 inet proto tcp from $developerhosts to any port 80 \
keep state queue developers
pass out on dc0 inet proto tcp from $employeehosts to any port 80 \
keep state queue employees
pass out on dc0 inet proto tcp from any to any port 22 \
keep state queue(ssh_bulk, ssh_interactive)
pass out on dc0 inet proto tcp from any to any port 25 \
keep state queue mail
--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: State/queue question
* Kelley Reynolds <[EMAIL PROTECTED]> [2005-03-21 19:40]: > This has come up a few times on the list, and I was wondering how difficult > it would be to alter the pf syntax so that a stateful rule on a firewall > could apply queues on two interfaces so that bidirectional queueing can be > done while tracking state? > > I believe (and please correct me if I'm wrong) that to get bi-directional > queueing, one must have a seperate rule per interface and not keep state > since that would be a single rule (this limiting the state-associated packets > to a single queue, one interface or the other) huh? you should create state and just create queues by the same names n different interfaces, it'll Just Work -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Re: pf vs ASIC firewalls
* Greg Hennessy <[EMAIL PROTECTED]> [2005-03-17 19:31]: > On 17 Mar 2005 03:58:26 -0800, [EMAIL PROTECTED] (Henning Brauer) wrote: > > > >> All of that said, I wonder if there isn't some way to implement > >> something vaguely PF-ish in an FPGA that would allow more control over > >> the rulesets than an off-the-shelf ASIC. > > > >there likely is... > >I mean, state table and state table lookups in hardware, hand off > >ruleset processing to the main CPU, that would rock. If done right. > > Be interesting to see if that was possible using commodity offload hardware > such as that found in > > http://www.nvidia.com/object/feature_activearmor.html well that is just marketing bullshit as far as i can tell -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: pf vs ASIC firewalls
* Jim Fron <[EMAIL PROTECTED]> [2005-03-17 08:46]:
> On Mar 14, 2005, at 2:26 PM, Mike Frantzen wrote:
> >>Could Someone please tell me the advantages of PF against Firewalls
> >>using the ASIC technology in terms of Security and perfomance??
> >Many (most? all?) vendors shipping what they call ASIC firewalls are
> >actually running software on a network processor (NPU). The benefit is
> >that most NPUs will process packets in real-time so if they claim to
> >support X gigabit per second then they can probably sustain that even
> >with minimum sized 64byte ethernet frames;
> You think? I've been a bit curious about this, especially in the
> low-end ("cheap") consumer-grade hardware.
Mike was obviously not talking about low-end stuff.
well, this entire thread is not about low-end shitz
> I have no idea if the BSD's--or any general-purpose host OS, for that
> matter--will, for example, prevent logging to disk during bursts of
> traffic. Perhaps there's a kernel option for priority of servicing
> i/o.
(almost all of the) logging happens in userland
> All of that said, I wonder if there isn't some way to implement
> something vaguely PF-ish in an FPGA that would allow more control over
> the rulesets than an off-the-shelf ASIC.
there likely is...
I mean, state table and state table lookups in hardware, hand off
ruleset processing to the main CPU, that would rock. If done right.
--
Henning Brauer, BS Web Services, http://bsws.de
[EMAIL PROTECTED] - [EMAIL PROTECTED]
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
Re: PF, Bridge, and IP on bridged interface [more]
* Sean Kamath <[EMAIL PROTECTED]> [2005-03-15 06:40]: > So, I guess that leaves the question, can one change the ethernet > address of a NIC with ifconfig on OpenBSD? no. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Good HFSC explanation
* John Ricardo <[EMAIL PROTECTED]> [2005-03-11 06:02]: > Thanks for the answer. > > Can you shed any light on my other question, namely (quoting myself): > > "So with fully-specified service curves, does HFSC as implemented here > in fact superimpose CBQ-style hierarchical priorities ontop, or do the > service curve specifications somehow mean that also giving "priority" > doesn't makes sense?" priority still makes sense. priority mostly influences latency, the service curve specifications throughput. of course they are not really independent from each other. hfsc with only the linkshare sc defined is like cbq. the realtime sc set a lower limit, and the upperlimit sc ... well, guess. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Good HFSC explanation
* John Ricardo <[EMAIL PROTECTED]> [2005-03-05 11:22]: > If you have specified the 3 service curves, the "bandwidth" keyword is > redundant and/or unnecessary? true. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: When does a table outperform a list?
* Bob <[EMAIL PROTECTED]> [2005-02-16 18:40]: > In my ruleset, I've only defined a table for a huge list of IP addresses > belonging to adservers. I've no doubt that a table will perform better > than a list in this case. > > But when does a table begin to outperform a list? I imagine a list is > quicker when the list contains two or three items, but at what point > would it be more efficient to put the items into a table? the borderline should be somewhere between 5 and 10 entries.
Re: macros and anchors SOLVED
* Peter Huncar <[EMAIL PROTECTED]> [2005-02-02 22:20]: > Is it planned to include the 'include keyword' ;o) into the next release? it is believed that anchors and the load anchor statement solve that more elegantly. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Is there any plan to add the time based filtering feature in PF
* Siju George <[EMAIL PROTECTED]> [2005-01-28 10:50]: > I would like to know if there is any plan among PF developers to add > the feature to filter traffic based on time. no. cron. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: First time user comments
* Peter Fraser <[EMAIL PROTECTED]> [2005-01-24 18:40]: > Parsers I know, I am assuming that pf is using Bison. using yacc, of course. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: First time user comments
* Peter Fraser <[EMAIL PROTECTED]> [2005-01-21 00:54]: > Could the "syntax error" message, give the position in the line that the > error occurred, or at least the token that caused it. no - that is not how parsers work. syntax error actually says it didn't match any production from the grammar. if we don't know what production it should have matches, how should we tell which part didn't? that is just not how parsers work, sorry. > I believe that not > supplying a "on " means the statement applies to all > interfaces. yes. > It would be nice if there is only one interface type on the computer to > define a macro automatically for them, I suggest $id0 $id1 etc. That way > pf config files could be more portable, particularly in the case of a > server machine that only has one interface. that will be solved by interface groups. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Using DNS names in pf.conf?
* Kevin <[EMAIL PROTECTED]> [2005-01-19 21:41]: > Are there any "gotchas" I should know about when using dns names in > pf.conf, specifically in tables used as destinations for permit rules? well, if DNS is not available by the time pfctl tries to load your pf.conf you're pretty much screwed. and pf is enabled very early at boot. try it out, and most importantly, get clear about the external dependencies you introduce and their consequences. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: feature suggest: ability to load/add _inverted_ table file
* Ilya A. Kovalenko <[EMAIL PROTECTED]> [2004-12-22 02:20]: >Here is diff (against 3.6-stable), that implements loading list to table > in inverted form, by rule like this: > > table file priv_nets.tab file-inv pub_hosts.tab > >Unfortunately, it demands more changes, than I expected :(, so I don't > think that it has a chance to be accepted. correct. I'll veto any change for this, no matter how leightweight it is. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Re[3]: feature suggest: ability to load/add _inverted_ table file
* Ilya A. Kovalenko <[EMAIL PROTECTED]> [2004-12-22 02:06]: > More correct & shorter diff, against -current (21.12) give it up. it will not go in ever.
Re: feature suggest: ability to load/add _inverted_ table file
* Ilya A. Kovalenko <[EMAIL PROTECTED]> [2004-12-20 08:01]: > I suggest to add pfctl(8) feature. > > Feature to load/add address list from file onto table in INVERTED > form (i.e. replacing "A.B.C.D" -> "! A.B.C.D" & vice versa) from > table rule (sth. like "file-inverted ") and command line > (sth. like -T add-inverted/load-inverted). > > It is quite simple to implement (I think/believe), but make tables > more more flexible. > > Later, I can post related code diff. I don't see the point. awk/sed/.. etc are your friends. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
