Re: pfctl -s rules/tcpdump rule numbers
On Tue, Dec 31, 2002 at 10:55:14AM -0600, Joe Nall wrote: How do you determine which rule matched in -current? pfctl -vvs rules
Re: rdr problem
On Mon, Jan 27, 2003 at 09:30:03PM -0500, Scircuit wrote:
Any idea why this would cause a syntax error?
FtpPort={ , 7778 }
rdr on $ExtIF proto tcp from any to any port $FtpPort - $FtpServer port $FtpPort
You cannot use lists of ports for either the destination port or the
redirection port with rdr rules. In this particular case, you can
specify a range of addresses instead of the list:
rdr on $ExtIF proto tcp from any to any port :7778 - $FtpServer
(you don't have to specify the redirection port range since it is the
same as the destination range)
-Ryan
Re: table and nat/rdr
On Wed, Feb 05, 2003 at 04:35:57PM +0100, Stefan Sonnenberg-Carstens wrote: I noticed the table definition to pf rules, but the manpage and the section BNF rules state no possibility for using table inside nat/rdr rules. I thought this might be fine for some load balancing, because you could have an external script checking webservers (and load ?) and then adjusting the table accordingly. Is this planned ? Preliminary code to do this exists but has not been reviewed or tested. I'm not certain that it will EVER be added to the tree, but I can tell you that this functionality will certainly not appear in the upcoming release. -Ryan
Re: packet filtering
On Thu, Jul 31, 2003 at 12:42:10AM +0200, Mark Bojara wrote: fxp0 is the uplink interface and xl0 is the interface that the vlan is connected too. If i tcpdump xl0 I can see traffic from all the vlan's on it. pf and BPF aren't in the same place in packet flow. tcpdump gets packets much earlier on, and sees stuff that pf never gets, such as arp traffic, etc. This is why Daniel suggested testing with a 'pass log all' rule to see wheich interface pf was handling the traffic on, rather than looking with tcpdump. -Ryan
Re: packet filtering
On Thu, Jul 31, 2003 at 12:26:21AM +0200, Daniel Hartmeier wrote: I'm not entirely sure, but the assumption that the same packet will be filtered both on the real and the vlan interface (in both directions) might just be wrong. My experience is that the packet will appear on one interface or the other, but not both. IE if it is tagged with a vlan id which is associated with a vlan interface, it will not appear on the physical interface. -Ryan
Re: pf-icmp6
On Thu, Nov 06, 2003 at 06:01:23PM +0100, [EMAIL PROTECTED] wrote:
pass in log quick on $INT proto ipv6-icmp all ipv6-icmp-type{135, 136} from
$INTNET to $INTIP
pass in on $INT inet6 proto ipv6-icmp all ipv6-icmp-type echoreq
I have copy those rule on the book, but when I compile the first or the second
rule:
Syntax error in file: pf rules not loaded!
Your book is out of date. Use 'icmp6-type' instead of 'ipv6-icmp-type'
in OpenBSD 3.3 and higher.
-Ryan
Source Tracking in PF
I just committed code which adds support to track stateful connections
by source IP address. This allows a user to:
- Ensure that clients get a consistent IP mapping with load-balanced
translation/routing rules
- Limit the number of simultaneous connections a client can make
- Limit the number of clients which can connect through a rule
As always, the more people who test this and provide feedback, the
happier I am. Read below for details.
-Ryan
SYNTAX:
The 'sticky-address' keyword applies to translation rules; the
translation address will be selected from the list, but once a client
makes a connection, all subsequent connections are translated the same
way.
nat on $ext_if from $int_net to any - \
{ 10.1.2.1, 10.1.2.3 } round-robin sticky-address
Similarly in the following case, connections to a server are mapped
randomly, but all connections from a client are mapped the same way.
rdr on $ext_if from any to $ext_if - \
{ 192.168.0.4/30 } random sticky-address
In the case of tracking states per rule, the syntax is slightly
different. The 'source-track' state option is used to enable tracking,
limits can also be set there: 'max-src-states' limits how many states
from a single source can exist simultaneously and 'max-src-nodes'
limits how many source nodes can exist (effectively this is a limit
on how many clients can connect at once).
The following rule allows a maximum of 1000 source ip's to connect to a
webserver, each with a maximum of 3 simultaneous states:
pass in on $ext_if proto tcp to $webserver port www flags S/SA \
keep state (source-track, max-src-states 3, max-src-nodes 10)
By default, the source node is removed when all the states which
reference it are removed. However the timeout 'src.track' regulates
how long the source node is retained after all it's states have died.
set timeout src.track 900
A list of src nodes can be retrived with pfctl -sS, pfctl -vsS;
pfctl -vsi provides statistics on src-node useage (similar to the
statistics provided for states)
Re: Re[2]: interface improvements - help needed!
On Fri, Jan 09, 2004 at 09:41:45AM -, Peter Galbavy wrote: Alexey E. Suslikov wrote: b) uncomfortableness for people, who wants to have bunch of rules stated differently from their state policy default, instead of just constructing more hacking-proofing ruleset. If I understand correctly, Alexey is asking for a global option for the default behaviour. This would be neat. You mean like this? man pf.conf: ... set state-policy The state-policy option sets the default behaviour for states: if-bound States are bound to interface. group-bound States are bound to interface group (i.e. ppp) floating States can match packets on any interfaces (the de- fault). For example: set state-policy if-bound ...
Re: vpn client through pf/nat invalid cookie
On Thu, Jan 29, 2004 at 12:16:44AM -0500, David Kaplowitz wrote: I've been having some problems with a vpn client I use for work (Nortel Contivity). The problem is: I keep getting the connection dropped due to invalid cookie. I can sometimes connect (after about 5 tries), but I get booted out immediately. The Nortel Contivity has a broken IKE implementation that requires the _source_ port of the connection to be udp/500. You need to add another rule after you main nat rule(s) like the following, that forces the source port to 500: nat on $EXT_IF inet proto udp $LAN to any port isakmp - $EXT_IF port 500 Note that this means that you can only have one client inside your firewall connected to that particular Contivity at any given time. -Ryan
Re: vpn client through pf/nat invalid cookie
On Thu, Jan 29, 2004 at 10:04:22AM +0100, Jean-Francois Dive wrote: Well, this is not a bug but an initial requirement of the IKE RFC's. We can discuss about it's validity, but i doubt this can be considered as a problem with the conntivity. All the rfc says is that at minimum, an implementation must support sending and recieving ISAKMP using UDP on port 500. It says nothing about not accepting packets with different source ports: 2.5.1 Transport Protocol ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbers Authority (IANA). Implementations MAY additionally support ISAKMP over other transport protocols or over IP itself. -Ryan
Re: System crashing when load balancing
On Thu, Jan 29, 2004 at 06:04:10PM -0200, Rodrigo Borghette Schmidt wrote:
pass in on $int_if route-to {($ext_if1 $gw1),($ext_if2 $gw2)} round-robin
proto tcp from $mynet to any flags S/SA modulate state
pass in on $int_if route-to {($ext_if1 $gw1),($ext_if2 $gw2)} round-robin
proto {icmp,udp} from $mynet to any keep state
Just a quick note to point out that I just committed a fix to -current
which avoids having to split rules like these up just to have modulate or
synproxy on tcp connections. You can now do the following, and the
non-tcp rules in the expansion will be 'keep state' (TCP flags will also
be dropped, but this is existing behaviour):
pass in on $int_if route-to {($ext_if1 $gw1),($ext_if2 $gw2)} round-robin \
proto { tcp icmp udp } from $mynet to any flags S/SA modulate state
Re: Remotely Counting Machines Behind Nat
On Tue, Feb 17, 2004 at 10:39:27AM -0500, A. Wright wrote: Is there a way with pf to wash these ambiguities (window size, syn packet size, etc) away so that all outgoing TCP packets look the same? Maybe even set them to user-defined variables, as we already can with 'max-mss' and The most effective way to do this is to run in proxy mode: Don't allow your internal machines to make direct connections at all. Turn ip forwarding off on your firewall, and install squid, socks5, etc. Set up sendmail as a mail relay and named as a caching-only server for your inside boxes, and you're all set. This way, all connections come from your firewall box and have it's fingerprint. If you're really paranoid, you'll use the proxies to scrub identifying information (browser User Agent strings, etc.). Or you might decide this is all too much trouble, and just get an ISP with a decent EULA. -Ryan
Re: set limit src-nodes
On Fri, Feb 20, 2004 at 01:51:46PM +1300, Russell Fulton wrote: While looking for possible things to tweak that might affect connections I found the 'set limit src-nodes' in the pf.conf man pages. Am I right in assuming that since I don't use any tag rules that I can safely ignore this option? This option is not related to rule tagging; rather, it is related to the source address tracking features: translation rules with 'sticky-address', or pass rules with 'source-tracking', 'max-src-nodes', and/or 'max-src-states' options. If you're not using any of these keywords in your pf.conf, you can ignore this. It's fairly easy to see if you're running into your limits, however. If you look at the statistics provided by 'pfctl -si', there's a counter labeled 'memory', which is incremented whenever a packet is dropped by pf due to insufficient memory - including hitting your state table or src-node table limit.
Re: Brige, Traffic Shaping and FTP
On Mon, Mar 01, 2004 at 11:21:55PM +0100, Julien Bordet wrote: As I said, there may a user land solution. Some kind of global user space advisor daemon, helping packet filter to make complicated decisions, for example. Having a userland program doing blocking operations on kernel packet flow is not feasible. The way to do this is by completely passing the packets to the userland process, and having the userland process re-inject the packets. No real API change would be needed to do something like this. Configure PF to block and log the packets that you're interested in, and have a userland process that watches pflog and uses BPF to send out the packets that you actually want passed.
Re: State table across reboots
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote: I'm under the impression pf keeps the state table across reboots, but It does not.
Re: CARP question
On Sun, Apr 11, 2004 at 07:48:40AM -0600, Role Account for SysAdmin wrote: In my network I have 4 NICs 1) $ext /30 inet xxx.xxx.xxx.xxx 255.255.255.252 NONE 2) $dmz (part of a routable /26) inet xxx.xxx.xxx.xxx 255.255.255.192 NONE 3) $lan /24 inet 192.168.1.1 255.255.255.0 NONE 4) $air /30 (a nic to a wireless router, part of my wireless gateway). inet 10.1.1.1 255.255.255.252 NONE Will CARP work with my routable /30 address, which connects me to my ISP, the DMZ's routable /26 block, and the private /24 /30 I use for corporate LAN, and wireless gateway? The nasty workaround for this problem is to set the real address on the physical interface for both your boxes to the network address, and use the regular address as the carp address. So if your /30 is 192.168.6.64/30, you have the following: 192.168.6.64 - network address - assign to physical interface on both boxes 192.168.6.65 - gateway 192.168.6.66 - your address - assign to carp interface 192.168.6.67 - broadcast This is an unsavoury solution, and may break things, but I know that there are people out there using it. A better solution is planned for the carp code, but it's tricky. -Ryan
Re: carp / ip aliases
On Wed, Apr 14, 2004 at 09:34:06AM +0200, Tobias Wigand wrote: i am thinking of to replacing my single firewall setup with a failover pair using carp/pfsync. right now it?s one box with 3 nics (internal/external/dmz). i am natting the dmz hosts on the external interface 1:1, thus have a lot of ip aliases on the external interface. so, is it possible to give the carp interface aliases? if it is, whats the syntax? Yes, just add them as if the carp interface was your physical interface. /etc/hostname.carp0: inet 192.168.6.1 255.255.255.0 inet alias 192.168.6.2 255.255.255.0 inet alias 192.168.6.3 255.255.255.0 inet alias 192.168.6.4 255.255.255.0
Re: OpenBSD Router Carp
On Wed, May 05, 2004 at 02:42:42PM -0400, Amir S Mesry wrote: Well now I know the answer to my ifstated question I sent earlier as well I think, I just wonder if I grabbed a bad .tgz because in CVS it shows ifstated, yet I can't find it in my installs for some reason, could that be because it's not ready, or I just got a bad .tgz? ifstated is in the tree but has not yet been enabled in builds. So if you want to use it, you have do download the source and build it yourself. It will probably be in builds sometime between now and the next release. -Ryan
Re: scrub source code
On Fri, May 28, 2004 at 06:33:07PM -0700, SHAH,MEHUL wrote: I am looking for pf (specifically, scrub) source code. I downloaded the openBSD src but I am not a software guy and unfamiliar with the BSD src tree. You're looking for src/sys/net/pf_norm.c, but you might also be interested in the pf_test_state_tcp() function in src/sys/net/pf.c which handles the tcp sequence tracking magic.
Re: IP source tracking doc ?
On Mon, May 31, 2004 at 02:39:50AM +0200, Ed White wrote: Playing with custom pf.conf I've understood that source-track rule and source-track global permit to manage in a different way all the src IP states, however I'd like to receive some confirms. 1) pass in quick inet proto tcp to port 25 keep state \ (source-track rule, max-src-nodes 100, max-src-states 2) This means that a max number of 100 IPs could connect and that each of them could have a max number of 2 active connections to this port. Right ? Yes. 2) set limit src-nodes 3000 pass in quick inet proto tcp to port 80 keep state \ (source-track global, max-src-states 5) pass in quick inet proto tcp to port 443 keep state \ (source-track global, max-src-states 2) This means that a max number of 3000 IPs could connect and that each one of them could have a max number of 5 active connections to port 80 and a max number of 2 active connections to port 443. Right ? Yes.
Re: Pfsync not working
On Thu, Jun 10, 2004 at 11:46:28AM +0200, Xavier Beaudouin wrote: BTW, is it necessary to assign an ip to pfsync interface (this is a good question for pf gurus ?) Yes. pfsync is an IP protocol, and needs a source IP address.
Re: Pfsync not working
On Thu, Jun 10, 2004 at 04:08:55PM +, Ryan McBride wrote: On Thu, Jun 10, 2004 at 11:46:28AM +0200, Xavier Beaudouin wrote: BTW, is it necessary to assign an ip to pfsync interface (this is a good question for pf gurus ?) Yes. pfsync is an IP protocol, and needs a source IP address. I should clarify here that I'm speaking of the syncif, that is the physical interface that pfsync is using to transfer the data. The pfsync interface itself (pfsync0) does not need an IP address.
Re: Pfsync not working
On Mon, Jun 14, 2004 at 10:13:42AM -0700, Chris Golubski wrote: boxes insist on keeping a status of MASTER on CARP0. My hostname.carp0 looks like this on both machines (with differing vhids): The vhid has to be the same on all machines taking part in the same virtual host.
Re: 2 Masters despite advskew
On Thu, Aug 26, 2004 at 04:29:04PM +0100, Oliver Humpage wrote: Has anyone got *any* ideas why internally there's only one master, yet externally there are two? This is driving me nuts :) They're not seeing or accepting each other's messages for some reason. Check to make sure that the carp settings on the external interfaces are absolutely identical except for the advskew, make sure you have basic connectivity between them, and make sure that firewall rules allow CARP packets through. You might get some indication as to what is wrong by looking at 'netstat -s -p carp' on both of the hosts.
Re: is amd64 a good choice ?
On Wed, Sep 01, 2004 at 05:15:14PM +0200, Henning Brauer wrote: * Alain [EMAIL PROTECTED] [2004-09-01 16:04]: Can you give me your opinion about the choice between amd64 and i386 for an openbsd/pf firewall ? buy an amd64. you can still run that in i386 mode should something go wrong in amd64 mode, what I don't expect to happen at all. You also gain proper per-page execute protection in amd64 mode. And the amd64 will be faster in i386 mode than an i386.
Re: is amd64 a good choice ?
On Wed, Sep 01, 2004 at 03:09:49PM +0200, Henning Brauer wrote: You are speculating, and you don't really knwo what you are talking about here... sorry, no GigE chipset interrupts per packet. I beleive re(4) does, at least with the OpenBSD driver. But if you are using this cheap, low-end gigabit chipset for your high-performance firewall you are very, very silly. and if there should be one ditch it and use something better. Like em(4) or sk(4).
Re: preventing dos attacks with pf
On Thu, Sep 02, 2004 at 04:16:40PM +0200, Wolfgang Pichler wrote: an hour ago i was hit by a sort of dos attack (someone sent nearly 20 mails to our mail addresses in the form of [EMAIL PROTECTED]). I've now googled around to see if its possible to limit the number of connections from one ip with pf - but havn't found something useful. Can someone please point me to the right direction ? Look at the pf.conf manpage, especially for source-track and max-src-states
Re: pf expiring states way too fast (2 hosts using carp+pfsync)
On Mon, Sep 06, 2004 at 06:23:28PM +0200, Per G?tterup wrote: Now the problem is that states never seem to live more than a few minutes at the most (a few seconds tends to be the rule) even for active connections. I see web-connections and ssh-connections being terminated more or less randomly (and very fast - usually in seconds). The problem seems to be concentrated on the internal interface (the one with the 8 subnets) but I'm not sure this is 100% true. Creating stateless rules shows that this problem is definately related to states as everything works flawlessly (no disconnections) when the state system is bypassed. Anyone clueful enough to know what is happening? There was a bug in pfsync when using adaptive timeouts: http://marc.theaimsgroup.com/?l=openbsd-pfm=109351242125764w=2 This has been fixed in -current, you might want to try that.
Re: pf rdr with carp
On Tue, Sep 07, 2004 at 04:08:48PM -0700, Bryan Irvine wrote: I copied my rulesset verbatim from an exisitng firewall where everything was working perfectly, and now everything works perfectly except redirections to other hosts. the rdr for spamd, squid, and the ftp-proxy all work, but the ones for vnc do not. I was playing around with the rules a little that's why the one looks different, none of them work. Any ideas? It's impossible to know exactly what the problem is as you havn't posted your _whole_ ruleset. How this behaves varies a great deal depenting on whan $WAN is defined as. Is that the physical interface, or the carp interface? If it's the carp interface, this won't work. You'll need to pay some attention to where you use the carp interface: if you mean the IP, use the carp interface, if you mean the interface that the packets pass through, use the physical interface.
Re: perceived strange behavior
On Thu, Sep 09, 2004 at 08:40:23PM -0400, Jason Opperisano wrote: all use TCP Port 5190. all three connections appear to stay open once connected. the simple solution appears to be to set a NAT rule that only uses 1 translation IP for connections on TCP Port 5190. Or use the 'sticky-address' keyword.
Re: pf expiring states way too fast (2 hosts using carp+pfsync)
On Wed, Nov 10, 2004 at 04:14:59PM +0100, Per-Olov Sj?holm wrote: http://marc.theaimsgroup.com/?l=openbsd-pfm=109351242125764w=2 This has been fixed in -current, you might want to try that. Is this fixed in 3.6 release ? Yes. Wonder as I have random disconnects when the two firewalls are up at the same time. Which version are you running?
Re: CARP
On Thu, Dec 16, 2004 at 08:54:54PM -0500, Jason Dixon wrote: There is probably a good reason for this, but might be hard to determine a) for an experienced user without access to your network, or b) for an inexperienced user *with* access to your network. ;-) I suggest monitoring your interfaces continually (while true; do ifconfig -a | grep carp; sleep 1; clear; done) while you recreate your problems. It wouldn't hurt to also monitor your pfsync traffic for hiccups. 'ifconfig carp' works, no need for '-a | grep carp'. carp(4) state transitions also show up on the routing socket, so you can do 'route monitor'. I usually experience ~3 seconds of packet loss during a failover. Recovery is always instantaneous (no loss). Regardless, I've yet to lose any TCP connections. I'd suggest you try to isolate the questionable behavior. Sorry if I sound like a Loinux whiny, I'm almost there, just need a few more pointers. 1) If I reduce advskew to something like 10 on machine A and 12 on machine b, would that increase the stability of the firewalls? I suggest larger advskew differences. You can only go as high as the size of your segment (256-1 for /24, for example). If you're only using 2 firewalls, I suggest advskews of 0 and 100. This isn't documented anywhere, and is only based on my own experience, so YMMV. If by not documented you mean explicitly ignoring the examples in the carp(4) manpage, then you're correct :-) The advskew range doesn't depend on the network segment. It's an 8 bit number in the CARP packet and the legal values are 1-255. Keep the value below 240 unless you really know what you're doing. 2) Why does it seem that when the master returns from me issuing a reboot does the connection for the client appear to get shaky again? What is the value of 'sysctl net.inet.carp.preempt'? Those who want useful advice on a CARP problem should provide the output of the following (from both machines): $ ifconfig -a $ sysctl net.inet.carp $ netstat -sp carp
Re: Problems with state syncronisation
On Mon, Feb 14, 2005 at 10:20:44AM +0100, Andrea Mistrali wrote: Those lines are always relative to broadcast addresses. What can it be? If a packet reaches both firewalls, they will both create state; when they each recieve the state creation message from the other, the state already exists and the insertion fails. You can ignore the messages, or modify your ruleset so that broadcast packets don't create synchronised states.
Re: pf vs ASIC firewalls
On Mon, Mar 14, 2005 at 03:50:23PM +0530, Siju George wrote: Could Someone please tell me the advantages of PF against Firewalls using the ASIC technology in terms of Security and perfomance?? If there is a bug in pf, we'll tell you, and you can apply a patch. If there is a bug in your ASIC, and the vendor tells you at all, there are two options: go back to doing the packet processing in the underpowered CPU, or replace the hardware.
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: pfsync / load balancing
On Mon, May 08, 2006 at 06:21:47PM +0200, Daniel Hartmeier wrote: Can this be achieved using pfsync? If so, what do I need to do to get this working? If not, can pfsync be extended to allow for this or should we look into something different altogether? This currently won't work. pfsync does only synchronize state table entries, not rules. Since the firewalls can have different rules, no attempt is made to associate a state entry with a particular rule of the recipient's ruleset. Instead, such state entries are associated with the default pass rule. Because of that, many rule options (like source tracking in your case) are lost on the recipient node. Both firewalls would insert the other's state entries, but those would not be counted towards the limit. Ryan had plans to work on this, but I don't know about any progress. It's not something trivial, and may only work with completely equal ruleset (or at least well-defined mappings between rules on both nodes). Actually, preliminary code to match states to the correct rule is in 3.9: /* * If the ruleset checksums match, it's safe to associate the state * with the rule of that number. */ if (sp-rule != htonl(-1) sp-anchor == htonl(-1) chksum_flag) r = pf_main_ruleset.rules[ PF_RULESET_FILTER].active.ptr_array[ntohl(sp-rule)]; else r = pf_default_rule; If the rulesets are identical, states created by rules in the main ruleset are associated with the correct rule on the recieving firewall. This means that things like state limits, tcp timeouts, and queues will work correctly. You can check the ruleset checksum with pfctl -vsi, to make sure that the rulesets will support this function. Note that it doesn't work for anchor rulesets, and we're still not matching states to the correct NAT rule. Hopefully I'll get a chance to fix some of this stuff before the next release, possibly at the hackathon. -Ryan
Re: Logging (lack of), driving me nuts
On Fri, May 19, 2006 at 12:42:57AM +0200, Daniel Hartmeier wrote: Does this mean 'antispoof for carp0' is generally (always?) a mistake? Yes. If you've got the same subnet on your physical interface, you can safely do antispoof there however. As Chad showed, packets are seen by tcpdump on carp0, are they also filtered by pf on carp0 (i.e. twice, on carp0 and the real interface)? No, they're only filtered on the real interface. This is because you can get asymetric routes with carp interfaces if there are addresses within the same subnet on the physical interface. Incoming traffic will go to the carp interface, but outgoing traffic will go through the physical interface. henning@ has raised some shortcomings in the current carp routing behaviour to me, so it's possible that as we make changes in this area we can somehow fix this problem as well. Has this changed in the past? pf.c: revision 1.477 date: 2005/01/07 18:58:39; author: mcbride; state: Exp; lines: +7 -1 Make carp(4) traffic always appear on the physical (carpdev) interface from pf's perspective.
Re: pf default deny compile-time option?
On Sat, Jul 15, 2006 at 09:26:02AM -0500, Travis H. wrote: On the FreeBSD pf list someone mentioned that they wanted the ability to have a default deny policy with pf, like the old ipf kernel option. FreeBSD is free to add this option, if they'd like. That reminded me that I thought the same thing when I started with pf. I know, I know, it's not a terribly useful setup until the pass rules get loaded, but by enforcing default deny in both pf and in the rules, you're less likely to forget it in one place or the other. And yes, I'm aware that it is enabled in /etc/rc before /etc/netstart is even called. We're not particularly interested in making this change on OpenBSD. http://www.benzedrine.cx/pf/msg07442.html If a user has the power to flush a ruleset (an operation that shouldn't generally take place during regular firewall operations) they can just as easily load a pass all ruleset. Root can do stupid things which compromise security. Obfuscation or needles complexity in an attempt to protect yourself from the root account will only make your system less secure. BTW, the ruleset loaded in /etc/rc could use set skip on lo0, and quick rules, Because the /etc/rc ruleset is only temporary, and quite small, I don't see the point in making performance-related changes to it (particularly performance-related changes that one would have a hard time measuring the effects of) and make some allowance for DHCP. DHCP uses bpf(4), and is unaffected by pf rulesets.
Re: bringing pf (4) to OS X via Network Kernel Extension (NKE)
On Mon, Oct 30, 2006 at 01:41:48AM -0500, Joseph Gorse wrote: I'm posting my intention to port pf (4) (http://www.freebsd.org/cgi/ man.cgi?query=pfsektion=4) to an NKE for use as a replacement or complement to the current ipfw2 that is available in current Mac OS X. FreeBSD version will be interesting to from the perspective of a porting effort, because you'll see what portability gunk they've added. But you'll probably want to at least have look at the OpenBSD version. The FreeBSD port of PF lags somewhat behind ours, and there is a fair bit of active development currently being done. However, OpenBSD has traditionally made no particular effort to ensure that PF is portable across the BSDs, and some of PFs more advanced features depend on on features in other parts of the kernel. I'm not familiar with the OS X kernel, so I can't say how hard it's going to be to wedge the PF bits in there, but you may not be able to support everything without significant buy-in and assistance from other OS X developpers. I've posted my intentions in the darwin-dev list as well, asking advice about Apple's NKE. I am soliciting any advice you have before I undertake this task. It seems sane enough to me to want kernelland pf where my only current options ipfw2 with userland natd for NAT and throttled for QoS. Seems sane to me as well, and it would be nice to see the BSD standard for packet filtering available on OSX as well. Are you thinking of porting CARP and pfsync as well?
Re: PF Table Size - Sanity Check
On Mon, Nov 06, 2006 at 02:21:58PM -0800, Michael K. Smith - Adhost wrote: We are looking at pulling in a listing of about 70,000 IP entries (most of them are hosts, not subnets) into a PF Table. There is essentially no difference between a host and a subnet as far as tables are concerned in PF. Is there any hard limitation to the configuration size Yes. If you have too many table entries, your system will run out of kernel memory and stall/crash/etc. If you increase the limit (via 'set limit table-entries', you should The default table entry limit is 100,000, so I don't imagine you'll have a problem with 70,000 unless your system is extremely low on memory. or ability to parse through something that large? Not really. As far as packet filtering, the size of the table makes very little difference. The cost of table searches scales at O(log n); doubling the size of the table costs you a single comparison.
Re: Where is /dev/pf made?
On Wed, Nov 15, 2006 at 01:22:33AM -0500, Joseph Gorse wrote: This may seem like a silly question, but where exactly is the code that sets up the /dev/pf device? I am probably overlooking something extremely simple and it's probably because I am currently overwhelmed with a foreign OS source tree (obsd). /dev/MAKEDEV So far as I can see, /dev/pf either doesn't show up or isn't useful until /etc/rc.conf has pf=YES in it. Perhaps this has something to do with why I can't find it? No, it's there and useable even if you don't have pf=YES in rc.conf. Basically the rc.conf setting just loads a default ruleset, enables pf and pflogd, and loads your /etc/pf.conf if it exists. If you don't have that set, you can manually enable pf with pfctl at any time.
Re: Where is /dev/pf made?
On Wed, Nov 15, 2006 at 08:44:15AM -0500, Joseph Gorse wrote: As for downloading the system source tree, it doesn't immediately have a /dev/MAKEDEV. Does MAKEDEV support devfs or is it strictly the legacy style of devices? # THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT. # generated from: # # OpenBSD: etc.i386/MAKEDEV.md,v 1.36 2006/06/11 10:58:57 mk Exp # OpenBSD: MAKEDEV.common,v 1.30 2006/10/10 12:33:41 todd Exp # OpenBSD: MAKEDEV.mi,v 1.77 2005/10/06 06:43:19 otto Exp # OpenBSD: MAKEDEV.sub,v 1.14 2005/02/07 06:14:18 david Exp OpenBSD does not have devfs.
Re: keep state defaults with stateful tracking options.
On Fri, Feb 08, 2008 at 03:37:33PM +0700, Dmitry Medvedev wrote: Is that correct behavior what we need to specify keep state, which is should be by default? or I miss something? Yes, this is the correct behaviour when you're trying to set state tracking options. In the pf.conf(5) manpage: STATEFUL TRACKING OPTIONS A number of options related to stateful tracking can be applied on a per- rule basis. keep state, modulate state and synproxy state support these options, and keep state must be specified explicitly to apply options to a rule. -Ryan
Re: Need stateless NAT
On Wed, Apr 02, 2008 at 04:27:17PM -0700, Adam Richards wrote: Is there a no state directive for nat rules, similar to the no-state directive for filter rules? Or another clever way to use nat/rdr/filter statements? Even though I wasn't able to find any affirmative evidence in pf.conf(5) manpage I thought I'd ask anyway. While I'd prefer a yes pf can do this answer, I will accept a no...but here are the code sections you'll want to look at to start your patch work answer. ;) No, PF does not do this. Keeping state is required for NAT to work, because you need to keep track of the mapping so that the return packets can be translated back the other way; I'm guessing that your actual problem is not the basic state mechanism, but the TCP sequence number tracking. Look for the commend Sequence tracking algorithm from Guido van Rooij's paper in sys/net/pf.c for this code; it should be relatively trivial to add a bypass option for this in pfctl, and skip these checks in pf.c if that option is present. None of this is really a good idea though, and it shouldn't be seen as an appropriate response to a nasty network design. -Ryan
Re: Need stateless NAT
On Tue, Apr 08, 2008 at 11:59:11PM -0700, Adam Richards wrote: Maybe a pf.conf knob that allows me to turn off stateful tracking for a particular nat on iface ... rule? Ah, you keep mentioning 'nat' and 'rdr', which confused me before, but I guess what you're actually talking about is called 'binat' in pf: binat A binat rule specifies a bidirectional mapping between an external IP netblock and an internal IP netblock. You're right, it should be relatively easy to give binat a 'no state' option... But not for a /18 of arbitrary mappings with a high rate of change. With the current translation code this would require a rule for every mapping, and every packet is going to require a linear search of this ruleset. Fixing this is going to require fairly major changes to how binat works. Are you willing to pay someone to make this happen? BTW: What kind of packet forwarding rate are you hoping to get with this solution? Much of pf's performance comes from the fact that packets matching state entries are not evaluated against the ruleset. -Ryan
Re: Need stateless NAT
On Wed, Apr 09, 2008 at 05:36:57PM +0900, Ryan McBride wrote:
You're right, it should be relatively easy to give binat a 'no state'
option...
Try the attached diff, eg:
binat on egress from 192.168.100.1 to any - 10.99.99.99 no state
Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.567
diff -u -r1.567 pf.c
--- sys/net/pf.c20 Feb 2008 23:40:13 - 1.567
+++ sys/net/pf.c9 Apr 2008 11:41:02 -
@@ -3321,7 +3321,8 @@
return (PF_DROP);
}
- if (!state_icmp (r-keep_state || nr != NULL ||
+ if (!state_icmp (r-keep_state ||
+ (nr != NULL nr-keep_state) ||
(pd-flags PFDESC_TCP_NORM))) {
/* create new state */
struct pf_state *s = NULL;
Index: sbin/pfctl/parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.536
diff -u -r1.536 parse.y
--- sbin/pfctl/parse.y 1 Feb 2008 06:58:45 - 1.536
+++ sbin/pfctl/parse.y 9 Apr 2008 11:41:02 -
@@ -439,7 +439,7 @@
%type v.number number icmptype icmp6type uid gid
%type v.number tos not yesno
%type v.probability probability
-%type v.i no dir af fragcache optimizer
+%type v.i no dir af fragcache optimizer binatkeep
%type v.i sourcetrack flush unaryop statelock
%type v.b action nataction natpasslog scrubaction
%type v.b flags flag blockspec
@@ -3741,6 +3741,7 @@
memset(r, 0, sizeof(r));
r.action = $1.b1;
+ r.keep_state = 1;
r.natpass = $1.b2;
r.log = $1.w;
r.logif = $1.w2;
@@ -3889,8 +3890,12 @@
}
;
+binatkeep : /* empty */ { $$ = 1; }
+ | NO STATE { $$ = 0; }
+ ;
+
binatrule : no BINAT natpasslog interface af proto FROM host TO ipspec tag
- tagged rtable redirection
+ tagged rtable redirection binatkeep
{
struct pf_rule binat;
struct pf_pooladdr *pa;
@@ -3915,6 +3920,7 @@
binat.log = $3.b2;
binat.logif = $3.w2;
binat.af = $5;
+ binat.keep_state = $15;
if (!binat.af $8 != NULL $8-af)
binat.af = $8-af;
if (!binat.af $10 != NULL $10-af)
Index: sbin/pfctl/pfctl_parser.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_parser.c,v
retrieving revision 1.235
diff -u -r1.235 pfctl_parser.c
--- sbin/pfctl/pfctl_parser.c 15 Oct 2007 02:16:35 - 1.235
+++ sbin/pfctl/pfctl_parser.c 9 Apr 2008 11:41:02 -
@@ -986,6 +986,8 @@
printf( - );
print_pool(r-rpool, r-rpool.proxy_port[0],
r-rpool.proxy_port[1], r-af, r-action);
+ if (!r-keep_state r-action == PF_BINAT)
+ printf( no state);
}
}
Re: Need stateless NAT
On Mon, Apr 14, 2008 at 06:50:24PM -0700, Adam Richards wrote: And there's another nuance as well: on ingress I need dest re-mapped while preserving src, Yes, that's how binat works. and on egress I need src re-mapped while passing on the [preserved] src as the egress dest. I'm not sure I understand this bit. You want to reflect packets back to the source? Or by src here you actually mean the dst? To be clear, lets talk about this from the point of view of the ip header fields in the packet, not the source of the connection. You want this to be stateless, so we have to consider each packet independantly. You're right, it should be relatively easy to give binat a 'no state' option... But not for a /18 of arbitrary mappings with a high rate of change. I'm not so concerned with arbitrary mappings as I'll be statically configuring the mappings, maintaining them from outside pf. By arbitrary, I meant essentially random ie, You're not talking about mapping 10.29.4.0/18 to 192.168.64.0/18, you're talking about 10.29.4.192 to 192.168.67.12 10.29.5.1 to 192.168.66.250 10.29.4.9 to 192.168.64.99 [ cut 2^14 examples ] To your last sentence, what if they're static mappings, ie - not arbitrary, with a high rate of change? ;) With the current code, this will be super slow. Either you're reloading entire rulesets, or managing 2^14 anchors. Lots of linked-list walking involved. What happens in pf when a table has changed and pf need to re-read it? Will pkts get dropped? Adding/removing single entries from a table is a /relatively/ inexpensive and atomic operation, but it involves some cost to cross from userland to kernel. I imagine it can be pretty fast using a custom tool rather than calling pfctl. With the current translation code this would require a rule for every mapping, This is how I plan on using pf -- 1:1 statically configured translations. IOW I don't care about free-floating addr pools. Right. Although the free-floating pools might actually be easier to implement. and every packet is going to require a linear search of this ruleset. Fixing this is going to require fairly major changes to how binat works. Major changes, *if* we want binat to work with pools, right? Well, tables. I have plans to remove the 'pools' bits from the pf translation and routing code. It's basically a duplication of the tables functionality. If it the core binat code remains unchanged, I'd guess modifying the search algorithm to be something as simple as a bubble sort, or maybe a radix tree implementation (as is common in networking code I believe), would be fairly easy to someone familiar with pf's inner-workings. I could be over-simplifying it. radix tree implementation: that's what the tables are. There are already some other optimizations in pf and pfctl that deal with the ruleset, but they won't help too much case (dealing with a long list of nearly-identical rules). There may be some ways to optimize for this case, but I'm not sure it's worth the trouble. I'll have to think about this more. BTW: What kind of packet forwarding rate are you hoping to get with this solution? To be on par with my Linux colleagues running the latest netfilter/iptables code I'd need to get = 1Mpps on 10G links. Even though pkt sizes will obviously influence pps, most flows I deal with are rather short lived and contain, on avg, pkt sizes = 512B. I expect to find predictible inflection points. You will most certainly NOT get this with the current code, nor the diff I've posted. -Ryan
Re: Need stateless NAT
Trevor: I mostly agree with your analysis, and without more information about the actual problem Adam is trying to solve I'm chalking it all up to horrendous network design. That being said, part of PFs usefulness is it's ability to make some horrendous network situations manageable. So I don't think the ugliness of the problem precludes us solving it... especially since some of the actual issues with this (cost of table/ruleset updates, rule matching performance) are issues that affect many other pf users. A couple of inline comments: On Mon, Apr 14, 2008 at 07:49:43PM -0700, Trevor Talbot wrote: Maybe this will change in the future to where I may need 1:n mapping? Note that 1:N requires flow tracking, even if it's only as granular as remote:internal/remote:external address pairs. Somewere low down on my todo list is to use the src-nodes code in pf to handle M:N binat mappings, where M can be smaller than N, so long as no more than M nodes are active in a given period. In fact, something like this could possibly solve Adam's problem, given a tool to add/remove src-node entries. In order to get pf doing what you want, you'll essentially have to cripple the state engine to first remove the firewalling logic, then scale back the amount of state tracked until it's as dumb as you want. Then add an interface to add entries to the state table itself, instead of using the ruleset. Or build your own engine based off of pf's state organization. I don't think it's necessary to cripple any of pf's current behaviour to support what Adam wants, but it's certainly not going to be a trivial change to do it cleanly. That being said, a change which result in a simplification of this code is definately something we'd consider, and there's definately room for that in this code. And to Adam's comment: I would like preface my inline replies with stating what my original goal was, and still is, in starting this thread: I want to pursuade the pf community that stateless NAT is a desired feature and should be part of the core code. :) My use-case is just one example of how this can be a useful feature. I'm not convinced of this yet, but I agree that it's an interesting problem. I'm looking forward to seeing your reply to Trevor's analysis. -Ryan
Re: pfsync/carp races?
On Sat, Jul 12, 2008 at 04:12:14PM -0500, Karl O. Pinc wrote: I'm assuming that the pfsync mechanism (with syncdev) does more than expose changes, that it actually merges the existing state tables of the two machines. When a pfsync'd firewall boots, pfsync requests a bulk update of all states from the other firewall(s). Until this update is complete, it increases the carp demotion counter, preventing carp from taking over the virtual IP address. When the bulk update completes or times out, the demotion counter is decreased again. (The demotion counter is also twiddled in /etc/rc, and daemons such as bgpd and ospfd for similar reasons) considered the alternatives until just now. In my case I'd want the master's state table copied to the standby, but how would it know which is the master? It seems safest to just merge the state of the two boxes so that's what I assume pf does.) In the case of the system booting, we know that WE are not the master, but in general you are correct. The firewalls all synchronize their state tables whether they are master or not. Aside from dumping state tables on the master and standby boxes and comparing them, is there a way to ask if the state tables are synchronized? Not really, because pfsync makes no attempt to verify that the state tables are synchronized itself; for performance reasons the protocol makes no attempts at reliability, but rather tends towards complete synchronization. (For example, if the backup firewall somehow misses a state insertion message and sees an update for a state it doesn't know about, it will make an explicit request for that state. Knowing would help prevent shutting down the master when the standby is not yet synchronized. Don't shut your master down until all it's carp interfaces are in the MASTER state. What happened next was also a bit perturbing. While running the firewall on the standby box one of the disconnected applications was logged back in. Booting the master _again_ disconnected the application and returned it to the login screen. This should probably not be happening. Have you verified that pfsync messages are being recieved correctly? Try looking at 'netstat -sp pfsync', and try comparing the output of pfctl -ss; you can also tcpdump on the pfsync interface or the syncdev interface with -s 1518 to see the states being synchronized. (Which brings me to a slightly off-topic question about the demotion counter. I can't find where to RTFM. Just what's the relationship between the demotion counter value and advskew when it comes to deciding the state of an interface? You're right, this should probably be better documented in carp(4). The demotion counter applies to a whole GROUP of interfaces, while the advskew applies to each interface individually, and it does in fact override the advskew. I see this in the 4.2-4.3 changelogs: Changed rc(8) and netstart(8) so pfsync(4) is not brought up before the working ruleset has been loaded I don't believe this is critical, but it means that if your rulesets are identical across firewalls the synchronized states are more likely to get associated with the correct rule.
Re: Tuning PF Round Robin and State Expiration
On Wed, Oct 08, 2008 at 04:03:14PM -0700, Mike Sweetser - Adhost wrote:
rdr on ! $vlanX_if proto { udp tcp } from any to $web_183_ext port { 80
443 } - web_183_roundrobin round-robin sticky-address
It's working - too well. We're noticing that it's round-robining not
only based on the IP address, but the port as well - connections from
the same machine to ports 80 and 443 are hitting different servers:
[snip]
Is there any way to set this so that a given client IP will hit the same
server in the pool, regardless of port?
This rdr rule is actually expanded by the parser into two separate
rules, so the round-robin is handled differently by the two.
Use 'keep state (source-track global)' on the inbound filter rule that passes
this traffic, and you should see the same mappings being used for all
connections.
In addition, we're noticing that states seem to expire pretty quickly -
sometimes in less than a minute. We're currently using set
optimization normal - will changing this to conservative help matters?
Is there a way to modify the state timeouts on a more granular level?
Normally TCP connections in the ESTABLISHED state will remain around for
24 hours after the most recent packet. If your states are being torn
down in less than a minute, it's because the 3-way handshake is not
completing, either one of the endpoints are terminating the connection,
or you're reaching the state limit and adaptive timeouts are kicking in.
Have you changed the state limit, or the adaptive.start and adaptive.end
timeouts from the defaults?
-Ryan
Re: PF, packet sizes and icmp replies
On Tue, Nov 18, 2008 at 10:36:48AM -0800, [EMAIL PROTECTED] wrote: Today I was shocked when I found, what PF doesn't support filtering by packets size and can't answer by admin-generated icmp code (for example, by icmp code 1 admin. prohibited). And don't tell me that it is useless. Packets size: We already had users attacks, then huge count of full- sized icmp-packets (echoreq) brings our network/servers down. In IPFW filter we might avoid it by just one simple rule - $ipfw add 123 deny icmp from any to any iplen 500-1500 in. In PF we could have almost nothing -max-conn-rate works only with TCP. I'm pretty sure this is useless enough that it doesn't justify the code bloat. Typically the performance costs of packet handling depends more on the number of packets, not the size of the packets. So a smart attacker will send many small packets rather than fewer, bigger packets anyways. Of course if you're concerned about your upstream bandwidth being consumed, whether you drop it on the firewall or not makes little difference. My personal suggestion would be to decide how much ICMP traffic you're willing to handle, and rate-limit it with altq rather than trying to sent arbitrary packet size limits, which may have unintended side effects. Admin-generated icmp codes: With IPFW we could return icmp code 1 then user tried to connect to closed ports (especially with SMTP port for spammers) . With PF we could block only by silent drop, or ICMP unreachable. It's not enough. 1) It's not clear to me why you don't want it to return the default ICMP unreachable/port unreachable. But sure, suit yourself. 2) This feature has existed in PF from the beginning. See pf.conf(5): return-icmp return-icmp6 This causes ICMP messages to be returned for packets which match the rule. By default this is an ICMP UNREACHABLE mes- sage, however this can be overridden by specifying a message as a code or number. and return= drop | return | return-rst [ ( ttl number ) ] | return-icmp [ ( icmpcode [ [ , ] icmp6code ] ) ] | return-icmp6 [ ( icmp6code ) ] i.e. 'block return-icmp ( host-prohib ) in' For example: block return-icmp ( host-prohib ) in P.S. By the way, no chance to shaping like ipfw(dummynet), by getting mask for all ip addresses? It's the last reason to stay with ipfw: No, there is nothing like this in PF right now. It's on my list of things to look at, but that list grows faster than I can get things done... -Ryan
Re: reading pf log files on non Open BSD systems
On Wed, Nov 19, 2008 at 01:13:32AM +, Stuart Henderson wrote: On 2008/11/19 13:48, Russell Fulton wrote: Does anyone have any suggestions as to how we can get data in pf log files into pcap files that can be read (and filtered) on other systems. the packets have a struct pfloghdr header as described in pflog(4); this could be chopped off. I'm not aware of existing software that does this, but it would be simple to code. net/tcpreplay includes a utility called 'tcprewrite' that remove this information (or rewrite it with whatever you want). other systems may actually understand the pfloghdr data and know how to present it. If they don't, ask for it. The information in there can be very useful. -Ryan
Re: [pf] Re: Weird behaviour with pass out _keep state_
On Fri, Mar 13, 2009 at 10:15:06AM +, Stuart Henderson wrote: On 2009/03/13 10:25, Jeremie Le Hen wrote: It doesn't seem to be possible to disable sequence number/window tracking. Does it? It's possible if you port the sloppy state handling code from OpenBSD.. Using 'sloppy' is a bad idea, and not recommended unless you really, reallly know what you are doing. If you think you need to use it, you are most likely wrong and have either a bad network design or broken software. Fix those instead. I would only consider using 'sloppy' if BOTH of the following are true: a) There is a compelling performance or network architecture reason for doing so, such as asymetric routing or relayd with 'direct server return'. Avoid these if you can. b) All boxes which recieve TCP connections through these 'sloppy' rules are running OpenBSD -current or supported -stable; or there are additional layers of firewall further in on your network which don't use 'sloppy'.
Re: pf is blocking too much connections?
Looking at these stats, I would guess that you are running with the default limit of states, 10,000. You have nearly 10,000 in your state table now, and every time you get to the limit, new connections fail (the 'memory' counter: 13.7/s). You can check with pfctl -sm, and change the limit with 'set limit states'. You didn't say which version of PF you're running (or on what platform for that matter), but you may also want to look at the adaptive timeouts to reduce pressure on the state table. On any sane version of PF, this is enabled by default (you can check by looking at the adaptive.start and adaptive.end values from 'pfctl -st'; they should be 60% and 120% of the state limit by default) -Ryan P.S. In the more general case, you can use tcpdump on the pflog interface, assuming that you're using the 'log' keyword on your block rules, to see what is being blocked. But there are many things inside PF which will drop packets without logging, which is what you see in the counters below. On Fri, Nov 13, 2009 at 09:03:25AM -0800, LeiV wrote: I have a openbsd pf firewall protecting a web server, I have noticed that some pages gives me errors when browsing through my site (sometimes it works sometimes not), then I looked at pf and saw that is blocking a lot of connectyions, how do I know which connections is blocking? # pfctl -s info Status: Enabled for 202 days 23:34:57 Debug: Urgent Interface Stats for bge0 IPv4 IPv6 Bytes In 1637636412652 1992 Bytes Out 19542535823270 Packets In Passed 6000993286 31 Blocked 1256202280 Packets Out Passed 63791901300 Blocked 433053010 State Table Total Rate current entries 9656 searches 25855533798 1474.3/s inserts 2050396787 116.9/s removals 2050387131 116.9/s Counters match 2334111432 133.1/s bad-offset 00.0/s fragment 640.0/s short 200.0/s normalize 00.0/s memory 240838837 13.7/s bad-timestamp 00.0/s congestion 1180.0/s ip-option 00.0/s proto-cksum00.0/s state-mismatch2758840.0/s state-insert331102301.9/s state-limit00.0/s src-limit 00.0/s synproxy 00.0/s
Re: synproxy and RST (non-listener)
On Sat, Oct 23, 2010 at 02:51:11AM +0300, Nerius Landys wrote: Thanks for the reply. But I don't _completely_ understand. I don't know too much about operating system calls, but let's say that I have a program that is bound to TCP port 8080 on my local machine (same machine that is running the pf in question). Let's say I launch another program that tries to listen on this port as well. Of course it will fail with cannot bind to port or something like that. So there _is_ something the operating system tells us regarding a port being bound on the local system, and this [presumably] does not require any packets to be sent. Could we do a similar check before completing a handshake with a client via synproxy? Yes, in the case where the synproxy rule is protecting connections to a local machine, in theory PF could be modified to check whether there is a service listening on that port. It would be a lot of code for not much benefit, though. OK I may already know the reason why this isn't an elegant idea, and correct me if I'm wrong. The synproxy could be proxying a connection to another host (meaning my service listening on port 8080 is running on a _different_ host than the pf machine). This is the main use-case that synproxy is intended for. Protecting other machines from resource exhaustion caused by an excess of uncompleted 3-way handshakes. For example, let's say pf is configured to forward port 8080 to an internal machine (like 192.168.0.2) that is running a service on port 8080. Then, there is no way of predicting whether there is a service running on port 8080 on that internal machine. Am I thinking along clear lines here or am I missing something? This is correct. To be 100% clear, the simplest solution to the synproxy problem you've described is this: Don't use synproxy if you aren't sure that there will be a service listening on the port.
Re: 'all' interface group seems to be missing
On Sat, Nov 13, 2010 at 11:54:28AM +0100, Christopher Zimmermann wrote: It seems that there is no 'all' interface group as documented in ifconfig(8) or at least pf.conf cannot use it. Hmmm. I'll have to look at this more closely. However, I think what you want in this case is actually (self), since you're in address, not interface context.
Re: pf and altq setup
On Tue, Feb 22, 2011 at 02:18:10PM +0100, Mikkel C. Simonsen wrote: Stuart Henderson wrote: Basically don't use queues named foo_in and foo_out, just use a single name foo, defined with queue foo on $tdcif and queue foo on $sirif. See the list archives for more; this has come up several times. If using separate names is wrong, why does the sample in the pf FAQ use that method? Using separate names is not 'wrong', it depends on what you're trying to accomplish. But you're right, the PF guide could probably be improved to cover this. But I tried making this change, and many others. I could get either the incoming or outgoing traffic to pass through the correct queues, but not both at the same time. What Stuart has suggested DEFINATELY works, so perhaps sharing your attempts at doing that would allow us to help you out. The final version (so far) uses only pass out, and no pass in rules. I also had to add no state to all the rules, to get the traffic through the queues. How much performance penalty do you get by not using states? It depends on a number of factors: - the size/complexity of your ruleset: the cost of each packet is related to the ruleset, but it's impossible to say something like if you have X rules, 'no state' will be Y times as expensive because there are several layers of optimization that will affect the average cost. - how many states you have (if some of your rules are stateful, you will probably have some entries in your state). State table evaluation happens before ruleset evaluation, so all your 'no state' packets get evaluated against the state table anyways. The CPU of the system is an 800MHz Via Ezra, so it should be fast enough I guess. Is it possible to get it working with states? 'fast enough' is relative, but there is nothing preventing such a box from working stateful rules and altq.
Re: Fwd: Re: double NOT in rules is not working as expected
I really think this violates your intended KISS principle, and you
would be a lot better off by simply making a file that contains
/somefile and /someotherfile, and load all that into one a 3rd table to
be used when you want both, eg.
table listab persist file /someotherotherfile
block in quick on $if from ! listab to D.D.D.D...
However, another way to get the effect you want is:
pass in on $if from lista tag LISTAB
pass in on $if from listb tag LISTAB
block in quick on $if net from any to D.D.D.D ! tagged LISTAB
(you can use 'match' instead of 'pass' for the first 2 rules if you're
using a recent enough version of PF)
-Ryan
On Fri, Apr 08, 2011 at 06:39:47PM +0300, Bojidara Marinchovska wrote:
Yes, I wrote about negation in tables, there is enough examples of its
usage in the Book Of PF, but it is not what I need ( following KISS )
Anyway thank you all
I try to accomplish something which is correct to be done with no
firewall but with other software and I try to use as simple as possible
rules
I have 2 types of lists with IPs which I put in tables (because these
IPs changes often and I don't want to reload rules, it is easy to add
just the new IP address)
tablelista persist file /somefile
tablelistb persist file /someotherfile
IPs from list A have to be able to access IP A.A.A.A,B.B.B.B,C.C.C.C,
D.D.D.D and E.E.E.E for example ( protocol, port )
IPs from list B have to be able to access for example only D.D.D.D and
E.E.E.E
# block access to A.A.A.A - C.C.C.C for all except listA
block in quick on $if inet proto protocol from !lista to A.A.A.A...
port ...
# here I wanted to be able to use something like to allow listA and
listB to access D.D.D.D and E.E.E.E
block in quick on $if inet proto protocol from ! {lista,listb } to
D.D.D.D,... port ...
instead of using:
pass in quick on $if inet proto protocol from {lista,listb } to
D.D.D.D ... port ...
block in quick on $if inet proto protocol from any to D.D.D.D ... port ...
Re: PF load balancing
There is documentation and a quick-and-dirty example in the PF User's Guide: http://openbsd.org/faq/pf/pools.html#outgoing On Tue, Aug 23, 2011 at 03:00:51AM -0700, elerdin wrote: Hallo, I have two internet connections and I want to use both with a round-robin load balancing, only for outgoing connections. I found on the web various solutions, but I did not manage to modify them for my scenario. One internet connections is a normal adsl, there is a modem that I connect to the OpenBSD router, the interface receives the dynamic IP using dhcp. The other connection has a static IP address and gateway. Now I'm reading the PF documentation, but while I study I need a fast and dirty solution that just works. Can someone help me?
