Re: Native EFI Bootloader Support
On Fri, Sep 04, 2015 at 11:22:48AM -0700, Chris Cappuccio wrote: > Since the purpose of Secure Boot provide little to no benefit to users > (in fact quite the opposite), the question becomes why? > For paranoid softraid crypto users who are concerned about a modified bootloader leaking their softraid key.
Re: MinnowBoard MAX
On Mon, Jul 28, 2014 at 08:28:04PM -0500, Stan Gammons wrote: A fellow from Intel told me they are coming out with Coreboot firmware for the Minnowboard max, no ETA other than soon, and he didn't know if any of the BSD's would work with it. He said the forthcoming FreeBSD 11 almost boots with the Minnowboard max as is. It seems OpenBSD 5.7-beta boots fine on the Minnowboard Max with coreboot. You can read my account of the current status here: http://www.countersiege.com/2015/02/22/minnowboard_max_openbsd.html -Ryan
Re: Goodbye to you my file descriptor - take 3
On Mon, Dec 31, 2012 at 04:53:15PM +1100, Aaron Mason wrote:
Ok, I just tried freeing NULL, and it did nothing. Granted it was on
a Linux system but still...
free() handles a NULL pointer by doing nothing, and it will behave this
way on any posix system compliant system. However, on an OpenBSD system
you could have actually read the documentation to check this.
I stand by my argument that there's no clear improvement, especially
on a modern system.
In my opinion it's marginally simpler to read and less likely to result
in a future cut-n-paste error.
On Mon, Dec 31, 2012 at 4:50 PM, Aaron Mason simplersolut...@gmail.com
wrote:
Maxime
I'm not entirely clear on what you hoped to achieve with the diffs
below, if anything you're inducing possible segfaults if any of those
values are NULL. That aside, I fail to see how this could be
construed as any sort of improvement.
Index: pfctl_osfp.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_osfp.c,v
retrieving revision 1.18
diff -u -r1.18 pfctl_osfp.c
--- pfctl_osfp.c18 Oct 2010 15:55:28 - 1.18
+++ pfctl_osfp.c22 Dec 2012 07:08:28 -
@@ -112,16 +112,11 @@
while ((line = fgetln(in, len)) != NULL) {
lineno++;
- if (class)
- free(class);
- if (version)
- free(version);
- if (subtype)
- free(subtype);
- if (desc)
- free(desc);
- if (tcpopts)
- free(tcpopts);
+ free(class);
+ free(version);
+ free(subtype);
+ free(desc);
+ free(tcpopts);
class = version = subtype = desc = tcpopts = NULL;
memset(fp, 0, sizeof(fp));
@@ -250,16 +245,11 @@
add_fingerprint(dev, opts, fp);
}
- if (class)
- free(class);
- if (version)
- free(version);
- if (subtype)
- free(subtype);
- if (desc)
- free(desc);
- if (tcpopts)
- free(tcpopts);
+ free(class);
+ free(version);
+ free(subtype);
+ free(desc);
+ free(tcpopts);
fclose(in);
@@ -513,7 +503,7 @@
return (buf);
found:
- snprintf(buf, len, %s, class_name);
+ strlcpy(buf, class_name, len);
if (version_name) {
strlcat(buf, , len);
strlcat(buf, version_name, len);
Index: pfctl_radix.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_radix.c,v
retrieving revision 1.29
diff -u -r1.29 pfctl_radix.c
--- pfctl_radix.c 27 Jul 2011 00:26:10 - 1.29
+++ pfctl_radix.c 22 Dec 2012 07:08:28 -
@@ -499,8 +499,7 @@
{
if (b == NULL)
return;
- if (b-pfrb_caddr != NULL)
- free(b-pfrb_caddr);
+ free(b-pfrb_caddr);
b-pfrb_caddr = NULL;
b-pfrb_size = b-pfrb_msize = 0;
}
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: Low latency High Frequency Trading
My immediate reaction is don't do it, but on the other hand I've never known people for whom 'money is not a problem' to shy away from something because of boring concerns like security. So... Software: Basically, to do this correctly you need to parse all the packets running in both directions between the two endpoints, tracking the acks and correctly emulating the behaviour of the TCP stacks on both sides to determine what is valid data to convert to UDP. Things to think about: - IP fragment reassembly - duplicate packets - out of order packets - lost packets - TCP resends - TCP checksums - IP checksums - TCP sequence number validation - etc, etc. Look at pf_normalise_state_tcp() in pf_norm.c and pf_test_state_tcp() in pf.c for a small taste of the scope of what you're considering if you want to write this in the kernel. Further examples for TCP reassembly could be found in the source code for ports/net/snort or ports/net/tcpflow. Of course you can take some shortcuts if you assume that the data you're getting is clean, and even more if you don't have to parse the TCP stream but can handle each individual TCP packet as an individual payload. Perhaps your current problematic implementation already does this? If so, it's also probably trivial to inject bogus data into the stream and have it accepted. Maybe that's a feature. Remember: Lots of attacks can be performed against this hacked up monstrosity unless everything is exactly perfect. Good luck with the frankenstein code, it's not supported. Hardware: - NIC: something that allows you to adjust the interrupt rate, e.g. em, bnx. On the other hand if the packet rate is not too high a cheaper network card without any bells and whistles might give you better performance (less overhead in the interrupt handler). I'd say you'd be best off buying a bunch and testing them. - CPU: maximum SINGLE CORE turbo speed. Disable the other cores, they're not helping you at all; in theory you want the biggest, fastest cache possible, but perhaps not necessary depending on how much software you're running. - Fast RAM might help, but you don't need much. probably the minimum you can get in a board with the above CPU. Also, remember to use the shortest patch cables possible, to reduce signal propagation latency. On Thu, Nov 08, 2012 at 08:08:05PM +0200, Dan Shechter wrote: For unrelated reasons, I can't directly receive the TCP stream. I must copy the TCP data from a running stream to another server. I can use tap or just port-mirroring on the switch. So I can't use any network stack or leverage any offloading. I also need to modify the received data, and add few application headers before sending it as a multicast udp stream. Winsock is userland. What I want to do is in the kernel, even before ip_input. I guess it should be faster. On Thu, Nov 8, 2012 at 7:36 PM, Johan Beisser j...@caustic.org wrote: On Thu, Nov 8, 2012 at 4:12 AM, Dan Shechter dans...@gmail.com wrote: Hi All, current situation A windows 2008 server is receiving TCP traffic from a stock exchange and sends it, almost as is, using UDP multicast to automated high frequancy traders. StockExchange --TCP--- windows2008 ---MCAST-UDP On average, the time it take to do the TCP to UDP translation, using winsock, is 240 micro seconds. It can even be as high as 60,000 micro seconds. /current situation my idea 1. Use port mirroring to get the TCP data sent to a dedicated OpenBSD box with two NICs. One for the TCP, the other for the multicast UDP. You'll incur an extra penalty offloading to the kernel. Winsock is already doing that, though. 2. Put the TCP port in a promiscuous mode. Why? You can just set up the right bits to listen to on the network, and pull raw frames to be processed. Or, just let the network stack behave as it should. 3. Write my TCP-UDP logic directly into ether_input.c Any reason to not use pf for this translation? /my idea Now for the questions: 1. Am I on the right track? or in other words how crazy is my idea? Pretty crazy. You may want to see if there's hardware accelerated or on NIC TCP off-load options instead. 2. What would be the latency? Can I achieve 50 microseconds between getting the interrupt and until sending the new packet through the NIC? See above. You'll end up having to do some tuning. 3. Which NIC/CPU/Memory should I use? Money is not a problem. Custom order a few NICs, hire a developer to write a driver to offload TCP/UDP on the NIC, and enable as little kernel interference as possible. Money's not a problem, right?
Re: Low latency High Frequency Trading
On Fri, Nov 09, 2012 at 04:14:28PM +0100, Ariel Burbaickij wrote: What is the rationale behind this statement: ... - CPU: maximum SINGLE CORE turbo speed. Disable the other cores, they're not helping you at all...? OpenBSD doesn't run multiprocessor inside the kernel, so SMP provides no benefit. Even if it did, the overhead of SMP would probably be a net loss for this particular workload.
Re: Low latency High Frequency Trading
On Fri, Nov 09, 2012 at 06:27:06PM +0200, Dan Shechter wrote: I can do some assumptions regarding the TCP flow and its origins. Its coming from the stock exchange over IPSEC gateways over leased lines. I think I can trust the origin of the flow. At least I can trust it as much as the off the shelf software does. If something goes wrong with the off-the-shelf software, you can blame the vendor. Your own hand-rolled solution, not so much... When I was saying money is not a problem, I was referring to the cost of the server to run this. I know, you said that already. But I've worked in this industry also and I am well aware of the reality distortion that occurs when gambling with billions of dollars of other people's imaginary money. I know that I need to implement state machine for the TCP session and keep some buffers for out of order packets. Do you think the right place to place the code is in ether_input.c? I gues you mean to say either sys/net/ip_ethersubr.c, or the ether_input() function inside that file, but either way the bulk of your code should get added to a separate file if you don't want a maintenance nightmare. Its about 1k packets per second max. This should be doable on all but the most ancient hardware. But you will need to consider how you want to handle bursts or anomalies: is it more important to never lose a packet, or is it acceptable to lose some number of packets in order to keep latency low? In the former case you need to rely on buffers; you will want to move packets off the interface recieve ring and into another buffer like the ip input queue as quickly as possible, then do your magic in software interrupt context. You'll also want to look at disabling the MCLGETI functionality in the network card driver, and possible increase the recieve ring size on the card. Here you probably want to hook your code at the very beginning of ipv4_input(). In the later case, you'll want to reduce the recieve ring size on the interface and handle the bulk of your processing in the hardware interrupt. Fragment reassembly, handling TCP resends and out-of-order packets, etc may no longer be useful (since it requires buffering packets), and you may opt to simply drop data that doesn't arrive in correct sequence. This is when ether_input() would be the right place to hook your code. I plan to coil the path cable to make electrical filed surrounding my device to protect it from evil. Think about how you might be able to use ACLs on a high-end switch to guarantee that the packets you recieve fit a certain profile (for example, ensure that all packets are IPv4 TCP port 12345 between hostA and hostB), to help shrink your code path. Similarly, it may be possible to configure the device that's handling the IPsec tunnel to do IP and TCP reassembly for you (if not, can you replace it with one that does?), in which case your code could be made MUCH simpler. You didn't mention the protocol you're handling, but solutions like the following may be helpful (or you might be able to implement the whole thing there, and avoid supporting a frankenkernel). http://www.brocade.com/solutions-technology/enterprise/application-delivery/fix-financial-applications/index.page It's optimized for cloud service delivery, so it's at least 9000x as awesome as OpenBSD.
Re: IPSEC VPN performance
On Tue, Oct 02, 2012 at 09:59:05AM +0200, Christiano F. Haesbaert wrote: Why not using tcpbench where you can actually specify the parameters and know what is going on :). Play with buffer sizes and you'll see a big difference, using -u will give you the actual PPS. I agree with this. Also, if you want to compare with other people's you should use the same tools and specific settings such as buffer sizes. Otherwise, no point in comparing and just decide on your own if 600Mbps with netcat is good enough for you. As I mentiend in http://marc.info/?l=openbsd-miscm=134033767126930, I tested with tcpbench -B 262144 -S 262144 -n 10
Re: IPSEC VPN performance
600Mbps seems about right, I tested a pair of E5649-based boxes to 550Mbps last year (with aes-128-gcm): http://marc.info/?l=openbsd-miscm=134033767126930 You'll probably get slightly more than 600 with with multiple TCP streams. Assuming PF was enabled for your test (the default configuration), the performance should be about the same with a proper ruleset. Traffic for existing states won't hit the ruleset at all. On Fri, Sep 28, 2012 at 06:39:14PM -0400, Jim Miller wrote: Yes. Let me double check everything again on Monday. Keep in mind that all devices had 1Gb ethernet interfaces and everything was directly cabled. No pf rules either. w/o ipsec I could get 900mbps through the openbsd boxes. Now you've got me thinking I need to recheck everything. -Jim On 9/28/12 5:19 PM, Hrvoje Popovski wrote: Hi, On 28.9.2012 22:09, Jim Miller wrote: So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I was able to achieve approx. 600Mbps performance through the test setup (via iperf and my dd method). 600Mbps via ipsec between two Intel E31220 ?
Re: net.inet.ip.ifq.maxlen was WARNING: mclpools limit reached; increase kern.maxclusters and paquet lost
On Wed, Aug 29, 2012 at 12:54:18PM -0400, Michel Blais wrote: How much can I increase net.inet.ip.ifq.maxlen ? I'm now at 2048 and still seeing increase in net.inet.ip.ifq.drops. This morning, it was at 21280 and now at 21328. A little bit of congestion increase is not the end of the world, but increasing the increasing the queue length will certainly increase your latency. I've change the système for a temporary more powerfull one (core 2 quad + 2 dual 82571EB) while I'm commanding and building new server and now the congestion have dropped from 3.9 to 0.8. More cores will not help; throwing more power at the problem may not be the solution, but if it is: the top performance will be a CPU with high clock speed (disable the other cores so that 'Turbo Boost' can crank the live core up), and the largest, fastest cache possible. You could also try setting kern.pool_debug=0. Something I must specify, I use bi-nat to save public ip address and have thousand of bi-nat rule divided in some anchors. Thousands of rules is not a good idea if you can avoid it. This may be a little bit helped by your anchors, or the anchors may make it worse (PF's ruleset optimization mechanisms will not operate across anchors). Can you explain in more detail what you are doing with these bi-nat rules? -Ryan
Re: Does pfsync require same firewall rules on each fw?
On Fri, Jun 29, 2012 at 01:20:49PM +0200, Martin Pelikan wrote:
2012/6/29 Matt Hamilton ma...@netsight.co.uk:
Does pfsync require firewalls to have the same firewall rules on all
hosts in the sync group?
pfsync only synchronizes states. Which rules created them is
irrelevant.
This absolutely incorrect (see below)
But, I was wondering... could I use pfsync to sync states across
from one side of the network to the other?
How well this will work depends a lot on the nature of your traffic and
the latency between the two firewalls. You will probably need to use the
'defer' option for the pfsync interface, which will cause delays on
connection setup if the firewalls are too far apart.
Do pfsync packets contain reference to the firewall rule number or
specific interface? Or does it just have information specific to the
packet itself (ie, src address, dst address, sequence numbers etc)?
If the firewall rulesets are the same, pfsync will link the state
entries to the matching rules. this is necessary to get timeouts, max-*
limits and overload table behavior, per-rule src node tracking, etc. If
the rulesets are different, all states will be associated with the
'default' rule and as such will get the defaults for these items,
regardless of the options on the rule which matched when the state was
created.
It's not impossible to get the same ruleset across two very different
firewalls though, as long as the general policy is the same you can
probably make it work by using interface groups rather than the actual
interface names, and tables where ip addresses need to be different.
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_pfsync.h?rev=1.44
struct pfsync_upd_c {
This is only used for state updates, state creations are done with
struct pfsync_state in pfvar.h.
Re: how to configure DHCP on trunk interfaces ?
$ cat /etc/hostname.trunk0 dhcp trunkport em0 trunkport iwn0 trunkproto failover Only annoyance is the iwn0 device doesn't attach to the trunk properly if I boot with the wifi hardware switch turned off. iwn0: radio is disabled by hardware switch On Wed, Jun 27, 2012 at 05:04:26PM +0600, �?л�?�? Шипи�?ин wrote: it works for em0, if I put DHCP in hostname.em0 is it possible to do with trunk0 ? can anybody give working example ?
Re: ipsec tunnel speeds
100Mb/s with aes-128 / hmac-sha1 on hw.model=Intel(R) Xeon(TM) CPU 2.80GHz (GenuineIntel 686-class) hw.vendor=Dell Computer Corporation hw.product=PowerEdge 1850 550Mb/s with aes-128-gcm (requires AES-NI and amd64) on hw.model=Intel(R) Xeon(R) CPU E5649 @ 2.53GHz hw.vendor=HP hw.product=ProLiant DL360 G7 Tested with tcpbench -B 262144 -S 262144 -n 10 On Thu, Jun 21, 2012 at 03:29:30PM -0400, Mark Romer wrote: 42 Johan, You are absolutely right, you can lart me now...(lol).. But I just wanted to know simply what others were getting for data transfer speeds over their ipsec tunnels. I know what speeds I am getting. I just want to know what others are seeing for their own setups. thanks, Mark
Re: pf-smp alpha on freebsd
No, there is no single mutex around PF specifically in OpenBSD, the whole kernel is wrapped in a biglock. I think if they work out all the nits and dead-ends we may have something to learn from this effort, but I don't see this code coming back to OpenBSD. It's not critical because they can change the state table implementation later - OpenBSD has reorganised this several times with more planned - but we've put quite a bit of effort into removing hash tables in our kernel wherever possible, partly due to their attackability. My personal preference would be to go with a lockless or lock-on-write RB tree for the state table, but without an SMP-safe network stack there's little motivation to work on such things (though it remains somewhere on my todo list). On Mon, Jun 18, 2012 at 10:06:01AM +0200, Franco Fichtner wrote: On Jun 17, 2012, at 7:53 PM, Ted Unangst wrote: On Sun, Jun 17, 2012 at 11:43, Holger Glaess wrote: i dident wont start about smp on openbsd but what about this porject ? Did you read the part below? I think it's pretty clear this project isn't going to have much relevance for OpenBSD. From the very beginning of the project it was clear, that code is going to diverge significantly from original OpenBSD code. OpenBSD has always developed pf without taking into account that code can ever get multithreaded, thus quite a lot needed to be changed. Thus, I've started with removing the #ifdef __FreeBSD__ from the code, and later I didn't hesitate even a fraction of second if I wanted to toss some code. The pros is that now code is much more readable and understandible then in head, the cons is that diff between us and OpenBSD is huge, although amount of shared code is huge, too. So, later on only manual merging of features from OpenBSD is possible and bulk imports of entire pf into FreeBSD are no longer possible. This sounds like a messy decision. Is this single-mutex stuff in pf true for OpenBSD as of now or a port quirk of FreeBSD's version? I worked on a heavily multi-threaded firewall core for a few years and I would be glad to help pf itself instead of a 4.5-based pf port going SMP, chasing rainbows and unicorns.
Re: pfsync: deferred packets exit on wrong interface
Are you using route-to in your configuration? This has been partly fixed in -current; if the route-to rule is matching on an outbound packet the deferred packet will be routed correctly. It is still broken in the case where route-to is on the inbound path; this is trickier to fix and I'm still considering options, none of which are very nice. There are several other problems with pfsync that have been fixed in -current, so you'd probably be best off running what, but if it's not possible I HIGHLY recommend moving to 5.1 when it's released. On Mon, Dec 12, 2011 at 08:13:48AM +0100, Peter Hallin wrote: We have a bunch of bridged firewalls and we are now looking into using the pfsync defer feature to solve some problems with async states during failover. However I discovered that the deferred packets (tcp SYN for example) are being sent out on the management interface of the firewall an not on the bridged vlan interfaces where they're supposed to go. In this case the traffic that goes the wrong way is destined for the firewall management network, but as it's only the SYN packet that goes that way, the firewall proctecting the management network will not set a state and drop subsequent packets. It probably takes this way because it's the shortest path to the other firewalls. If the defer flag is off, everything works as it should and traffic takes the right path. This has been tested on 4.9/amd64. Please let me know if I can supply more info, it's a pretty complex problem to explain.
Re: Hardware for 1Gbps IPsec
On Tue, Oct 11, 2011 at 04:03:48PM +0200, BARDOU Pierre wrote: I'm looking for hardware capable of doing 1bgps IPsec, under OpenBSD of course. Do you think it is possible with a brand new high end server and their new instructions (AES/NI and/or AVX) ? Currently I don't think you'll be able to find a single system that will push 1GB of IPsec running OpenBSD. I've tested -current with aes-gcm across a pair of HP DL360 G7 boxes with Xeon X5650 @ 2.67GHz; I was able to get around 550 Mbps with tcpbench -n 10 through a gif tunnel + IPsec transport mode. You'll need to be running amd64 for this to work. Or would a crypto card be necessary ? If yes, do you have a brand/model to recommend ? In the crypto section most of the devices I see are old chipsets, which are far from 1 Gbps throughput. The only thing I see is the Via Padlock, but I think the CPU is not capable of Gigabit routing. There is also the BCM5862, but I can't find a card embedding it. There are no crypto processors that come anywhere close to the CPU crypto instructions (at least for network traffic). The interupt and PCI bandwidth cost of the crypto cards is just too high. (they probably still make sense for heavily asymetric crypto, like SSL acceleration. Some improvements may be seen in the next few releases with some smaller planned optimizations, and of course a higher clock speed should help, but I don't expect you'll get a solid 1Gb without taking the crypto code out of the biglock and allowing it to run MP. (non trivial, unlikely to happen any time soon) If you _really_ need 1Gbps and it's not just to meet some marketing fantasy, you're probably best building some kind of architecture that load balances the traffic across 2 or 3 VPN tunnels that terminate on different boxes (and you could get some kind of redundancy this way as well) -- CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2011/08/17 11:00:35 Modified files: sys/arch/amd64/amd64: aes_intel.S aesni.c Log message: Assembler implementation of the GCM mode using the Carry-less Multiplication (CLMUL) instruction found in the new Intel and future AMD CPUs. Done about a year ago and was rotting in my trees until Ryan prodded Theo to read the white paper and figure out the license issues. Apparently, there are none. All C code and SSE glue code was written by me, while the GF multiplication function is taken from the CLMUL white paper, specifically Figure 6: Code Sample - Performing Ghash Using Algorithms 1 and 5.
Re: Time interval based pf rule
On Fri, Sep 02, 2011 at 05:41:26AM -0700, Stefan N wrote:
Okay guys. Thanks for the suggestion.
On 2 September 2011 09:26, Stefan N stefanbsd...@yahoo.com wrote:
anchors + crontab as Peter suggested is an easy alternative.
Depending on what exact effect you want to acheive, you can maybe do it
without loading separate ruleset files if you prefer.
For example, in your /etc/pf.conf file, something like
table surfers { } persist
# allow interent surfing
pass in on $int_if from surfers to any {
block
# rules that allow internet surfing here. e.g.
pass in proto tcp from any to any port { 80 443 }
}
And in crontab:
0 9 * * * /sbin/pfctl -Td -t surfers 192.168.1/24
0 17 * * * /sbin/pfctl -Ta -t surfers 192.168.1/24
If your misbehaving users are not all in one netblock, you can create a
file and load/delete the addreses in the table from that file.
Alternatively, run a squid proxy, force all your users to use it, and
implement your time-based filtering there (squid is much better for
censorship anyways because you can filter based on domain name or even
the full URL rather than just IP addresses)
Re: fresh Thinkpad x220 - possibly new iwn variant
You and anyone else with an x220 want to be running -current, not the Aug 17 snapshot. Do a CVS checkout and make build, it shouldn't take long, especially with a nice SSD like that. (I don't know that it will fix this specific problem - I don't have one - but it will definately help other things) On Sat, Aug 27, 2011 at 09:38:31PM +0200, Peter N. M. Hansteen wrote: My new employer handed me a fresh Thinkpad x220 for my day-to-day needs, nice little number but the iwn iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address a0:88:b4:41:6f:5c (which is a bit temperamental under recent linuxes too) is refusing to play nice with OpenBSD (specifically the 17 Aug amd64 snapshot). I imagine it's another firmware iteration that's needed, but here's a dmesg followed by pcidump -v:
Re: Expected throughput in an OpenBSD virtual server
On Wed, Aug 24, 2011 at 07:00:09PM +0200, Per-Olov SjC6holm wrote: - SMP worse. Really sucks! _Dramatically_ reduced throughput. This is probably a result of you testing a virtualised guest rather than real hardware. - One processor core (as most of my tests have used) An improvement, but very little. Maybe 10% better 10% is fantastic. What were you expecting? 10x improvement from a network driver change? All the easy optimizations have already been done.
Re: Expected throughput in an OpenBSD virtual server
On Tue, Aug 23, 2011 at 09:10:05AM +0200, Per-Olov SjC6holm wrote: If you please will explain how baddynamic and avoiding certain ports will affect what we are talking about... Naaahh lets forget that section I believe people are referring to the text above that: One goal of OpenBSD is to have the system Just Work for the vast majority of our users. Twisting knobs you don't understand is far more likely to break the system than it is to improve its performance. Always start from the default settings, and only adjust things you actually see a problem with. VERY FEW people will need to adjust any networking parameters! Earlier you asked: So the question remains. Is it likely that a faster cpu core will give better performance (not that I need it. Just doing some laborations here). Is a faster CPU the best / only way to increase throughput. Yes, all other things being equal faster CPU will help. Other hardware factors include: - CPU vendor (AMD vs Intel) - CPU cache, bus, chipset - PCI bus - Network card - If you are doing IPSec, AES-specific instructions (AES-NI on Intel) Some CPU architectures have much better IO and interrupt performance for a given clock speed (Sparc64, for example), but cost makes them an unlikely choice for a firewall. Things that seem to make very little difference in testing: - MP vs SP kernel - i386 vs AMD64 Of course we assume the OS tweak is ok and that reasonable NIC:s are used. OS tweaks are usually not OK. The general rule of thumb is that if you have to ask about them on misc@ because there is no documentation and you don't understand the effects, then you shouldn't touch it PF configuration can have a big effect on your performance for some types of traffic. In general it's better to worry about making your ruleset correct and maintainable, but if you MUST write your ruleset with performance in mind, the following article discusses most of the issues: http://www.undeadly.org/cgi?action=articlesid=20060927091645 Is there a plan to change the interrupt handling model in OpenBSD to device polling in future releases ? No.
Re: Expected throughput in an OpenBSD virtual server
On Tue, Aug 23, 2011 at 10:42:59AM +, Stuart Henderson wrote: On 2011-08-22, Per-Olov Sj?holm p...@incedo.org wrote: MCLGETI ?? Is it in if_em.c if I want to see how it is implemented? it's in various files, see mbuf(9) and look for videos/slides from talks by dlg (David Gwynne), there's an asiabsdcon talk with more details and quite possibly some others. The effects of MCLGETI are quite visible in the PF testing I did for our '10 years of PF' talk, see pages 70-74 of the slides from BSDCan for example: http://quigon.bsws.de/papers/2011/pf10yrs/
Re: Recovery FFS formatted partition
On Wed, Aug 17, 2011 at 11:30:05PM +0200, Pablo Velasco FernC!ndez wrote: Hi all. Its possible to recovery a FFS partition? During my last OpenBSD installation I format by mistake my second hard disk with all my videos, texts, pictures etc... Thank you for you attention. In the past I've used the TCT (The Coroner's Toolkit) to recover from an accidental rm -rf * in /; it's been superseded by TSK (The Sleuth Kit), which also works on OpenBSD: http://www.sleuthkit.org/sleuthkit/desc.php You might want to have a look at File UNDeLeter (which uses TSK): http://sfdumper.sourceforge.net/fundl.htm I'll repeat what others have said: as in real forensics, make 2 copies of the original drive on other media; work from one of the copies and recover from the backup copy rather than touching the original drive again until you're satisfied you have all the files you want. Yes, you'll need lots of storage for this. Get it, and when you're done recovering files, you will have the disk space to make some backups.
Re: PF tcp sessions/s rate evaluation
There is not much to tweak, performance-wise. OpenBSD avoids such buttons like the plague, and besides: benchmarks should be run with a stock install, which is what 99% of users are going to be doing as well. You can try looking at the output of 'pfctl -si' and see if any of those is increasing a lot, it may give you some more hints. The only thing that jumps to mind is the states limit; if it's getting hit you'll see the memory counter increase. I can't make any suggestion for a good value for 'set limit states' though because you included zero information about the hardware you're testing on. On Tue, Aug 16, 2011 at 02:12:01PM -0400, Quentin Aebischer wrote: Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could try to significantly enhance the number of tcp sessions per seconds processed by PF. I'm kind of a PF newbie, so I'm clueless for the moment . Any hints, thoughts or ideas is appreciated ! --
Re: PF tcp sessions/s rate evaluation
Just to clarify a bit, I would not be surprised if IPTables performs more quickly than PF in this particular test, for a couple of reasons: - PF uses a red-black tree for the session tracking, while iptables uses a hash table. The red-black tree means performance scales smoothly as the number of sessions increases (and avoids attacks on individual hash buckets), see http://www.benzedrine.cx/pf-paper.html for details, but the insert/delete cost is higher, which is what you're probably seeing here. - PF does full TCP session checking by default (verifying TCP sequence numbers, etc). You could try testing with 'sloppy' state tracking to see if this makes a difference (NOT recommended in production unless you know what you're doing, so please don't report such results in a performance comparison). One problem with the test setup you've described (doing rdr-to for the session to the webserver) is that you can't repeat the tests without the firewall enabled to determine if it's a PF vs. iptables difference or just an OpenBSD vs. Linux difference. Also, if you post a dmesg of the system you're using and tell us what interfaces $WAN and $LAN are, we can check you're not doing tests with some ghastly network cards... I don't know what knob you've twisted to raise the kernel space memory, but such things are not recommended and I would prefer for you to report worse results with a non-tweaked install than report a bunch of settings that shouldn't be touched. In general, the design goals of PF go somewhat in the following order (I'll admit that we have a lot of work to do still on #2 in some areas of PF): 1) Free software 2) Correct, readable code 3) Secure, robust packet filtering 4) Flexible but simple to use 5) Good performance I don't think anyone here cares much if iptables is 'faster' as long as we're ahead on the first 4 items above. We already have enough fast, insecure systems. -- Bruce Schneier On Tue, Aug 16, 2011 at 08:16:02PM -0400, Quentin Aebischer wrote: Thx for the reply. Well I've already increased the state table size to 15 entries, 1 was not enough (there was up to 7 simultaneous state entries during the test). Hardware wise, I'm using a xeon 2.4 GHz monocore with 1 GB of RAM. Since this server is used as firewall only, I've raised the kernel space memory to up to 90% of total memory. I don't want to make hasty conclusion, so I'll keep searching.. Ryan McBride mcbr...@openbsd.org a C)critB : There is not much to tweak, performance-wise. OpenBSD avoids such buttons like the plague, and besides: benchmarks should be run with a stock install, which is what 99% of users are going to be doing as well. You can try looking at the output of 'pfctl -si' and see if any of those is increasing a lot, it may give you some more hints. The only thing that jumps to mind is the states limit; if it's getting hit you'll see the memory counter increase. I can't make any suggestion for a good value for 'set limit states' though because you included zero information about the hardware you're testing on. On Tue, Aug 16, 2011 at 02:12:01PM -0400, Quentin Aebischer wrote: Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could
Re: ping got incorrectly caught by pf
Thanks for pointing this out, it was an oversight in the recent changes
to pf_test_rule().
I recommend specifying explicitly the correct protocols if you're
wanting to to match by user/group/os fingerprints.
block return out log proto { tcp, udp } all user = 1002
If you'd like, you can apply the patch below which will force you to do
it this way, but it's not strictly necessary. (hopefully this will be in
a snapshot near you soon)
On Tue, Jul 12, 2011 at 11:46:47AM -0400, Jiri B wrote:
Hello,
with latest snapshot (Jul 11 2011) I see this strange behavior
which I haven't seen before upgrade (ping caught by strange pf
rule).
$ id ;netstat -rnf inet | grep default
uid=1000(jirib) gid=10(users) groups=10(users), 0(wheel), 5(operator)
default192.168.1.1UGS6 1320 -12 iwn0
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 192.168.1.1 64 chars, ret=-1
--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
OK, why? It was caught by pf:
# tcpdump -i pflog0 -n -ttt -e icmp
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Jul 12 17:43:00.412525 rule 9/(match) block out on iwn0: 192.168.1.254
192.168.1.1: icmp: echo request
Interesting... what is that rule?
# pfctl -R 9 -vv -sr
@9 block return out log all user = 1002
[ Evaluations: 275 Packets: 23Bytes: 1912States: 0
]
[ Inserted: uid 0 pid 30333 State Creations: 0 ]
So, why was ping caught by rule which should apply only to
uid = 1002? FYI, the ping is caught for root as well?
Am i doing something wrong or I haven't seen some info for
-current followers?
jirib
--
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.604
diff -u -p -r1.604 parse.y
--- parse.y 8 Jul 2011 18:52:47 - 1.604
+++ parse.y 13 Jul 2011 03:52:25 -
@@ -3941,9 +3941,23 @@ rule_consistent(struct pf_rule *r, int a
{
int problems = 0;
+ if (r-proto != IPPROTO_TCP r-os_fingerprint != PF_OSFP_ANY) {
+ yyerror(os only applies to tcp);
+ problems++;
+ }
if (r-proto != IPPROTO_TCP r-proto != IPPROTO_UDP
(r-src.port_op || r-dst.port_op)) {
yyerror(port only applies to tcp/udp);
+ problems++;
+ }
+ if (r-proto != IPPROTO_TCP r-proto != IPPROTO_UDP
+ r-uid.op) {
+ yyerror(user only applies to tcp/udp);
+ problems++;
+ }
+ if (r-proto != IPPROTO_TCP r-proto != IPPROTO_UDP
+ r-gid.op) {
+ yyerror(group only applies to tcp/udp);
problems++;
}
if (r-proto != IPPROTO_ICMP r-proto != IPPROTO_ICMPV6
Re: VLANs on bridge
On Thu, Jun 23, 2011 at 01:21:06PM -0700, Chris Cappuccio wrote: Unfortunately I'm not sure that the vlan driver can easily layer on top of trunk, a few tweaks may be required to make it work properly unless it mirrors if_capabilities from the parent interface (which isn't clear to me after quickly paging through if_trunk.c). vlan(4) layers fine on top of trunk(4), I'm using this extensively. I'm not sure that you are solving the right problem by asking for redundancy across NICs. You are probably better served by asking for redundancy across boxes using CARP and PFSYNC and multiple firewalls Redundancy across NICs provides the simplest form of protection against a switch failure (pair of connected switches, 1 nic to each swich)
Re: network bandwith with em(4)
On Sat, Mar 12, 2011 at 06:29:42PM -0800, Chris Cappuccio wrote: Are you suggesting that because you have a quad-port gig nic, your box should be able to do 6 *million* packets per second? By that logic my 5-port Soekris net4801 should be able to handle 740kpps. (for reference, the net4801 does about 3kpps with 4.9) are you sure? that seems low, the 4501 used to do 4kpps with openbsd 3.3 ! Quite sure, though I certainly welcome someone else doing independent testing to prove me wrong. (FWIW: I tested 3.3 last month and got a maximum of 2400pps before packet loss exceeded 1%) The numbers above are for IP forwarding (not bridging), no PF, TCP syn packets with random ports, ISN, and source address, but fixed destination address. Measurements are on either side of the device using SNMP on the switch, and they match very closely what I'm seeing from the endpoints on either side of the firewall. The results are also stable across the more than 30,000 individual tests I've run to date against a variety of hardware and versions (automated, of course!) Note that If you measure on the box itself (i.e. the IPKTS/OPKTS) you will get lies when the system is livelocking. If you push harder you can get more packets through the soekris but it's meaningless as most of the packets are being dropped and the box is completely livelocked.
Re: network bandwith with em(4)
On Thu, Mar 10, 2011 at 12:18:32PM +, Tom Murphy wrote: I had a pair of Dell PowerEdge R200s that have both em(4) and bge(4)s in them, however, it's the em(4) doing the heavy lifting. Roughly 30-40 megabits/s sustained and doing anywhere between 3000-4000 packets/s. On OpenBSD 4.4, it happily forwards packets along. I upgraded one of the firewalls to 4.8 and switched CARP over to it (yes, I know the redundancy is broken anyway now.) and it couldn't seem to handle the traffic. Any inbound connections would stall and I have no idea why. I assume that you don't have the 'defer' option set on your pfsync interface (it would be broken until you upgrade both firewalls) There were no net.inet.ip.ifq.drops, but I noticed 10 livelocks when running systat mbufs (on em0). I think in 4.8 systat mbufs is showing the total number of livelocks ever, and 10 is a tiny number. On a system nearing it's limit you could expect the livelocks counter to get hit a few times a second, but if it's getting hit 50 times per second you're way over capacity. Note you can also look at 'sysctl kern.netlivelocks' which is a little less ambiguous, and shows the total number of livelocks since boot. Could MCLGETI be hindering performance? I'm doing a lot of testing in this area these days on a broad range of hardware, and I have yet to find a case where MCLGETI does not improve a system's ability to handle load. If anything MCLGETI needs to be more aggressive, and we're looking at ways to do that. -Ryan
Re: network bandwith with em(4)
On Fri, Feb 25, 2011 at 08:40:10PM +0100, Manuel Guesdon wrote: systat -s 2 vmstat: 3.2%Int 0.1%Sys 0.0%Usr 0.0%Nic 96.8%Idle ||||||||||| The numbers presented here are calculated against the sum of your CPUs. Since you are running bsd.mp with hyperthreading turned on, your machine has 16 CPUs; each CPU accounts for about 6% of the total available so the 3.2%Int value in your systat vmstat means that you have one cpu (the only one that is actually working in the kernel) about 50% in interrupt context. The exact behaviour varies from hardware to hardware, but it's not surprising that you start losing packets at this level of load.
Re: network bandwith with em(4)
On Thu, Mar 03, 2011 at 03:52:54PM +0100, Manuel Guesdon wrote: Of course and s/OpenBSD/FreeBSD/ may help too but none of these proposals seems very constructive. If you think that you'd be better served by FreeBSD, please go ahead and use that instead. | I think we already mentioned it that you will always see Ierr. The | question is if the box is able to forward more then 150kpps. Yes that's one a the questions. We can divide it into 3 questions: 1) is the limitation comes from hardware ? 2) is the limitation comes from OpenBSD ? 3) is the limitation comes from the way OpenBSD exploit hardware. 1) Except if someone explain by a+b why the hardware can't forward this rate, I'm keep thinking it can do it (otherwise I don't see reason to sell quad 1Gbps nic). Are you suggesting that because you have a quad-port gig nic, your box should be able to do 6 *million* packets per second? By that logic my 5-port Soekris net4801 should be able to handle 740kpps. (for reference, the net4801 does about 3kpps with 4.9) I'm ok to hear that I've purchased crappy motherboard card or nic (but I'd like to understand why they are crappy). It has nothing to do with hardware crappiness, it has to do with your expectations. Your box should certainly be able to fill a few of your gig ports with 1500byte packets, but there is no way it'll handle a full 4 gigabits / second of TCP syn packets. I've spent days and days making tests, searches, reading kernel source code and so on because I think it's interesting for the community to find where the problem come from and how to solve it (if possible). If finally the answer is that OpenBSD (or may be any other OS) can't forward more than 150kpps without losing 1 to 20 pps with this hardware, I'll live with it. Are you actually complaining about 1 to 20 errors per second? That's 0.01% packet loss, welcome to ethernet. You will not see this change by switching to different hardware or OS. It /is/ possible that something is wrong with your box and you could be getting a slightly higher throughput. But don't expect that we'll make it handle 2 million PPS any time soon. But as we've already seen that increasing int/s improve performances (for good or bad reason), I keep thinking there's something to improve or fix but I may be wrong. There are MANY more performance considerations than just pps: latency, interactive/userland performance under load, how the system responds once it is overloaded, etc. We're not going to sacrifice all these just to get a higher pps number. However, don't bother just telling us there's something to improve. We've working on this for years, we've already made huge improvements, and we're always looking for more. Perhaps the biggest limitation on modern hardware is that we can't split the packet handling across multiple CPUs, but your input provides exactly ZERO help with changing that.
Re: network bandwith with em(4)
On Mon, Feb 28, 2011 at 12:49:01PM +0100, Manuel Guesdon wrote: OK. Anyway NIC buffers restrict buffered packets number. But the problem remain: why a (for exemple) dual Xeon E5520@2.27GHz with Intel PRO/1000 (82576) can't route 150kpps without Ierr :-) http://www.oxymium.net/tmp/core3-dmesg I've done some more comprehensive testing and talked to some other developers, and it seems that 150kpps is in the range of what is expected for such hardware with an unoptimized install. One thing that seems to have a big performance impact is net.inet.ip.ifq.maxlen. If and only if your network cards are all supported by MCLGETI (ie, they show LWM/CWM/HWM values in 'systat mbufs', you can try increasing ifq.maxlen until you don't see net.inet.ip.ifq.drops incrementing anymore under constant load. On my test box here - Intel(R) Xeon(R) CPU 5140 @ 2.33GHz with em(4), pf disabled - increasing net.inet.ip.ifq.maxlen to 8192 gets more than double the performance compared with the default of 256. We're looking at making the ifq.maxlen tune itself so you don't have to twiddle this knob anymore, not sure if and when that will happen though.
Re: network bandwith with em(4)
On Mon, Feb 28, 2011 at 12:49:01PM +0100, Manuel Guesdon wrote: OK. Anyway NIC buffers restrict buffered packets number. But the problem remain: why a (for exemple) dual Xeon E5520@2.27GHz with Intel PRO/1000 (82576) can't route 150kpps without Ierr :-) http://www.oxymium.net/tmp/core3-dmesg Turn off hyperthreading, run a uniprocessor kernel rather than bsd.mp. I can't immediately tell if you're running i386 or amd64, but i386 will probably be better. There may be something else going on here, because 150kpps should be trivial for a box like this, but the advice above will certainly improve your situation. (Yes, it will hurt to know that 7 of your cores are doing nothing. Too bad, they're just slowing you down now)
Re: network bandwith with em(4)
On Fri, Feb 25, 2011 at 02:05:30PM +0100, Patrick Lamaiziere wrote: Le Fri, 25 Feb 2011 13:51:32 +0100, Patrick Lamaiziere patf...@davenulle.org a icrit : (ooops, push the wrong button) How about a _full_ dmesg, so someone can take a wild guess at what your machine is capable of? full dmesg : http://user.lamaiziere.net/patrick/dmesg-open48.txt The box is a Dell R610 server. This box should be able to fill a gigabit of regular TCP traffic (1500 MTU) without any problem. Double-check your testing procedures. I have some additional comments/questions though: 1) you probably don't want to run bsd.mp on a firewall, it'll hurt you more than it helps, unless you have significant CPU-bound userland stuff going on, for example antivirus scanning of email. 2) You may get better performance running i386. 3) Besides the the em driver changes you've mentioned, is the source code you're building the kernel clean OPENBSD_4_8 -stable, or something else (4.8-current from after the 4.8 release, for example)
Re: network bandwith with em(4)
On Wed, Feb 23, 2011 at 06:07:16PM +0100, Patrick Lamaiziere wrote: I log the congestion counter (each 10s) and there are at max 3 or 4 congestions per day. I don't think the bottleneck is pf. The congestion counter doesn't directly mean you have a bottleneck in PF; it's triggered by the IP input queue being full, and could indicate a bottleneck in other places as well, which PF tries to help out with by dropping packets earlier. Interface errors? Quite a lot. The output of `systat mbufs` is worth looking at, in particular the figure for LIVELOCKS, and the LWM/CWM figures for the interface(s) in question. If the livelocks value is very high, and the LWM/CWM numbers are very small, it is likely that the MCLGETI interface is protecting your system from being completly flattened by forcing the em card to drop packets (supported by your statement that the error rate is high). If it's bad enough MCLGETI will be so effective that the pf congestion counter will not get increment. You mentioned the following in your initial email: #define MAX_INTS_PER_SEC8000 Do you think I can increase this value? The interrupt rate of the machine is at max ~60% (top). Increasing this value will likely hurt you. 60% interrupt rate sounds about right to me for a firewall system that is running at full tilt; 100% interrupt is very bad, if your system spends all cycles servicing interrupts it will not do very much of anything useful. dmesg: em0 at pci5 dev 0 function 0 Intel PRO/1000 QP (82571EB) rev 0x06: apic 1 int 13 (irq 14), address 00:15:17:ed:98:9d em4 at pci9 dev 0 function 0 Intel PRO/1000 QP (82575GB) rev 0x02: apic 1 int 23 (irq 11), address 00:1b:21:38:e0:80 How about a _full_ dmesg, so someone can take a wild guess at what your machine is capable of? -Ryan
Re: pf rules for Load Balance Incoming Connections for webservers
On Tue, Feb 01, 2011 at 02:22:25PM +0530, Indunil Jayasooriya wrote: I have 3 web servers running on port 8080 behind PF firewall. I am trying to load balance these incoming connections to these web servers. I wrote rules as below. Pls pay attention to *highligthed BOLD* rules . they are the once I have written. But, I can NOT login to these web servers from the Internet. *match in on $ext_if inet proto tcp to $ext_if port 8080 rdr-to $web_servers \ round-robin sticky-address * You need to pass the inbound traffic somehow (match doesn't do this). Either change the 'match in' above to 'pass in', or add another rule below like this: pass in on $ext_if inet proto tcp to $web_servers port 8080 # filter rules block in log block out log I think it's better you put this before the match rule(s). If you don't you'll have to use 'quick' on the pass rules I mentioned above. *pass out log on $int_if inet proto tcp from any to $web_servers port 8080 \ flags S/SA modulate state*
Re: pf commands to discuss
On Thu, Jan 20, 2011 at 01:47:20PM +0530, Indunil Jayasooriya wrote: my question is that How can I exclude my firewall from being able to doing it ? I'm really not sure why you don't want the firewall to be able to traceroute. (hint: if you can't trust the users on your firewall to behave responsibly with basic troubleshooting tools, you're Doing It Wrong (tm)). However, here is one way that you can get the effect you're looking for, using the 'tag' and 'tagged' keywords: match out on $ext_if from $lan_net nat-to ($ext_if) pass in log (all) on $int_if inet proto udp from $admin_pc to !$int_if \ port 33433 33626 tag ADMIN pass out log on $ext_if inet proto udp from $ext_if to any \ port 33433 33626 tagged ADMIN Note I've removed the 'keep state', it's not necessary to specify that anymore.
Re: PF and States
On Wed, Dec 08, 2010 at 12:39:12PM -0800, dabheeruz wrote: We are seeing the issue again and I am writing a script to get the pfctl -vvsi data at regular intervals. Can you please point me to what values I should be looking out for? You want to look for any of the counters in the Counters section besides 'match' increasing A Lot. How much depends on your specific situation, but if you get a feel for what you see when you're NOT having problems, you should be able to see if any of the counters increases suddenly. In your case, the most likely ones are: - memory - congestion - state-limit
Re: PF and States
On Thu, Dec 02, 2010 at 11:22:08PM -0500, Godesi wrote: 1. Do I need pf for relayd when I am not doing redirects? I don't think so, but this is easy for you to test... 2. How much states can i really have on a box that has 4 gig ram? More than 100,000. I havn't tested lately (planning to do so soo), but I would expect somewhere closer to 500,000. Is it governed by how much mem is allocated to kernel? Yes. Can I change that? Not directly. In fact, having too much RAM in your box will COST you memory, as more kernel memory is used up tracking all your RAM. So cutting your ram to 2 GB will probably improve the upper limit, though it doesn't seem that that's the limit you are hitting. What does 'pfctl -vvsi' show when this problem is happening?
Re: (Perhaps?) dumb pf question relating to tables
On Wed, Nov 10, 2010 at 01:45:16PM +0100, Tor Houghton wrote: May I ask whether or not per user ownership (or permission to update) a table is/will be possible? I am pondering the best mechanism for a non-root process to add/remove addresses to a table. You can look at sysutils/tabled in ports, which provides this functionality (permissions would be controlled by the filesystem permissions on the fifo) I don't think we'll be making /dev/pf accessible by non-root processes any time soon.
Re: pf synproxy
On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote: Confirmed - synproxy works great if the synproxy machine is the default gateway for the end host. Yes, PF has to handle every packet of a synproxy'd connection. Sadly this means scalability (adding multiple synproxy boxes) is not possible, nor is it possible to filter a specific IP out of the end machines ranges. It's not clear what you mean by either of these statements. Perhaps I'm shooting for the moon here - but shouldn't it be possible to have a machine validate a remote host to be real and then create a state to simply permit all traffic from it to pass without additional filtering? Thus no breaking of packets and allowing the remote host to respond directly? I don't think it is possible to do what you want. Once you have completed the 3-way handshake and negotiated a set of sequence numbers to use for the connection, there is no way to simply dump the established connection on another box that knows nothing about it. synproxy works by completing the 3-way handshake with the source first, then negotiating a separate 3-way handshake with the client. Because the negotiations are separate and the two endpoints have no direct knowlege of each other, there sequence numbers negotiated are different. PF handles translation between the different sets of sequence numbers, and has to be man-in-the middle for every packet on the connection in order to do this translation.
Re: pfctl from today seems to be somehow messed up / DIOCSETSTATUSIF
This sounds a lot like a kernel/userland mismatch. Please update both kernel and userland from the same snapshot and try again. On Thu, Jul 01, 2010 at 03:33:56AM +0200, Laurent CARON wrote: Hi, I did upgrade one of my BGP routers today with latest current. Upon reboot I have no network. pfctl returns the following error: # pfctl -f /etc/pf.conf pfctl: DIOCSETSTATUSIF A default drop all in ruleset is loaded. If I rollback to previous pfctl it loads my rules fine. If i want to load rules correctly with newer pfctl I have to remove: set loginterface $EXTIF001 from /etc/pf.conf Thanks --
Re: pfctl from today seems to be somehow messed up
On Thu, Jul 01, 2010 at 10:15:26PM +0200, Laurent CARON wrote: This incidentally made my other router (running openBGPd) crash with: uvm_fault(0x80cc7320, 0xdeafb000, 0, 1) - e page fault trap, code=0 Stopped atpfsync_in_clr+0x123:movq 0x10(%rbx),%rax Interesting. Do you have the 'ps' and 'trace' output from that?
Re: Removing pf_pool
On Tue, Jan 12, 2010 at 11:11:54PM -0500, Pascal Lalonde wrote:
I just caught the following from openbsd-cvs:
http://marc.info/?l=openbsd-cvsm=126326657232193w=2
If my understanding is correct, this means that it will become
impossible to emulate weighted round robin with constructs like the one
below, since duplicate IPs will be flattened once converted to a
standard PF table?
rdr on em0 inet proto tcp \
from any to 192.168.100.100 port = www - {
10.0.0.1, 10.0.0.1, 10.0.0.1, \
10.0.0.2, 10.0.0.2, \
10.0.0.3 \
} round-robin
Is this right?
Well, that rule above will not parse anymore on -current, you need to
use match or pass with rdr-to now. But yes, the above construct will
stop working.
My first thought is to wonder why you're not running with a symmetrical
cluster. But I realise that we are not always in control of such things,
and one of PFs functions is to get help people work around bad network
design.
There are a few things you can do here to get a similar effect.
1) Assign multiple IP addresses to the servers you'd like to hit more
heavily.
match on em0 inet proto tcp \
from any to 192.168.100.100 port = www \
rdr-to {
10.0.0.1, 10.0.0.2, 10.0.0.3, \
10.0.0.11, 10.0.0.12, \
10.0.0.21 \
} round-robin
2) Use the 'probability' keyword
pass quick on em0 inet proto tcp from any to 192.168.100.100 \
probability 50% rdr-to 10.0.0.1
pass quick on em0 inet proto tcp from any to 192.168.100.100 \
probability 70% rdr-to 10.0.0.2
pass quick on em0 inet proto tcp from any to 192.168.100.100 \
rdr-to 10.0.0.3
The changes just committed are actually cleanup that needs to happen if
you want to see some more intelligent weighted load balancing in PF than
these hacks. But that is still a far ways off, definately after 4.7.
-Ryan
Re: pf n00b
On Sat, Oct 31, 2009 at 03:00:41PM -0600, ghe wrote:
I'm fresh off the boat from Debian. I love OpenBSD's attitude, and
the documentation is even pretty decipherable, but I'm still a
little confused by pf. I managed to build a trivial filter, but
there are a few things I don't understand.
I read somewhere (3 books, google, the website docs, and man) that a
longer rule takes longer to do its work.
I can't speak for the books, and I KNOW google is full of lies, but can
you point out specifically what parts of the website docs and man page
talks about this? It should be removed.
Why? I don't understand how pf works -- I'd expect pfctl, while it's
munging pf.conf, to make most of the conditions into a big mask that
could just with the IP header and make a decision on the result.
PF is designed to have a considerably more flexible and fine-grained
filtering mechanism, so what goes on is considerably more complicated
than just a bitwise against the header.
So specifying the proto and both addresses and flags shouldn't make
much difference in efficiency. No?
Actually, under many circumstances specifying the proto and addresses
will IMPROVE the performance of the ruleset evaluation even though it
makes the individual rule evaluation slower.
The number of rules evaluated makes a lot more difference than the
number of parameters evaluated per rule.
pf.conf consists largely of anchors (to fork on protocol) and sub-
anchors below them to fork on service -- I'm trying to reduce the
count of rules seen by a packet to a minimum. But
This approach is almost guaranteed to have the opposite effect.
My number one advice for people who want to optimize their rulesets for
performance is: DON'T.
Seriously.
Writing firewall rules is hard, anything more than a trivial ruleset is
easy to screw up and challenging to test. So the #1 goal for your
ruleset should be readability and maintainability. While you're at it,
put your ruleset under revision control, and figure out a good way to
test any ruleset changes that get made.
That being said, here are some things you can do while you're doing the
above which will help performance.
- stateful filtering (don't use 'no state')
- pfctl optimizer (don't use 'set ruleset-optimization none')
- use tables for lists of addresses
- use as few rules as possible to get the filtering you want
while keeping the ruleset readable.
Now, if you really, really need to optimize your ruleset for
performance, it's important to know that PF doesn't simply walk through
the rules as you've specified in your pf.conf when; pfctl optimizes the
rules as they are loaded into the kernel, and PF has a mechanism called
'skip steps' which will skip evaluation of rules if it's known in
advance that the rules cannot possibly match.
The skip steps attributes are the following:
* interface
* direction
* address family
* protocol
* source address
* source port
* destination address
* destination port
The best thing that you can actively do for ruleset performance is to
get out of the way of these mechanisms.
- Make use of the rule expansion in pf.conf (rules with items listed in
braces { }) rather than manually expanding them. The expansion is done
by pfctl in the skip steps order.
- Group your rules by the skip-steps parameters, in the order above.
(ie, all rules for em0 together; within that group, all the 'in' rules
together, within that, all ipv4 rules together...)
- For the above parameters, specify as much detail as possible without
adding more rules; increased detail will give skip-steps more to work
with.
- Make sparing use of barrier rule options, which prevent the ruleset
optimizer from reordering the ruleset efficiently.
* label
* prob
* state limits
* max_states
* max_src_nodes
* max_src_stats
* max_src_conn
* max_src_conn_rate
* anchor
- This means: Don't break the ruleset into anchors for performance
reasons unless you _really_ know what you're doing. If you DO, it's
probably best to break it up in skip-steps order (ie, by interface
first).
If you're STILL having performance issues after this, there are a few
more things you can do. Remember though:
Premature optimization is the root of all evil
-- Donald Knuth
- Write your ruleset with 'first match' ordering (quick) on
all/most rules, and use the 'profile' ruleset-optimization
- Filter only on one side of the firewall, using 'set skip' for the
interface on the other side.
- Group rules using optimizer breaks together; the optimizer
will only reorder or merge them if they are the same. (Roughly stated,
these are the 'actions' that a rule can perform).
* tag
* keep state
* queue
* routing (rt, route-to,
Re: OpenBSD a la NanoBSD ?
On Fri, Oct 16, 2009 at 10:58:53AM +0200, k...@oav.net wrote: I love OpenBSD, and I really like to set a small OpenBSD distribution on USB stick to allow make cheap OpenBGPd routers. Is there any project that is officialy supported by OpenBSD team? Do the regular OpenBSD install, selecting only the following sets: bsd bsd.rd etc46.tgz base46.tgz I think you'd be hard-pressed to a USB stick that won't handle such an install. The above will fit on a 256MB drive (but it's pretty cozy). 1G will give you a more pleasant experience for upgrades (stale libraries etc), and room for some ports and log files.
Re: Where is Secure by default ?
On Mon, Mar 09, 2009 at 04:50:51PM +0100, Felipe Alfaro Solana wrote: ARP is insecure by default. If you care, move to IPv6 and use IPSec/SeND. SeND will not be coming to OpenBSD any time soon. http://www.ietf.org/rfc/rfc3971.txt http://www.ietf.org/rfc/rfc3972.txt 80 pages across two RFCs for mapping layer 2 addresses to layer 3 addresses?!? Public key crypto (ASN.1 encoded, of course) to verify them? I guarantee that implementing this will create more security problems than it solves. If you do not trust your local network, use crypto at a higher layer (ipsec, ssh, ssl, etc).
Re: Hardware recommendation for firewalls (more than 4 NICs)
On Mon, Aug 11, 2008 at 01:14:53PM +0200, Marco Fretz wrote: How odd. I know at least one site that runs all of their BGP off of OpenBGP on OpenBSD boxes that are dedicated as routers. In all cases, these systems outperform the equivalent Cisco hardware for a fraction of the cost. Forget this. Cisco does CEF (cisco express forwarding) that's stream forwarding in hardware. You don't have a chance to reach this PPS with a pc / server based router (any os). However, this only applies to best case traffic; the hardware path does not handle all possibile cases, and corner cases are shunted to the underpowered CPU for special handling. An attacker can take advantage of this and overwhelm a hardware router with far fewer packets than their marketing glossies would have you believe, so in order to get your desired performance in all situations you have to go with a much bigger system. One nice thing about software routers is that the spread between their best case and worst case performance is much narrower, so they are easier to size and test.
Re: OpenBSD and SYNFlood / DDoS protection
synproxy in pf already makes sure the 3-way handshake completes before the connection is completed on the other side; rate limiting can also be done on the OpenBSD firewall, so it's not clear why you would need an extra box there. The bigger problem with DDoS attacks is that the upstream pipe is filled up with traffic, and no matter how much technology you deploy at your end of the pipe, it's still going to be full. Rate limiting and such needs to be deployed further out, at your ISP, and possibly further upstream. Also, it would help if all ISP's implemented proper egress filtering to prevent spoofing. On Fri, Jul 18, 2008 at 10:27:36PM -0700, Parvinder Bhasin wrote: This maybe dumb but won't hurt to throw this out there, maybe this has to be built with combination of tools, technologies etc but i would definately like to first collect as much info and then maybe work on this (or maybe the solution - open source is already out there , in that case I would like to know what :), I know of many 100K devices that will do this. Is there a way that I can setup a machine (another openbsd machine) in front of an OpenBSD firewall to help against DDoS attacks? If so what would be proper approach in doing so (if someone has already approached this subject). Machine would have 2 or 3 nics (3rd nic for management maybe?). You take the internet drop on the first port, say for example: fxp0 (external_if) . Maybe implement SYNCOOKIE (technology). The traffic only gets passed on to the firewall port throught fxp1 (internal_if) , once the server gets the ACK back.Would SYNPROXY do this too?? This machine could also be doing some form of RATE LIMITING?? maybe?? Anyone ?? Anytakes?? /Parvinder Bhasin --
Re: Huawei E220 on ALIX
On Wed, Jul 16, 2008 at 10:24:36PM +0200, Martin Schmitt wrote: I'm trying to use a Huawei E220 UMTS USB modem on an ALIX, using OpenBSD Flashdist 20080504. Please try this with the GENERIC kernel, and report back to us if you still have a problem.
Re: PF and Binat
On Mon, Jul 14, 2008 at 10:28:18PM -0700, Parvinder Bhasin wrote: Filtering happens AFTER translation, so you need to filter on the real addresses of the hosts, not the alias addresses. Hmm by real ip do you mean internal ips of the servers?? Yes.
Re: PF and Binat
On Mon, Jul 14, 2008 at 09:19:22PM -0700, Parvinder Bhasin wrote: When I try to add the external ips as aliases on my external interface, it works fine. Isn't the BINAT statement sufficient??? do i have to use aliases??? Unless the addresses are being routed to the firewall in question, yes, you have to use aliases. Otherwise your system will not reply to ARP requests for the addresses, and the upstream router will not know where to send the traffic.
Re: PF and Binat
On Mon, Jul 14, 2008 at 09:48:22PM -0700, Parvinder Bhasin wrote: Actually Ryan, when I do the aliases way , do I still need the binat statements? because when I use aliases and binat statements together, it doesn't work. Without the binat statements and with aliases everything works fine?? If you do aliases without the binat, you're not connecting to your natted hosts, you're connecting to your firewall. what gives? Oh, I missed this before: pass in on $ext_if proto tcp from any to 75.36.44.22 port 80 pass in on $ext_if proto tcp from any to 75.36.44.23 port 25 Filtering happens AFTER translation, so you need to filter on the real addresses of the hosts, not the alias addresses.
Re: your mail
On Wed, Jul 02, 2008 at 03:52:26AM -0700, kavitha reddy wrote: very recently i bought openBSD 4.2 (pack of 3CD's).Now, as a part of my research work iam interested to know whether it is possible to show DoS attacks in openBSD 4.1 .If so let me know how can that be possible.As u said when a patch added to openBSD 4.2 , prevents remote DoS attacks.How can this be tested. A good place to begin your research would be the errata page for OpenBSD 4.1, which lists all the critical patches that were made to this release. http://openbsd.org/errata41.html In particular, look carefully at all the entries that say either SECURITY FIX or RELIABILITY FIX. I hope this helps, -Ryan
Re: modulate state not working with snapshot from 01.07.2008 on i386
On Wed, Jul 02, 2008 at 04:19:21PM +0200, Michael wrote: topic says all I guess... if you need more details please let me know. Well, with a bug report as detailed as this all I can say is it's probably been fixed, try a new snapshot.
Re: Anyone from this list at BlackHat or DefCon? And a query...
On Thu, Jun 26, 2008 at 09:37:28AM +0530, Amarendra Godbole wrote: It would be a pleasure meeting folks on this mailing list, including OBSD developers' at BH or DefCon. Thanks. The great majority of OpenBSD developers are from outside the United States, and I would guess that most of us prefer not to visit the US now thanks to the murderous foreign policy, authoritarian domestic surveillance, and invasive border control. You'll find few of us there. Personally I've been refusing invitations to go to, or even transit through the United States for about 6 years. It is generally said that the BH or DefCon wireless network is hostile, and sane individuals must not use their laptop for the risk of being compromised. My question is: if I use OpenBSD -current, with not much additional configuration (apart from the Intel wifi firmware), will the connection be reasonable secure? (Not sure if this hostility is a publicity stunt). Thanks again. While in general the Internet is a pretty hostile place, you probably need to worry about local network attacks (sniffing, man-in-the-middle) more than usual. Don't trust DNS, and tunnel tunnel your outgoing connections out through ssh or ipsec (look at the -D flag to ssh, and make sure that your browser uses the socks proxy for DNS lookups as well) This advice applies equally to any time you're on an untrusted network (Internet cafe, Open wirless access point, etc)
Re: sloppy states and dsr
On Fri, Jun 20, 2008 at 12:49:43PM -0700, Darrin Chandler wrote: Yes, you use sloppy state only on the host(s) seeing half of the trafic. So to say it even more plainly... anywhere you are forced to deal with asymetric routing you can use sloppy state in place of not having any stateful option. Would that be a fair statement? It's a fair statement if by 'forced' you mean, 'compelled beyond your control, with no other options, having fully understood the consequences and informed all relevant parties of the risks involved'. This feature is NOT a substitute for good network design. sloppy state performs basically NO security checks on the TCP stream; more importantly the TCP state tracking is extremely loose and it's trivial for an attacker to spoof creation of fully-established TCP connections, which will not time out for an extremely long time, filling your state table and blocking legitimate traffic. It's dangerous.
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 05:19:16PM +0800, Dongsheng Song wrote: How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? Use the following in your boot.conf: set image bsd.mp man boot.conf for more details...
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 11:28:36AM +0200, Michiel van Baak wrote: How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? cd / mv bsd bsd.up mv bsd.mp bsd reboot This is not really good advice, because it breaks next time you accidentally copy the wrong kernel into /bsd (for example, next time you upgrade the system)
Re: Development at the hackathon
On Tue, Jun 10, 2008 at 11:19:46PM -0700, Aaron Glenn wrote: Is there a particular time of day most changes are committed (like pre-dinner) or should we sync and build at whim? People are working pretty much all the time, though you may notice a slight decrease in commit rate around beer o'clock (between 11pm and 1am, TZ=Canada/Mountain). At any rate, we try to keep things production-stable even during a hackathon: our productivity during the event depends on it, so you can sync and build pretty much anytime. If you run into problems check the most recent commit messages and see if it's been fixed while your machine was building.
Re: Incorrect pfctl -vvq s Output
On Tue, Apr 08, 2008 at 07:04:31PM -0600, Daniel Melameth wrote: 8.25Kb/s? I know this is 1Kb/s so what's going on? Is this just an inaccuracy in the pfctl output or does altq really think I'm moving 8Kb/s? I assume it's the former as pftop appears to get it right: Make sure you're paying attention to the difference between BITS and BYTES. Bandwidth on network devices is generally measured in bits, and that's what the queueing in PF uses.
Re: Would OpenBSD and Squid be considered a Proxy Firewall?
On Mon, Mar 24, 2008 at 12:15:55AM -0700, Bryan Irvine wrote: having also not read the book, my guess would be that a transparent proxy + firewall would increase security because people don't have the the option to run SSH tunnels via the HTTP port. A good example would be years ago I ran a sock4 proxy on port 80 on my home firewall to allow me to download MP3s off of napster from my work computer. Had a squid proxy been in place I would have been forced to run it on 53 ;-p I've yet to find a proxy that I can't get an ssh tunnel through. Look at the -x and -X options in nc(1) and ProxyCommand in ssh_config(5) Having your ssh server listen on ports 80, 443, and 53 (at least) will help as well. There are other options in ports, just search for 'tunnel' - I've used net/gotthard quite sucessfully in the past.
Re: Setting up a HA server with limited resources
On Sat, Mar 22, 2008 at 10:49:26AM -0700, johan beisser wrote: I would like to reach a state, if possible, in which load balancing is performed, but at the same time, if one machine fails, the other will automatically take over. I believe this setup is also very useful when deploying updates. You're screwed on the load balancing without a 3rd system in the mix. Preferably 4 systems, so you've got failover between the firewalls. That's not the case anymore - see the IP BALANCING section in the carp(4) manpage. (there are a few caveats, first and formost being that your layer 2 network will have to cooperate)
Re: dvorak key layout
On Sun, Mar 16, 2008 at 02:57:23PM +1030, Timothy Wilson wrote: Maybe this is new in 4.3 or 4.2? I don't have this option in 4.1. I guess I should upgrade :) Are you sure you're looking in the right place? $ uname -a OpenBSD foo 4.1 GENERIC.MP#0 i386 $ which kbd /sbin/kbd
Re: dvorak key layout
On Sun, Mar 16, 2008 at 12:47:48PM +1030, Timothy Wilson wrote: I was wondering how I can use a dvorak keyboard on the console? I've googled, but I can only find how to's for X11, or for 2.x OpenBSD. I'm sure its something simple in rc.conf (.local!), but I can't find it. Any help would be appreciated. Select us.dvorak as the keyboard layout in the installer -or- put 'us.dvorak' in /etc/kbdtype, and reboot -or- Use kbd(8) to set the keyboard encoding to us.dvorak on the command line (kbd -l will give you a list of all your options)
Re: FIPS 140-2
On Thu, Mar 13, 2008 at 12:29:47PM +1100, Damien Miller wrote: On Wed, 12 Mar 2008, Ed Ahlsen-Girard wrote: Does OpenBSD's OpenSSL use the FIPS 140-2 certified bits where applicable? No. Furthermore, there are no FIPS 140-2 certified bits - it is an entire package that is certified, you don't get to pick and choose. However, if you can find a FIPS 140-2 certified cryptographic accellerator that OpenSSL will use (and most of those supported by OpenBSD will fall into this category), OpenSSH will be using it as well, and you can then presumably put FIPS 140-2* on your product materials or audit questionaire or what have you. -Ryan * With some fine print disclaimer to ensure that nobody accuses you of claiming FIPS compliance for the whole system, of course.
Re: More questions on building a release with a read only source tree
On Sun, Feb 24, 2008 at 11:27:31PM -0800, Don Jackson wrote: I would like make release to use [ a ] read only source tree I use lndir(1) to accomplish this. Check your source tree out somewhere else, and use lndir to make a 'copy' in /usr/src. Build from there, no other magic required.
Re: USB WLAN dongles
On Thu, Jan 24, 2008 at 10:11:14AM +0100, Pau Amaro-Seoane wrote: I was thinking, as somebody in the thinkpad forum suggested, of an USB WLAN dongle, but one of those with an external antenna that is connected through a standard (typically: Reverse) SMA-connector. Next, get a sufficiently long, low-loss cable and a parabolic antenna (some 24 dBi gain, e.g.), mount the antenna at a point having preferably line-of-sight to the WLAN source (the public router/access point) How long does your run have to be? Perhaps you can mount the dongle in a parabolic dish and run USB back to your system. Standard USB cable is good for about 5 meters; If you're going farther than that, you can get powered repeater cables that are good for up to 30 meters or so, or place a small box like a soekris close to the dish, and run ethernet. Either way signal losses on a digital run will be much, much less than even the most expensive low-loss cable :-) -Ryan
Re: More than 255 vhid's w/ CARP
On Wed, Dec 05, 2007 at 01:00:11PM +0100, SeDoFa wrote: It's true, but this can't solve any problems. In my case I have a /16 subnet and I need to nat every single IP to a different IP, for a total amount of about 400 IPs. Same subnet, same interface, redundant firewall with carp. Is there another way to increase vhid limit? You can't put multiple aliases on a single carp interface? Either way, this is a pretty scary setup because both addresses and interfaces are managed in linked lists in many places within the kernel, so when you do hundreds of them, performance will suffer. You may want to look at other ways you can modify your network architecture to make this possible - starting with routing the subnet to you firewall, so that you don't have to actually assign the addresses to an interface in order to nat to them. -Ryan
Re: OT: mail retrieval software
On Tue, Jul 31, 2007 at 09:59:23PM +0100, poncenby wrote: Grateful if anyone could recommend a mail retrieval program which does not require a local SMTP service like fetchmail does. How about fetchmail? (with procmail / maildrop / whatever) poll mailserver protocol imap service 993: username mcbride there has password mekmitasdigoat is mcbride here fetchall ssl mda /usr/local/bin/procmail -d %T
Re: Intel xeon fails to boot with 4.1 release
On Wed, Jul 04, 2007 at 10:03:20AM -0700, Austin Hook wrote: Thanks for the pointer to some stable binaries, however it's too old for me. I guess I will try with current snapshot and build stable 4.1 if I need it. If the problem is entirely a kernel issue, until 4.2-beta you should be able to boot from -current install media but install a 4.1-release userland with a 4.1-current kernel. Boot the system, then download your -stable source and build a -stable kernel with the fix in it. Or just run the -current snapshot :-)
Re: openbsd 4.1 and keep state
On Thu, Jun 28, 2007 at 02:56:33PM +0100, Stuart Henderson wrote: On 2007/06/28 15:45, Huzeyfe ONAL wrote: Use no state in your rule. and 'flags any' if it's TCP. You can set this explicitly if you'd like, but it's not necessary: pfctl only applies 'flags S/SA' by default if the rule is stateful.
Re: Packets Per Second Limit?
On Thu, May 31, 2007 at 03:43:56PM -0700, [EMAIL PROTECTED] wrote: Were nearing the 8300pps mark so I was worried? But should I be? You're fine. The 8300pps mark is not an upper limit, it's the best case for a full 100Mbit ethernet link (ignoring jumbograms). Becuase the majority of my packets are smaller then 64B, shouldn't I be able to pass a lot more packets then 8300pps? Yes, depending on limitations of your firewall hardware, pf ruleset, size of state table, etc. If all my packets were 64K or smaller, shouldn't that allow me to be able to handle closer to 200k packets/sec before hitting my bandwidth limit? For this you will need a reasonably fast box with good gigabit ethernet cards (em or sk), and an intelligently written ruleset. It seems like you're a long way away from 200k pps, though.
Re: PFSYNC
On Sat, May 26, 2007 at 09:36:48AM +0200, Alberich de megres wrote: I know i repeat myself, but that's important for me: my pf isn't syncing tables i create. Can I solve this? Write a tool that synchronises your tables. The pfsync protocol as it stands is not an appropriate protocol for synchronizing tables, because it does not guarantee delivery, and provides only a best-effort basis at synchronising the state table (which is helped by the fact that messages on active states are sent frequently)
Re: Carp source routing ?
On Mon, Nov 27, 2006 at 12:16:13PM -, Pedro Hugo wrote: Is it possible to send packets with the carp address as the source address ? You have a few options: - Have the process bind to the carp address only (most daemons allow this to be configured as do some userland tools such as nc and ping) - Use pf to nat traffic to the carp address - Don't configure an address on the carp device's parent interface (only applies if the carp devices is then the route to the other endpoint)
Re: Firewall partially failing with high traffic
At 2006-11-14 13:03:51, Chris Cameron wrote: I can't (easily) give direct output from things like ifconfig or pf.conf as they're both huge and contain information I've been told we don't want to send out. Hopefully this doesn't prevent anyone from helping me out. If it's a problem with carp, it's going to be really difficult to resolve without seeing the ifconfig ouptut, but here are some questions that you might want to consider... - Do you have dedicated addresses on the carp parent interfaces? - Are all the carp devices on the master firewall MASTER; what about the backup? - Can you reach the 'dissapearing' network from the backup firewall? - Is preemption enabled? (sysctl net.inet.carp.preempt=1) - What is the output of 'netstat -sp carp' on both the master and backup firewalls? - What about the output of 'netstat -i'? Are there output errors on the offending interface? - Have you tried running with carp debugging turned on? (sysctl net.inet.carp.log=1)
Re: video hardware determination
On Wed, Nov 08, 2006 at 10:08:14PM -0500, Michael Hernandez wrote: When I got home... I looked... and low and behold... X was running just fine, and there was no xorg.conf to be found. Is that expected behavior? Of course not... Actually, that IS the expected behaviour from X now. It doesn't always work out that way though.
Re: vmware keyboard problem.
On Wed, Nov 01, 2006 at 04:50:50PM -0500, Der Engel wrote: VMware Workstation 3.2.1 is like a bit old don't you think? When can we expect your patches to make VMWare Workstation 5.* work on OpenBSD?
Re: OpenBSD AJAX
On Tue, Oct 24, 2006 at 12:55:09AM -0500, Sam Fourman Jr. wrote: is it possible to have a AJAX enabled Website hosted on OpenBSD? Yes the reason why I am asking is because Apache is version 1.3.x (due to licencing issues). if not Maybe there is another http server that would support it? AJAX not a particular server-side technology, but rather a set of techniques and tools for building interactive web applications. Most of the magic happens on the client side. Depending on what programming language you're using on the server side, there may be AJAX specific modules or frameworks. For example there appear to at least be some perl AJAX frameworks in our ports tree. Other languages may have similar tools.
Re: OpenBSD AJAX
On Tue, Oct 24, 2006 at 10:42:25AM +0200, Magnus Bodin wrote: On Tue, Oct 24, 2006 at 01:30:02AM -0500, Sam Fourman Jr. wrote: my next question is Would it be Possible to use AJAX from a CGI made with C running from Apache that Ships w/ OpenBSD? Yes. C, INTERCAL, ksh. Any application that follows the cgi protocol. But remember, PHP will corrupt your precious bodily fluids.
Re: new LiveCD instructions for OpenBSD
On Tue, Oct 24, 2006 at 02:37:05PM +0200, Andreas Bihlmaier wrote: On Tue, Oct 24, 2006 at 08:25:52AM +0900, vladas wrote: On 10/24/06, Andreas Bihlmaier [EMAIL PROTECTED] wrote: Is this LiveCD/DVD reliable enough to send in dmesg's from it? Exuse me, but I don't see a point in posting a dmesg for a livecd, which by definition is portable. The dmesg depends on the machine I insert it into. I /believe/ the poster is asking whether it can be used to plug into $RANDOM_MACHINE and mail a dmesg from that machine. Nice for scoping out potential OpenBSD systems in a shop provided you can get the sales droids to look away long enough for the reboot.
Re: PF binary search tree
On Thu, Oct 19, 2006 at 01:09:57PM -0600, Breen Ouellette wrote: From: Daniel Hartmeier (danielbenzedrine.cx) pf uses a binary search tree instead of a hash table, which doesn't require pre-defining a maximum size. The tree will just grow until memory allocation fails. With 64MB RAM that typically doesn't happen until you have over 6 state entries. I have been doing some research and I came across this message from some time ago. Is this still relevant? Yes. PF still uses a binary search tree. It should be pointed out that the ipf state tracking also has a maximum size, it's simply managed in a different way - there is a configurable number of hash buckets, and a limit to how many states can be in each hash bucket. Optimistically speaking, the number of entries would be the product of these two numbers. However, one advantage of the pf search tree is that it scales on a fixed curve as the number of states increases. Hash tables can fill unevenly, or be filled unevenly by an attacher. If so, can anyone tell me if the PF binary search tree is more or less memory efficient than the ipfilter hash table? I'd imagine they're approximately the same in terms of memory consumption, although I've not looked at how big state table entries are in ipf. What is the fallout if PF cannot allocate anymore memory for the binary search tree? Does it drop connections or puke all over? If you've set the maximum state limit correctly existing connections will continue to work, but new connections will fail until old connections time out. (I recommend testing on your specific hardware by creating enough states to reach the limit) Mechanisms such as adaptive timeouts (on by default in 4.0) will help to purge old states out of the state table more quickly as the state table fills. I am trying to convince my current employer to move away from ipfilter and over to PF. Any assistance would be appreciated. I think you're focusing on the wrong areas. Without having a clear understanding of your employer's requirements it's hard to come up with a specific argument, but think about security, ease of use, documentation, flexibility, reliability, and performance. Also important may be software licensing, standardisation, and the OS compromises you have to make to run IPF. PF is well established as the leader in all of these areas - you may find better performance in some other firewalls, but invariably this is because unacceptable security shortcuts have been taken. Some resources that you can look at to build your case are: http://www.benzedrine.cx/pf-paper.html http://www.openbsd.org/papers/auug2006/pf_evolution/ http://www.openbsd.org/faq/pf/index.html http://undeadly.org/cgi?action=articlesid=20060929080943 http://undeadly.org/cgi?action=articlesid=20060927091645 http://undeadly.org/cgi?action=articlesid=20060928081238 http://coombs.anu.edu.au/~avalon/ Often one of the most convincing arguments you can make is to take your existing IPF ruleset an re-write it as a PF ruleset. The vast majority of security problems are due to user error, and focusing on making your ruleset understandable and maintainable will likely bring the greatest security benefits. Using macros, tables, ruleset expansion, and interface groups, your ruleset will become smaller and more maintainable, and the difference is instantly visible.
Re: carp(4) debugging
On Tue, Oct 10, 2006 at 05:50:50PM -0400, Brian A. Seklecki wrote: Certainly a way to log events (interfaces, etc.) and the resulting actions taken by the code would be useful in mission critical environments. Anything beats tcpdump 'proto carp' and making guesses from there. Nothing new to 4.0, but a few of the things you can do besides using tcpdump are: route monitor - see interface link state change sysctl net.inet.carp.log=1 - generates primarily protocol error messages netstat -sp carp - display a number of relevant counters If you want to do more complicated things, like run commands when carp interfaces change state, you can have a look at ifstated. -Ryan
Re: WLAN-Sec-Tools for OpenBSD?
On Tue, Oct 10, 2006 at 08:31:25PM -0500, Sam Fourman Jr. wrote: for what is it worth I would like to say thank you for porting kismet, I use it all the time, because I do not know of another tool to scan for available AP's ifconfig -M dstumbler (in security/bsd-airtools)
Re: Loading pf rules at boot with '-o' flag to pfctl...
On Sun, Oct 08, 2006 at 01:53:42AM -0400, Martin Gignac wrote: Is there any plan to add a variable in /etc/rc.conf to achieve this, or is using '-o' during boot considered a bad thing? The plan is to make it possible to specify the optimization level directly in the pf.conf file (which one could override on the command line) Unfortunately it's not a trivial change - the way the parser is set up right now you have to know whether to apply optimisation before you start reading the pf.conf file, so reading it from the file is not currently an option.
'flags S/SA keep state' now the default
I've just committed code based on a suggestion made by Daniel Hartmeier
to make flags S/SA keep state the default for rules.
NOTE: This does change is in -current only, and does not apply to the
4.0 release.
These changes makes pf rulesets significantly cleaner, improving
readability. More importantly, it makes the recommended behaviour the
default, something that OpenBSD tries to do wherever possible.
- Stateful filtering should be used on most rules for performance as
well as security reasons, and stateless filtering is by far the
exception.
- The flags S/SA change ensures that for TCP connections only initial
syn packets can match a rule and create a new state. While PF supports
creation of state on intermediate packets, it makes application of some
security mechanisms impossible, and it makes PF unable to correctly deal
with TCP window scaling on the connection. This has increasingly become
a problem as more OSs ship with window scaling and increased buffers
enabled by default.
Most users will not see any consequences of these changes, but there are
a few cases where this has impact:
* Users who are doing stateless filtering on purpose
* Users who expect to be able to flush their state table, fail
over without pfsync, or reboot their firewall and have the
states recreated from intermediate packets.
Users in either of these categories should use the 'no state' and/or
'flags any' options where appropriate to explicitly request the current
behaviour of their ruleset.
- Forwarded message from Ryan Thomas McBride [EMAIL PROTECTED] -
Date: Fri, 6 Oct 2006 04:45:44 -0600 (MDT)
From: Ryan Thomas McBride [EMAIL PROTECTED]
Subject: CVS: cvs.openbsd.org: src
To: [EMAIL PROTECTED]
X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=ham
version=3.1.1
CVSROOT:/cvs
Module name:src
Changes by: [EMAIL PROTECTED] 2006/10/06 04:45:44
Modified files:
sbin/pfctl : parse.y
Log message:
Make 'flags S/SA keep state' the implicit for filter rules, based on
a suggestion from [EMAIL PROTECTED] Also add 'flags any' and 'no state' options
to disable flag matching and stateful filtering respectively.
IMPORTANT NOTE:
Current rulesets will continue to load, but the behaviour may be slightly
changed as these defaults are more restrictive. If you are purposefully
filtering statelessly ('no state') or have a requirement to create states
on intermediate packets ('flags any') you should update your ruleset to
make use of the new keywords to explicitly request the behaviour.
Note that creation of states from intermediate packets in a connection is
not recommended, and will increasingly cause problems as more OSs enable
window scaling and increase buffer sizes by default.
ok dhartmei@ deraadt@ henning@
- End forwarded message -
--
Re: FTP Account Lockout
The company I work for is required to get PCI (Payment Card something-or-other) certified in order to keep doing some of the things that we are doing with credit card payments. Payment Card Industry Data Security Standard [snip] However, now that we need this cert, one of the few things still standing in the way is the requirement that we set up the FTP server to lockout (for 30min.) any account that fails to login 3 times in a row. You mean besides the fact that you're running FTP at all, right? - PCI requires that all passwords are encrypted in transmission, and FTP doesn't do this. - Depending on how you interpret the wording, PCI either prohibits or strongly discourages the use of FTP from 'untrusted' networks/hosts Consider replacing your FTP solution with scp/sftp. -Ryan -- Ryan T. McBride, CISSP - [EMAIL PROTECTED] Countersiege Systems Corporation - http://www.countersiege.com PGP key fingerprint = 5A63 31A0 B2E0 4A64 3D16 C474 99A7 BEFE F9BA A8E0
Re: CARP Backup Interfaces
On Wed, Oct 04, 2006 at 10:18:21AM +0200, Joachim Schipper wrote: I have two firewalls running CARP and pfsync for high availability. The physical interfaces do not have IP addresses, only the CARP interface do. The problem is is that the backup CARP interface still needs to be able to source and forward traffic. Is this possible? You could set up load-balancing CARP, which may work. No, this won't work. If you're trying to route some specific traffic to and from the backup firewall, perhaps passing it on the pfsync interface with some nat/rdr magic from the master firewall will do the trick. -Ryan
Re: More than 255 vhid's w/ CARP
On Wed, Aug 09, 2006 at 07:33:08PM -0400, Jason Dixon wrote: Unless you're using more than 255 VLANs (unlikely), you don't need that many vhids. Also, if the carp(4) devices are connected are on different VLANS (distinct layer 2 segments), you can use the same vhid on multiple interfaces.
Re: carp in PF interface context.
On Tue, Aug 08, 2006 at 12:33:23PM +0200, Henning Brauer wrote: Why the carp interface cannot be used in context of the interface? well, because it is that way. Because of the way that the routing currently works, if both the carpdev 'physical' interface and the carp interfaces have addresses on the same subnet, incoming traffic to the carp address will appear on the carp interface, while outgoing traffic will appear on the physical interface. This causes some confusion for PF in the case of interface-bound states, and perhaps some other situations. If there is no address on the same segment on the physical interface, both directions of traffic traverse the carp interface. Rather than try to explain that you need some kind of hacked up workaround in case A (which gets easier with interface groups, but probably would need some code changes to be really useable), and a different approach for case B, we decided to make all traffic appear on the physical interface. It's a single case to remember, and the behaviour is consistent. We may have the opportunity to fix this behaviour in the future, as changes are made to the routing code, and changes are being contemplated for CARP routing behaviour. But for now, henning is correct. Because it is that way.
Re: kernel settings for pf default block
On Wed, Jul 05, 2006 at 02:36:44AM -0400, Nick Guenther wrote: #pftcl -f all echo block all | pfctl -f - then the switch over to the new ruleset is pretty snappy and hardly enough time for any malicious packets to get through. Flushing the ruleset is totally unneccessary when loading a new ruleset. Simply do: # pfctl -f /etc/pf.conf If there is some kind of error in your new ruleset, nothing changes - you're still running with your old ruleset. There is no window with no firewall rules unless you explicitly ask for it. Even with a default block policy in the kernel, what if you load a pass all ruleset for known/unknown reasons? The fact is that if you're root, you can do stupid things. Get used to it, and grant access appropriately.
Re: carp with hosts in different vlans
On Mon, Jul 03, 2006 at 04:58:09PM +0200, Sebastian Reitenbach wrote: I can setup a tunnel between both hosts, and route the mulitcast packets through the tunnel and then have the IP address shared between the two hosts? No. CARP does not accept packets that have crossed a router, to prevent external spoofing of carp packets. Get your colo to change their switch/router config to put your boxes on the same ethernet segment, put both of the boxes on a switch that you manage that connects to one of your colo's switch port, or change colo providers.
Re: FW: Ntop, Nw. Board Mfg, and CARP
On Sun, Jun 25, 2006 at 01:55:24PM -0400, Barry, Christopher wrote:
display format of the host. One selection is network board
manufacturer, based on MAC allocation I'm guessing. My CARP
interface says the mfg is U.S. Department of Defense.
CARP uses the same MAC address range as VRRP. From the VRRP RFC:
7.3 Virtual Router MAC Address
The virtual router MAC address associated with a virtual router is an
IEEE 802 MAC Address in the following format:
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
The first three octets are derived from the IANA's OUI. The next two
octets (00-01) indicate the address block assigned to the VRRP
protocol. {VRID} is the VRRP Virtual Router Identifier. This
mapping provides for up to 255 VRRP routers on a network.
Since IANA comes from DARPA, it's not particularly surprising that the
manufacturer would be listed as the U.S. Department of Defense. However,
the relationship between DARPA and IANA is less direct now and the
influence of large corporations is increasing - it's probably more
technically accurate to list The Military-Industrial Complex as the
manufacturer.
Re: Doubts about OpenBSD security.
On Thu, Jun 22, 2006 at 01:04:00PM +0100, Constantine A. Murenin wrote: On 21/06/06, Joco Salvatti [EMAIL PROTECTED] wrote: So the attacker could enter in single user mode, without the need for the root password, and load a malicious kernel module. The attacker cannot load a malicious kernel module on OpenBSD, because OpenBSD specifically does not support loadable kernel modules for good. :) Oh yeah? I guess I must be imagining things when I start vmware :-) anchovy1:~$ uname -a OpenBSD anchovy.countersiege.com 3.9 GENERIC#58 i386 anchovy1:~$ modstat Type Id Off Loadaddr Size Info Rev Module Name DEV 0 29 e8d01000 0001 e8d01220 2 linuxrtc DEV 1 30 e8d7b000 0005 e8d7f300 2 vmmon DEV 2 31 e8dfa000 0002 e8dfbce0 2 vmnet
Re: arpbalance + pfsync
On Mon, Mar 27, 2006 at 12:32:31PM +0900, Jason Stubbs wrote: Same main question as in the last thread I posted to, but without any of the distractions. Can a pair of redundant firewalls be used with arpbalance without being affected by the state race? It should work fine with arpbalance, as there shouldn't be a state race; effectively each host is being served by only one firewall unless there is a failure. What version of OpenBSD are you trying to do this with? There have been some bugs fixed in both the pfsync and arpbalance code over the past year... -Ryan
Re: Pf questions for larger implementation
On Wed, Feb 22, 2006 at 08:39:36PM -0500, Nick Holland wrote: Steve D. wrote: Hi, I'm setting up a gateway (1.7 Ghz machine with 1 Gig of ram) for 700+ users using pf with NAT and BINAT's (90% NAT).I would like to know if anyone has any recommendations on tweaking the runtime options in PF. This box will pretty much just be handling the natting with a bare minimum of filtering, just enough to keep the box secure. Yes: DON'T TOUCH ANYTHING UNTIL YOU KNOW WHAT THE GOAL IS. Apparently, there are some OSs people are used to that ship in a nearly useless state, at least judging by the queries like this. With OpenBSD, you aren't supposed to have to tweak things..it should Just Work. See if you run into a problem. Don't start twisting knobs until you see if there is a reason to do so, and until you know what the desired outcome is. The defaults are set pretty darned well to start with -- you are much more likely to break something by tweaking than you are to improve anything. Normally, I would agree with this. And you're right as far as non-pf tweaking. But he's already stated that he's going to be running this system in a please rape my client systems configuration, not as a firewall with a sane default deny ruleset. Go ahead and deploy it with the basic defaults, but when the first worm hits those client systems and you find yourself wondering why existing connections still work but new connections fail, check first to see if your state table is full. In my opinion if you're talking about NATing 750 Windows boxes doing regular Windows-type things, you're going to want to at least at crank the limits on states and turn on adaptive timeouts; I wouldn't go any further than that unless you run into actual problems, but you can also think about using some of the other connection limiting features to prevent trojaned systems from filling the state table and impacting other users. Things to think about (roughly in order of aggressiveness): - 'set limit states' - adaptive timeouts - 'set optimization' I would consider these three Normal tuning for a firewall deployment like this. The default configuration is constrained somewhat by the fact that we want it to work well on systems with limited memory, so they don't totally reflect reality for a more serious firewall. We've talked about turning adaptive timeouts on by default, though. Maybe I'll get around to that after 3.9. - 'max-src-states' on outgoing connections - 'max-src-conn-rate' on outgoing connections These are tweaky. You need to understand exactly what problems you're trying to solve, and what the side-effects are going to be. -Ryan
Re: carp + no ip address on iface (only master can receive acks)
On Thu, Nov 17, 2005 at 03:02:56PM +1100, Alex Strawman wrote: ok, now this makes sense, how is the next hop meant to send packets back? it sends them to the mac address the carp0 is broadcasting, which the master happily accepts, only to see its not in its state table, and drops it. the backup system doesn't get it's acks back.. Traffic shouldn't even be getting OUT on the backup in this situation. is there currently a way around this Get more IP addresses.
Re: pf beginner: my firewall passes tcp but not icmp
On Fri, Nov 04, 2005 at 07:22:33PM +1100, Cameron Simpson wrote: I was imagining the keep state stuff handled that. So - for my mental model - a packet being forwarded traverses the rules twice: once on the way in and once on the way out? Yes. Well I'd reduced my test to pinging the firewall itself. An earlier tcpdump was showing pings coming in and no replies. Would that imply pings arriving and being dropped, and thus no replies attempted by the OS? Maybe. The replies could also be happening, but be dropped by pf. You can look at 'netstat -sp icmp' to see if they're getting beyond pf and what the kernel is doing with them. bpf (and thus tcpdump) happens before pf incoming, and after pf outgoing: wire - interface - bpf - pf - routing - pf - bpf - interface - wire
Re: carp incorrect hash debugging
On Thu, Nov 03, 2005 at 06:11:20PM -0500, Jon Hart wrote: 1) used to determine that a particular carp packet is intended for you carp host? carp(4) does a number of validity checks before treating the packet a real carp packet: - was the device recieved on a interface that has a carp device on it? - is the ttl 255 (prevents routed carp packets from being accepted) - packet length - crc32 checksum - VHID - Is the carp interface UP and RUNNING? - version - SHA-1 HMAC 2) given that a carp host knows that a particular carp packet is one that it cares about, how does it verify that all of the parameters contained within are legit? It checks the HMAC, which contains the password, version, counter, type, and the addresses. [snip] If the answer to all this is to just ensure that if I ever have more than one carp pair on the same network to ensure that I have different vhids, Yes, you MUST use a different vhid for different carp clusters on the same link-local network; the MAC address for the carp interface is generated from the vhid, and if you don't keep this unique your switch will likely get confused. does anyone have a vhid numbering scheme that they've found workable? I had been using interface number +1 (so the carp for em0 would be vhid 1, etc). In many situations, I use the last octet of the first virtual IP address. (If your virtual IP is 192.168.0.23, use 23 as your vhid)
Re: arpbalance bug?
On Sat, Nov 05, 2005 at 04:05:17AM +1300, Josh wrote: Is this anything to be concerned about? http://www.isrc.qut.edu.au/people/mbradfor/openbsd-carp-arpbalance.html Only if you use arpbalance in a situation where it really matters (as opposed to a situation where you use it because you think it's cool) It will be fixed shortly: http://marc.theaimsgroup.com/?l=openbsd-techm=113098794012511w=2
Re: pf beginner: my firewall passes tcp but not icmp
On Fri, Nov 04, 2005 at 05:16:22PM +1100, Cameron Simpson wrote: [var/[EMAIL PROTECTED] pfctl -s rules block return all pass quick proto tcp from any to any port = ssh flags S/SA keep state pass in quick proto icmp all keep state ^^ How are the packets supposed to get OUT of the firewall? You have to think of the traffic crossing both interfaces. (I have also tried pass quick proto icmp all with no useful effect.) With the simple ruleset above, or something more complicated? This should work (as should the above without the direction) Also, I have seen elsewhere in list archives debug output showing what rules got applied. I have not found out how to produce such debugging myself. Add the 'log' keyword to at least your block rule, and maybe your pass rules as well. Then do: # tcpdump -vvvpleni pflog0 -s 1518 I'm loading up the rules like this: pfctl -F rules -v pfctl -xm -f /etc/pf.conf -v echo YES Don't explicitly flush the ruleset like this, pf does that for you and with such a command you're running without any ruleset at all for at least a moment, more if your new ruleset is buggy and fails to load. What else can I do to further debug this? tcpdump on the pflog interface is probably the most powerful tool; you can also look at pfctl -si to see if packets are being dropped for some other reason than ruleset evaluation, and perhaps do tcpdump on the physical interfaces you think the traffic should be crossing, to see if it's maybe actually coming out on the other side but being dropped elsewhere on your network.
Re: garbage on pf state (with pfsync)
On Thu, Aug 11, 2005 at 07:02:35PM -0300, Luiz Ot?vio Souza wrote: Probably my problem is hardware (two cheap realteks for sync), but why the pfsync accept this malformed address, and why the kernel panic on flush ? (i can also get panic from a pf -F state). i can send more info if someone need. You apparantly missed the following in the panic message: RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb It would also be helpful to include the output of 'pfctl -vvss' with some of these 'malformed' states. Also have a look at http://www.openbsd.org/report.html
