Re: hfsc and pfr_detach_table errors
Wilbern Cobb wrote: I'm trying to get HFSC to work with a large amount of queues (about 700). For some reason all my queues disappear after some time, and I'm getting a bunch of pfr_detach_table: refcount = 0. errors. I'm not issuing any pfctl command when the error occurs. If you only get that problem with HSFC, then one possibility is that HFSC has a bug and is corrupting the kernel memory. I still wonder what calls pfr_detach_table Cedric
Re:
arun kumarn wrote: Hi While porting the code over Linux i got one problem just i want to know what actually struct pfi_kif is for pfi_kif contains the the information PF keeps about interfaces. That mean that for each interface that exist on your OS, (struct ifnet on BSD) there is a parallel structure pfi_kif. PF also allocates pfi_kif structures for interfaces that are defined in PF rules but don't exist (yet) on your OS. For example, assume you've one ethernet interface eth0 on linux. You will have one pfi_kif structure for eth0. But if you define pass in on eth1 from foobar, then PF will create a pfi_kif structure for eth1 even if there is no such interface on your box. eth1 could appear later if you plug some USB gear for example, in which case the above rule will immediately work without user intervention. Cedric
Re: benefits of 'set state-policy if-bound'
Jon Hart wrote: Greetings, I'm in the middle of deploying my largest and most complex OpenBSD+pf setup yet and I'm starting to question the way I've done things in the past. I've been using an if-bound state-policy for quite some time. My reasoning up to this point was that I believed: 1) if-bound provided a tighter ruleset. A packet would never come in on or go out on an interface unless I explicitly said so. 2) if-bound made debugging any problems much easier because of '1' and because pfctl -ss will show the interface, which is very helpful. Whether or not these are true or complete is open to debate... Because this particular deployment will have significantly more interfaces, rules, hosts and traffic flows, suddenly using if-bound seems like it might be overkill. if-bound will not be slower than floating, so I don't think it's overkill. What benefits, aside from the ones above, does an if-bound state-policy provide? What about the opposite? What benefits does a floating state policy provide? There is only two scenarios when you don't want to use if-bound, and want to use floating states: a) if your routing environment can change dynamically, and you've a state that should migrate from one interface to another. b) if you use asymetric routing. If any of these contitions is true, you should use floating states. Otherwise, I would use if-bound states. Cedric
Re: benefits of 'set state-policy if-bound'
Jon Hart wrote: Whether or not these are true or complete is open to debate... Because this particular deployment will have significantly more interfaces, rules, hosts and traffic flows, suddenly using if-bound seems like it might be overkill. if-bound will not be slower than floating, so I don't think it's overkill. Really? My thinking was that because state would be kept on all interfaces that the packet in question traverses, and each state entry requires memory and system resources, that more resources would be required. I'd be surprised if this meant 2x the memory. Ok, yeah, that's correct, it will use more memory if you've more states. I usually filter statefully only on external interfaces, so for my config it doesn't make any difference, but it can for you if you filter everywhere. Note that with if-state, you will have more states, but each states will be stored on a tree attached to each interface. That mean that when PF receive a packet, it will only search the subset of states for the given interface (for if-bound state) so the search itself would be faster than for the floating case, if there was no cache effect Cedric
Re: Dup-to
Bob DeBolt wrote: Here is the simplest form of what I now have. int_if = rl1 ext_if = rl0 log_if = fxp0 pass in on $ext_if dup-to $log_if all pass out on $ext_if dup-to $log_if all I've not used dup-to for a while, but you should try to add the address of your log host, to allow PF to know the MAC addres of your log host, for example. pass in on $ext_if dup-to ($log_if 10.1.1.10) all Cedric
Re: rdr states not if-bound?
Nino Dehne wrote:
Repeated setup:
/ vlan1 \/ vlan2 - lan1
wan - router - - fxp0 bridge fxp1 -
\ vlan3 /\ vlan4 - lan2
I have a pass quick on { vlan1, vlan3, vlan4 } all and a relevant
What happends if you add keep state to the above rule?
Cedric
Re: anchors and tables and tags oh my.
steve h wrote: - i create a table foo in the main ruleset and stick 10.0.0.0/24 in it. i pass in from foo in an anchored ruleset. the rule does not match. shouldn't tables in a 'parent' anchor ruleset be global? Yes. That's likely a bug. Please make a testcase. there are some tables i use everywhere. if i create the table in a bunch of anchor rulesets, it whines about namespace (so i have to rename it each time...?) It should whines only if the table is both in a parent and child ruleset (like /table and /ruleset/table) It should not whines if it is in two unrelated subrulesets (like /ruleset1/table and /ruleset2/table) If that's not the behaviour you see, then there is a bug. Cedric
Re: handling nonexisting table/queue names
Ilya A. Kovalenko wrote: Greetings, pfctl(8) silently ignores nonexisting table and queue names. I suppose, it is some kind of feature (like dynamic creation, or so), Yes, that's a feature: the table can be created later by some daemon like spamd. but such silent handling complicates debugging typos on ruleset. Can pfctl(8), at least, display warnings ? If you do a pfctl -vvsr pfctl will show you the number of IP addresses in each table, so you can easily spot empty table: pfctl -vvsr | grep ':0' Cedric
Re: performance: single ip in table Vs single ip
Mike Frantzen wrote:
Simple question which rule is evaluated faster.
table ip0-2 const {192.168.0.2}
pass in quick on $int_if from ip0-2 to any
pass in quick on $int_if from 192.168.0.2 to any
Daniel did some tests several years ago and the break even point was
about six IPs in a table versus six individual rules. So your table
rule will be 6x as slow.
To be more accurate, a rule with a 6-entry table takes the same time
than 6 simple rules which differ only by their from or to addresses.
A table with only _1_ entry in it will be slower than a simple rule,
but less than 6x as slow.
Cedric
Re: ranges within a table ... is it possible ?
alex wilkinson wrote:
Hi all,
Is it possible to specify a range within a table ? e.g.
No, table do not currently support ports.
table itunes const { 8000 8999 }
I get a syntax error for the aformentioned table, so can anyone
suggest a method for what I'm trying to achieve ?
You need to use macros.
Cedric
Re: Pfctl for non-root users
Peter N. M. Hansteen wrote: Jason Dixon [EMAIL PROTECTED] writes: Is the ability to run pfctl (via sudo) as a non-root user still broken? I've tested this on a 3.6 -release system, and /dev/pf is still unavailable for non-root users. [EMAIL PROTECTED]:~$ ls -l /dev/pf crw--- 1 root wheel 73, 0 Oct 19 00:02 /dev/pf It certainly looks like being a member of wheel is a distinct advantage, at least. if you do chmod g+rw /dev/pf maybe Cedric
Re: Dropping fragmented ICMP echo-reply packets sourced from Solaris?
Kevin wrote: On Apr 1, 2005 2:06 AM, Cedric Berger wrote: Kevin Kadow wrote: I've noticed frag'd ICMP echo-replies being dropped by scrub in when they come from a Solaris host. Is this a known issue? Oh Yeah, That's a long time annoyance of the scrub code, which (wrongly IMO, but others disagree) drops fragments which have the DF bit set. You'll get the same problem with fragmented UDP packets from Solaris and Linux (typical with NFS) Cedric That makes sense. Changing the pf.conf entry to read scrub in no-df makes the problem go away. Yes, but read pf.conf man page. If you don't also set random-id, you might find yourself in big trouble with some packets. I mostly gave up on scrub because of that mess. Cedric
Re: Dropping fragmented ICMP echo-reply packets sourced from Solaris?
Kevin wrote: I've noticed frag'd ICMP echo-replies being dropped by scrub in when they come from a Solaris host. Is this a known issue? Oh Yeah, That's a long time annoyance of the scrub code, which (wrongly IMO, but others disagree) drops fragments which have the DF bit set. You'll get the same problem with fragmented UDP packets from Solaris and Linux (typical with NFS) Cedric On a related note, is there any way to log packets dropped by scrub? Doing 'ping -s 1473 target', if the target is a Cisco router or a BSD machine, the reply packets are accepted and ping shows success, but the exact same ping command transmitting to Solaris 9/Sparc will fail; tcpdump shows the packets being received by OpenBSD My pf.conf includes a scrub in command. Replacing the line with a explicit scrub command of either scrub in all fragment reassemble or scrub in all fragment crop does not change the behavior. If I comment out the pf.conf line scrub in, then *ALL* fragmented ping replies fail and the frags logged by pflog as dropped packets; with scrub enabled, only the replies coming from a Solaris machine are dropped. This does not appear to be an out-of-order frag problem (see tcpdump info below). If I run sudo ping -c 2 -s 1473 target-solaris, the ping fails: PING target-solaris (172.25.151.72): 1473 data bytes --- 172.25.151.72 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss And during that time, tcpdump - -s 1518 icmp shows this: 1112315188.969521 172.25.109.31 172.25.151.72: icmp: echo request (frag 41696:[EMAIL PROTECTED]) 0.04 172.25.109.31 172.25.151.72: (frag 41696:[EMAIL PROTECTED]) 0.001356 172.25.151.72 172.25.109.31: icmp: echo reply (frag 57180:[EMAIL PROTECTED]) (DF) 0.04 172.25.151.72 172.25.109.31: (frag 57180:[EMAIL PROTECTED]) (DF) 0.10 172.25.109.31 172.25.151.72: icmp: echo request (frag 47724:[EMAIL PROTECTED]) 0.04 172.25.109.31 172.25.151.72: (frag 47724:[EMAIL PROTECTED]) 0.001241 172.25.151.72 172.25.109.31: icmp: echo reply (frag 57181:[EMAIL PROTECTED]) (DF) 0.03 172.25.151.72 172.25.109.31: (frag 57181:[EMAIL PROTECTED]) (DF) ### # pf.conf # int_if=em0 TCPState=flags S/SA keep state table TRUSTED persist scrub in block in block in log on $int_if pass out keep state pass out quick on $int_if inet proto tcp from any to any $TCPState pass in quick on lo antispoof quick for lo pass in quick on $int_if proto tcp from TRUSTED to any port ssh $TCPState pass in quick on $int_if proto tcp from any to any port www $TCPState pass in quick inet proto icmp from any to any icmp-type echoreq keep state ###EOF### Thanks, Kevin Kadow
Re: Anchors with tables
Jason Dixon wrote: Looking at pf.conf (5), it claims that anchors can hold rules, address tables, and other anchors. Do you have the possibility to check if that was working on 3.5? I wouldn't be surprised if there was new bugs in that area in 3.6. Cedric
Re: can you help me measuring traffic using OpenBSD's pf?
Sean Kamath wrote: [In a message on Tue, 22 Mar 2005 22:52:58 +0100, Steven Schubiger wrote:] On 22 Mar, Eugene M. Minkovskii wrote: I want to meashure incoming traffic and outgoing traffic separately, regardless of which side initiated the traffic. # Excerpt from pf.conf, Options set loginterface Enable collection of packet and byte count statistics for the given interface. These statistics can be viewed using # pfctl -s info Huh. Didn't know about that. Any idea about the amount of overhead it would incur? set loginterface incur no overhead, because statistics are gathered for all interfaces anyway all the time, with or without that knob. Actually, you don't even need set loginterface. You can grab all interface stats using pfctl -vvsI or pfctl -i interface -vvsI. Read pfctl manpage. Cedric
Re: link failover
guilgamesh70 wrote: Hi group, I have this situation + + +--- IPSec link Internal network + Obsd Box+ + +--- Private link + where I would like to failover the private link over the ipsec link. I get confused with routing. Should I use cron to test next hops availability + dynamic pf changes or ospf (two ends will be openbsd boxes) Any suggestion would be highly appreciated. Thhanks in advance. Does the Obsd Box handle the IPSec VPN itself or is it a separate box? Cedric
Re: link failover
guilgamesh70 wrote: Cedric Berger wrote: guilgamesh70 wrote: Hi group, I have this situation + + +--- IPSec link Internal network + Obsd Box+ + +--- Private link + where I would like to failover the private link over the ipsec link. I get confused with routing. Should I use cron to test next hops availability + dynamic pf changes or ospf (two ends will be openbsd boxes) Any suggestion would be highly appreciated. Thhanks in advance. Does the Obsd Box handle the IPSec VPN itself or is it a separate box? Cedric Yes the obsd will handle the ipsec vpn. That's why I have some trouble at the routing level Yep, I can understand the problem now. I don't know ospf, but I strongly doubt it will handle that case. So you're left with a cron job I guess. IPSEC comes before routing, so if you add/remove the flows with your script (and ipsecadm), this will work without touching PF. Personally, I think this is such a pain that I would try to get two boxes to split the VPN and failover capabilities. Maybe someone else has a better idea? Cedric
Re: pf with many interfaces?
Adam Morley wrote:
table internal_subnets { 10.1.1.0/24, 10.1.2.0/24, 10.1.0.0/24 }
.. tables for rfc1918, classD, classE, etc.
table outsideworld { *, !internal_subnets, !rfc1918, !classD, !classE
} (can I use * or should it be 0.0.0.0/0?)
It should be 0/0, and you cannot have tables containing tables.
rfc1918 and friends should be macros like $rfc1928.
table notoutside { internal_subnets, rfc1918, classD, classE }
You don't need 2 tables with just the opposite content:
antispoof quick for em0
antispoof quick for em1
antispoof quick for em2
block in quick on em3 from notoutside
You could use: block in quick on em3 from !outsideworld
I'll leave the rest of your questions to more experimented PPL,
But basically I would try to put strict rules on interface(s)
connected to the internet, and you can be more loose on internal
interfaces, depending on how much trust you've on your users. :)
Cedric
Re: setting up vpn tunnel with nat - twisted
brianBOFH wrote: Hi, I have two 192.168.1.0/24 networks physically separated. I need to get connectivity from one to the other and vice versa _without_ renumbering hosts. That being said - I have an openbsd 3.6 machine with one public and one private interface on each end. I know I can setup the tunnel between the two. But because I can't bridge and route between the same network, my question is setting up NAT between them. Obviously the SRC and DST needs to be rewritten on either side which means your typical NAT setup will not work. Can this be achieved with pf? If anyone can point me in the right direction I would appreciate it. This is possible, but very tricky. You can create a transport-mode IPSec flow between the public IP of your 2 gateways, and then do nat on enc0 and maybe rdr on enc0. There is a chicken and eggs problem between the routing table lookup and IPSec lookup. Read (man ipsec) about NAT and *enc#* interfaces. You will have to setup a dummy flow from 192.168.1.0/24 to convince the kernel to ipsec-process your packet. Plan a good week of trial-and-error to make that work. Cedric
Re: NAT *before* routing decision
Chris Wilson wrote: Hi all, Trying to get my head around mixing NAT and IPSEC on OpenBSD; hoping you folks can tell me whether I'm crazy :-) I'm doing that, but with a somewhat older version of OpenBSD. So I guess that makes us both crazy :) I've got IPSEC ala: 10.1.1.1/32 10.1.1.1 10.2.2.2 10.2.2.2/32 (ie the encryption domain and the vpn endpoints are the same). Now I'd like the OpenBSD machine at 10.1.1.1 to be able to be able to give users on it's local LAN access to 10.2.2.2 through the IPSEC tunnel, NAT'ing the source address to 10.1.1.1 The problem is that because nat is performed after the routing decision is made packets are sent out of sk0 rather than enc0. The IPSEC implementation is presumably deciding that a packet from Local-LAN to 10.2.2.2 doesn't match the IPSEC SA and is therefore routing the packet normally, not via the tunnel. Only once the nat rule has been applied (on a non-encrypted interface) does the packet match the IPSEC SA. Is what I'm trying to do possible? Your analysis of the problem is 100% correct. So what you need is to convince the kernel that it should route the traffic using IPSec (to enc0), and then perform the NAT on enc0. I cannot give you the exact command, but basically you've to add a dummy flow (use ipsecadm, pointing to your existing spi) that will match your packets before NAT. The flow should look like: LAN/24 - 10.2.2.2. The processing on the kernel will look like that: - packet arrives on 10.1.1.1 from LAN.something. - packet match your dummy flow, so IPSec route it through enc0. - when hitting enc0, packet is NATTED. - natted packet is send to 10.1.1.1 using real real flow/spi. You need to play a little bit to get dummy flow right, but as I said, It's possible at least with a slightly outdated version of openbsd. Is there any way to force pf to do source-address-NAT as a packet enters the system rather than as it leaves? Not without hacking-up PF. Cedric
Re: using the ! (not) modifier
Bjrn Ketelaars wrote: Hello, Im trying to setup a natting firewall in which the internal network (int_if:network) *only* has access to the internet and udp-port 53 (domain) on the firewall. When Im using pf.conf given beneath it is possible to access all servers on the firewall... If I track a package (say tcp port 22 to $int_if) on the inbound network I will get the following: 1.) block log all default block policy 2.) pass in on $int_if proto udp from $int_if:network to $int_if port $int_udp keep state package is not accepted on $int_if because of tcp-port 22 3.) pass in on $int_if from $int_if:network to !$int_if:network keep state package is still not accepted because of !$int_if:network (=any except the internal network). Unfortunately, in the real world this does not work and the package reaches its destination. Any suggestion? here is two as a start: 1) to !$int_if:network will only work as you intend if there is only one IP address assigned to $int_if. If there is more, it will fail. please show the content of pfctl -sr. as a workaround, you can use !($int_if:network). 2) You want to prevent PPL in your internal network to connect to your firewall, but the rules that you show here won't prevent ppl to access the external IP address of your firewall ($ext_if). Cedric
Re: using the ! ('not') modifier
Björn Ketelaars wrote: here is two as a start: 1) to !$int_if:network will only work as you intend if there is only one IP address assigned to $int_if. If there is more, it will fail. please show the content of pfctl -sr. as a workaround, you can use !($int_if:network). 2) You want to prevent PPL in your internal network to connect to your firewall, but the rules that you show here won't prevent ppl to access the external IP address of your firewall ($ext_if). Cedric Hello, 1.) Wait a minuteso the not-modifier works only for a single ip-address (e.g. $int_if) and not for a range (e.g. $int_if:network)? This explains it! No, it should work with a range. but if you've assigned alias to the interface, there is two and more range, and then it will not work, look at the pfctl -sr output why. 2.) Indeed I want to prevent people in the the internal network to access the firewall, but I also want to make it possible to connect to the internet (by means of NAT) to connect to the internet. The following is better then: pass in on $int_if from $int_if:network to !(self) keep state Cedric
Re: Linux port of pf
Ed White wrote: On Tuesday 19 October 2004 22:08, Ed wrote: Has anyone ported pf for use on linux kernels? I like the firewall so much I want to use it on the debian systems. ..and maybe releasing it under GPL... You really like flames, don't you? Cedric
Re: CIDR notation - block spam 220.87.30.0/24
i.t Consulting wrote: Am Mittwoch, 6. Oktober 2004 21:21 schrieb Max Laier: the postfix mailserver tells me today: Oct 6 18:06:16 yak postfix/smtpd[27628]: NOQUEUE: reject: RCPT from unknown[220.87.30.15]: 450 Client host rejected: cannot find your hostname, [220.87.30.15]; from= to=[EMAIL PROTECTED] proto=SMTP helo=HGK do I have to go back to the cidr-basics ? Going back to valueable problem reports-basics might be a good idea ... I didn't expect postfix to get a spam message from 220.87.30.15 since pf should already block port 25: # pfctl -vvsr @16 block drop in log quick on rl0 proto tcp from bloecke.port25:* to any port = smtp [ Evaluations: 13Packets: 0 Bytes: 0 States: 0 ] The :* after bloecke.port25 means the table does not exist. Otherwise, the number after the : would tell you how many addresses are currently in it. Cedric
Re: pf error in OpenBSD help!
Siju George wrote: Hi all, When my OpenBSD 3.5 System tries to load the PF ruleset it shows the following error. /etc/pf.conf:22: could not parse host specification no IP address found for dc0:172.16.0.0/12 the 22nd line of my pf.conf is this. nat on $ext_if from $int_if:172.16.0.0/12 to any - $ext_if either (literally): nat on $ext_if from $int_if:network to any - $ext_if or: nat on $ext_if from 172.16.0.0/12 to any - $ext_if will work Cedric
Re: route-to problem; traffic remains on default link
Paul Cusbish wrote: --- Cedric Berger [EMAIL PROTECTED] wrote: Paul Cusbish wrote: [ All, a bit of a late followup, but i've included some rules this time. Thanks for your help ] Hi there, I have a common setup (seen it a few times on this list) - xl0 LAN fxp0 Cable / dynamic address fxp1 ADSL / static (DNS, SMTP, HTTP etc...) The default gateway is fxp0, of which is nat'd. The fxp1 link is, as specified above, the services link. I have some reply-to rules for SMTP, HTTP etc, to avoid asymmetric routing, which works great. I have BOTH links natting now. I do tend to use IRC and Mail from the gateway, and not from the internal network. How would the rules differ? Here are the route-to rules that do not work: nat on $cable_if from $internal_net to any - ($cable_if) (NOTE: This is the default route) nat on $adsl_if from $internal_net to any - ($adsl_if) pass out quick on $adsl_if route-to ($adsl_if $adsl_route) inet proto tcp from any to any port 25 modulate state Problem is that this rule cannot work. The default route is set on $cable_if, therefore the pass out quick on $ADSL_IF rule will never be kicks in. That is the classical chicken-and-egg problem. you need to do something like: pass out quick on $CABLE_IF route-to ($ADSL_IF... But then, your nat rules will also need adjustments. That's a PITA to get right, but that's doable. Have fun! Cedric - Hi Cedric, Thanks for your reponse. Regarding the nat rules, could you give me a pointer in the general direction of what needs to be adjusted please? Well, basically you just need to be more selective nat on $cable_if from $internal_net to any - ($cable_if) nat on $adsl_if from $internal_net to any - ($adsl_if) NAT occur before filtering, so you need to make sure packets don't get NATTed 2 times, and that they get NATTed to the right IP. so your NAT might look like: nat on $cable_if inet proto tcp from any to any port 25 - ($adsl_if) Now there is many different ways to do that, you could use tags as well. Cedric
Re: route-to problem; traffic remains on default link
Paul Cusbish wrote: [ All, a bit of a late followup, but i've included some rules this time. Thanks for your help ] Hi there, I have a common setup (seen it a few times on this list) - xl0 LAN fxp0 Cable / dynamic address fxp1 ADSL / static (DNS, SMTP, HTTP etc...) The default gateway is fxp0, of which is nat'd. The fxp1 link is, as specified above, the services link. I have some reply-to rules for SMTP, HTTP etc, to avoid asymmetric routing, which works great. I have BOTH links natting now. I do tend to use IRC and Mail from the gateway, and not from the internal network. How would the rules differ? Here are the route-to rules that do not work: nat on $cable_if from $internal_net to any - ($cable_if) (NOTE: This is the default route) nat on $adsl_if from $internal_net to any - ($adsl_if) pass out quick on $adsl_if route-to ($adsl_if $adsl_route) inet proto tcp from any to any port 25 modulate state Problem is that this rule cannot work. The default route is set on $cable_if, therefore the pass out quick on $ADSL_IF rule will never be kicks in. That is the classical chicken-and-egg problem. you need to do something like: pass out quick on $CABLE_IF route-to ($ADSL_IF... But then, your nat rules will also need adjustments. That's a PITA to get right, but that's doable. Have fun! Cedric
Re: PF tables states
Ed White wrote: This is a message from an interesting thread on [EMAIL PROTECTED] http://marc.theaimsgroup.com/?l=openbsd-miscm=109422765506037w=2 In short the question is: why doesn't PF kill all the states associated with the tables entries when you flush a table ? Why? Because states have always survived rules. You can remove all your rules, your states will stay there. That is what ppl expect, and there is no reason to change that default behaviour. But since tables statistics already record the fact that a state exist for an address that is no longer there (XPASS) optionally blocking such packets or removing the state could be done easily. don't know if that's a good idea. Cedric
Re: is amd64 a good choice ?
Alain wrote: Hello, We're working on an openbsd/pf based GigE firewall. I would like to know if amd64 is a good architecture choice ? Will it be better than i386 ? In the pf developer interview, 64 bit architecture is recommended, but they don't really explain why. One of the limitation of i386 is that you cannot use more than 768M or address space for kernel memory. That limits the number of states or table entries that can be put in there. Hopefully 64-bit kernels can access more virtual memory, but I don't have enough knowledge of VM code to give you hard numbers. Cedric
3.5 + Aliased Interface as Source IP
Okan Demirmen wrote: On Fri 2004.07.23 at 23:33 +0200, Daniel Hartmeier wrote: On Fri, Jul 23, 2004 at 03:24:25PM -0500, eric wrote: So, I know there's a way to tell pf to route traffic from a source-ip, I just forgot how and can't find it in the manpages. Also, is a way to make traffic from 172.16.43.54 appear as though it's coming from 10.9.9.3, and the other machines behind gateway appear as though they're coming from 10.9.9.2? Instead of nat on $ext_if from $int_net to any - ($ext_if) try nat on $ext_if from 172.16.43.54 to any - 10.9.9.3 nat on $ext_if from $int_net to any - 10.9.9.2 The form ($ext_if) is useful when you get a single address assigned to $ext_if dynamically (and it changes automatically). If you have aliases and want specific addresses used like this, don't use (if). correct me if i'm wrong, but can't you also do: nat on $ext_if from 172.16.43.54 to any - 10.9.9.3 nat on $ext_if from $int_net to any - ($ext_if:0) Sure. To make things clear, with 3.5: home# echo nat on sis0 - (sis0) | pfctl -nvf- nat on sis0 all - (sis0) round-robin See the round-robin keyword added? That mean if there is more than one address assigned to sis0, PF will round-robin through available addresses for each new outgoing connection. Consider adding source-track in that case. On the other end, adding :0 tells PF we're interrested in the main address only, and PF won't add the round-robin keyword in that case: home# echo nat on sis0 - (sis0:0) | pfctl -nvf- nat on sis0 all - (sis0:0) This is faster too, so PPL upgrading to 3.5 should look at their ruleset and think if they need to add that :0 or not. Pre-3.5, (if) would only take the first address in any case. Cedric
Re: filtering on enc
Tamas TEVESZ wrote: hi, i think i'm missing something on filtering on the enc interface. scenario looks as: leftsecgwAright [internal lan] -- [xl0 tun0] -- ~~ -- [secgwB] -- [other lan] secgwA is a 3.5-stable built on jun 15 (ie. it doesn't have the pf fix that went in the tree on jul 16). on the right lan there is an mssql server on 10.80.99.10, and on the left lan there's a client on 192.168.63.4 that needs to access said server. all that needs to be passing through the tunnel is this single connection. secgwB is probably some nortel contivity thing (i wasn't told exactly what it is, but from mail bits i suppose so). secgwA handles only this one ipsec tunnel. a.b.c.142 is the address of secgwA's tun0 interface, d.e.f.2 is the address of secgwB's internet-facing interface. i'm trying to set up filtering on enc0 so that only the above-specified connection may get through, but i'm seeing phenomena i don't really understand (and thus, i'm probably naming several things inappropriately, for i lack a better/proper name for them. i'm trying to be as clear as i can, though, please bear with me). in its simplest form, my pf.conf looks like this: = scrub in all fragment reassemble scrub out all fragment reassemble pass quick on lo pass quick on xl0 pass quick on tun0 block log on enc0 pass out log on enc0 proto tcp from 192.168.63.4 to 10.80.99.10 port = 1433 flags S/SA keep state Add pass in on enc0 proto ipencap all all and it should work. That's an old problem with OpenBSD IPSec code. Cedric
Re: Inet on table
Ilya A. Kovalenko wrote:
Good time of day,
I want to define table, that includes all Internet IP
addresses (i.e. all except fake ones).
Excludes-only table does not work.
table nInet {!192.168.0.0/16 !172.16.0.0/12 !10.0.0.0/8}
How can I add all IP addresses onto table ?
any causes error
0/0 does not work (as said on FAQ)
construction 0/1 128/1 seems to work
How I should do it ?
0/1 128/1 will work, yes.
But the real question I've is why do you need that.
You can just do the opposite table:
table x { 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8}
And then use the table in negative rules, like:
pass in from !x
Cedric
Re: Inet on table
Ilya A. Kovalenko wrote:
Good time of day,
I want to define table, that includes all Internet IP
addresses (i.e. all except fake ones).
Excludes-only table does not work.
table nInet {!192.168.0.0/16 !172.16.0.0/12 !10.0.0.0/8}
How can I add all IP addresses onto table ?
any causes error
0/0 does not work (as said on FAQ)
Actually, this is a bug that turns out to be very easy to fix.
Apply the following diff by hand (with vi, not patch)
Then 0/0 should work. That should also fixes some IPv6
badness...
Cedric
lapbsd# svn diff pf_table.c
Index: pf_table.c
===
--- pf_table.c (revision 167)
+++ pf_table.c (working copy)
@@ -880,14 +880,14 @@
if (af == AF_INET) {
sa-sin.sin_len = sizeof(sa-sin);
sa-sin.sin_family = AF_INET;
- sa-sin.sin_addr.s_addr = htonl(-1 (32-net));
+ sa-sin.sin_addr.s_addr = net ? htonl(-1 (32-net)) : 0;
} else {
sa-sin6.sin6_len = sizeof(sa-sin6);
sa-sin6.sin6_family = AF_INET6;
for (i = 0; i 4; i++) {
if (net = 32) {
sa-sin6.sin6_addr.s6_addr32[i] =
- htonl(-1 (32-net));
+ net ? htonl(-1 (32-net)) : 0;
break;
}
sa-sin6.sin6_addr.s6_addr32[i] = 0x;
Re: PF $if:network syntax with more than one interface IP.
Per-Olov Sjöholm wrote: Hi ! I have used $if:network and $if:broadcast much to avoid specifying macros with IP addresses. However... I have recently fixed me a second public IP on my internet interface. Now I see the limitations with this and have to go back and specify the IP:s directly in pf.conf (for the Internet interface..) as I don't want both my public IP:s expanded in the ruleset. If I specify $if:network both addresses are expanded If you're using 3.5, you can do the following: $if:0:network or $if:0:broadcast It will also work for dynamic addresses, like: ($if:0:network) or ($if:0:broadcast) The question: Is is possible to fix the interface a'la Solaris where you can specify interfaces for example hme0:1, hme0:2 etc where you have a separate interface name for each IP on the same physical interface.. Then it would still be possible to use the syntax above that I really like. No Cedric
Re: Absent Interfaces Handling
Ed White wrote: Hi, I've read that since 3.5 PF can load rules for absent interfaces. After some tests I've found that sometimes it works and sometimes it doesn't. Can anyone tell me which interfaces are compatible ? with 3.5, PF look if the interface you're trying to load can be hot-plugged (pc-card, usb and such). example 2 worked because all the interfaces you tried exist in usb or pc-card versions. Cedric Ed Example 1: desktop with only rl0 .. pass in on rl0 all pass in on fxp0 all .. NOT loaded Example 2: laptop without interfaces .. pass in on rl0 all pass in on fxp0 all pass in on dc0 all pass in on an0 all pass in on wi0 all .. loaded OK Example 3: laptop without interfaces .. pass in on sis0 all .. NOT loaded
Re: carp + pfsync + sqlnet (Oracle)
[EMAIL PROTECTED] wrote: Does anybody protect any oracle rdbms (sqlnet protocol) using obsd 3.5 + carp + pfsync ? Does it work ? Is it problematic ? I think for database failover, you'd better use the DB own features. For example, a quick google grep gave me that: If you have multiple addresses, you can configure client load balancing and connect-time failover features, as in the following example. sales= (DESCRIPTION= (ADDRESS_LIST= (FAILOVER=on) (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
Re: pfctl -n fails when run by a non-root user.
JB Robertson wrote: hi gang, as i was playing with some ruleset, i noticed that i couldn't use pfctl -n as non-root user anymore when there is a nat rule in the ruleset. Yeah, that's a known little issue. We're looking for ways to solve that cleanly. Cedric
Re: tagging keep state
Henning Brauer wrote: * Ed White [EMAIL PROTECTED] [2004-06-01 13:32]: On Tuesday 01 June 2004 00:48, David Gwynne wrote: Theres always annoying edge cases. The only problem I've seen with this behaviour of tags is when you're trying to keep track of traceroutes through the box. Say you have the following rules The funny thing is that if you want to use tags to filter on multiple interfaces you have to keep state on each of them. That's the opposite of what FAQ suggests! ;-) what, the FAQ suggests to filter stateless if you have multiple interfaces? I have to talk to Joel ;) *IF* possible, you don't want to have multiple states for the same packet. Wastes RAM for little purpose. Cedric
Re: :peer
Ed White wrote: On Monday 31 May 2004 01:26, Henning Brauer wrote: block in quick on rl0 inet from (rl0) to any (Using pfctl not ifconfig) :peer applies to pointtopoint interfaces (like tun) where the remote address is known and configured. So if I'll use PPPoE on rl0 I'll have something like rl0 = 10.0.0.1 rl0:peer = tun0 = x.x.x.x (routable) no, tun0:peer will be the IP address of the remote side (ISP side). what is on the right side of the - if you run ifconfig tun0 Cedric
Re: tftp through pf problems
Cameron MacDonald wrote:
I guess the sensible question would be, can you tftp things through pf?
tftp does not work with keep-state and friends, because it answers from
a different port then the one used for the query. that's a PITA, but
there is
nothing PF can do. tftp itself need to be fixed, but I'm not sure it's
possible
to change that behaviour is tftp is started from inetd.
Cedric
I've
searched and read alot but nothing I've found specifically states that it
is, or is not possible.
The connection comes back from the tftp server to the correct port but is
then given a port unreachable message. I'm guessing this is because there's
nothing actually listening at that port?
Some help and pointers would be much appreciated.
Regards,
Cameron MacDonald
Following is the obligatory log and pf.conf
19:43:36.960604 my ip.1790 server ip.tftp: 53 RRQ
/firmware/leadtek/LR8051S/currentversion.txt
19:43:37.180840 server ip.47806 my ip.1790: udp 24 (DF)
19:43:37.181144 my ip server ip: icmp: my ip udp port 1790 unreachable
19:43:39.459591 my ip.1790 server ip.tftp: 53 RRQ
/firmware/leadtek/LR8051S/currentversion.txt
19:43:39.683193 server ip.47806 my ip.1790: udp 24 (DF)
19:43:39.683514 my ip server ip: icmp: my ip udp port 1790 unreachable
19:43:41.958761 my ip.1790 server ip.tftp: 53 RRQ
/firmware/leadtek/LR8051S/currentversion.txt
19:43:42.179459 server ip.47808 my ip.1790: udp 24 (DF)
19:43:42.179776 my ip server ip: icmp: my ip udp port 1790 unreachable
19:43:44.467850 my ip.1790 server ip.tftp: 6 ERROR EUNDEF
==
EXT= de0
INT= de1
PRIVNETS= { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
icmp_types = { 8, 11 }
set loginterface de0
set optimization conservative
# Scrub rules
scrub in all
# NAT and Redirection rules
nat on $EXT inet from $INT/24 to any - ($EXT)
# Redirections
rdr on $EXT proto tcp from any to any port 3389 - 192.168.42.101 port 3389
rdr on $INT proto tcp from any to any port ftp - 127.0.0.1 port 8021
# Filter Rules
block in log all
block out log all
pass in quick on lo0 all
pass out quick on lo0 all
# Pass traffic to/from internal network
pass in quick on $INT all keep state
pass out quick on $INT all keep state
pass in quick on tun0 all keep state
pass in quick on tun1 all keep state
block in log quick on $EXT from $PRIVNETS to any
block out log quick on $EXT from any to $PRIVNETS
# Let in ping from all interfaces
pass in inet proto icmp all icmp-type $icmp_types keep state
# Pass the stuff we expect on the external interface
pass in on $EXT inet proto tcp from any to any port { 22, 25, 3389, 1723 }
flags S/SAFR
pass in quick on $EXT inet proto udp from any to any keep state
pass in quick on $EXT inet proto 47 from any to any keep state
# Permit outgoing on $EXT
pass out on $EXT proto tcp all modulate state flags S/SA
pass out on $EXT proto { udp, icmp } all keep state
# Let the Bigpong heartbeat in
pass in quick on $EXT from 61.9.208.13 to any
pass in quick on $EXT from 61.9.128.137 to any
Re: Things pf can't do?
Dave Anderson wrote: I'm new to pf, so I'd appreciate a sanity-check. I've searched through the docs and the mailing list archives but not found anything that clarifies this. (I found one similar question, but it never got an answer.) There seem to be some things one might reasonably want to do which are not practical with pf; in particular, I (being paranoid) would like to drop any incoming packets which have the loopback address as their destination address -- but I also need to redirect some incoming packets to the loopback address (e.g., for spamd and ftp-proxy). Since only the translated addresses are available to the filter rules, the only way to do this appears to be to use the 'pass' option on the redirection rules -- but this means that all of the other sanity-checking I do in the filter rules must also be squeezed into each redirection rule (which not only is awkward but probably isn't possible, since they're most likely too complex to express that way). If my analysis is correct, are there any plans for dealing with issues of this sort? Look at tags. I'm pretty sure you can tag a packets when it hits the RDR rule, and then filter on that tag later instead of the loopback address. Cedric
Re: Max table size and Composite Blocking List - 3.4 stable
Attila Nagy wrote: Cedric Berger wrote: With that patch, you should be able to load up to something like 4'000'000 table entries on your i386 with 1G mem. Adding more than 1G memory will not help, since the kernel VM space is limited to 768Mb. Is it possible to overcome this problem with a 64 bit CPU, for example AMD64? Likely, yes. Cedric
Re: Max table size and Composite Blocking List - 3.4 stable
Greg McConkey wrote: [EMAIL PROTECTED] (Cedric Berger) wrote in message news:[EMAIL PROTECTED]... Greg McConkey wrote: Anyone getting the Composite Blocking List to load into a table in PF, the 1.4 million lines seems to be too much. PF seems to complain that there isn't enough memory when loading it manually, using: pfctl -t spamd -Tr -f spamd.cbl Box has 1Gb of ram and about 1Gb of swap on i386. Running spamd-setup it seems to load the 1.4 million lines into spamd but fails when it loads the spamd table into my pf ruleset. What is the max table size that pf can handle, has this changed in 3.5? Spam seems to be getting worse the past week and would like to be able to use the CBL instead of just spamhaus and spews. Ok, here it goes. If you want to put tons of IP addresses in your table, you need to apply the following patch: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_table.c.diff?r1=1.47r2=1.48 With that patch, you should be able to load up to something like 4'000'000 table entries on your i386 with 1G mem. Adding more than 1G memory will not help, since the kernel VM space is limited to 768Mb. With this patch, there is no need to tweak nkmempages or any other button. Please report success or failure! Cedric 3.4 stable won't compile by going from version 1.41 to 1.48 of pf_table.c. Is this available in 3.5-stable or do you have to be running current. Could this be made workable in 3.4 at all? Just apply the diff by hand. It's just replacing two NULLs by pool_allocator_nointr. I'm sure you can do that even if you don't speak C. Cedric
Re: Max table size and Composite Blocking List - 3.4 stable
Greg McConkey wrote: [EMAIL PROTECTED] (Cedric Berger) wrote in message news:[EMAIL PROTECTED]... Greg McConkey wrote: Anyone getting the Composite Blocking List to load into a table in PF, the 1.4 million lines seems to be too much. PF seems to complain that there isn't enough memory when loading it manually, using: pfctl -t spamd -Tr -f spamd.cbl Box has 1Gb of ram and about 1Gb of swap on i386. Running spamd-setup it seems to load the 1.4 million lines into spamd but fails when it loads the spamd table into my pf ruleset. What is the max table size that pf can handle, has this changed in 3.5? Spam seems to be getting worse the past week and would like to be able to use the CBL instead of just spamhaus and spews. Ok, here it goes. If you want to put tons of IP addresses in your table, you need to apply the following patch: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_table.c.diff?r1=1.47r2=1.48 With that patch, you should be able to load up to something like 4'000'000 table entries on your i386 with 1G mem. Adding more than 1G memory will not help, since the kernel VM space is limited to 768Mb. With this patch, there is no need to tweak nkmempages or any other button. Please report success or failure! Cedric Never mind my previous post about the compile error, made the changes to the pf_table.c file instead of replacing the whole file and it compiled just fine. And works too. Tested on a PII 400MHz with 384mb of ram. It stops passing traffic for about a minute (64 seconds or so) when loading the table, will have to see how the other box, 2.4GHz P4, handles it. Thanks for your help Cedric. Thanks for the report. When I get some time, I'm gonna look at ways to improve loading time. I've some ideas. Cedric
Re: error while trying to rebuild pf and pfctl
David Jobes wrote: I am getting this error, and after checking online, and searching thru the code and makefiles, i still have been able to get it to rebuild pfctl. cd /usr/src/sbin/pfctl/ # make yacc parse.y cc -O2 -Wall -Wmissing-prototypes -Wno-uninitialized -Wstrict-prototypes -I/usr/src/sbin/pfctl -c -o parse.o y.tab.c parse.y: In function `yyparse': parse.y:608: structure has no member named `prob' parse.y:1514: structure has no member named `prob' *** Error code 1 this is from the latest or a cvsup done today cp /sys/net/pfvar.h /usr/include/net Cedric
Re: Singleton tables versus macros
Gregory Wright wrote:
Hi,
I have a question of style and efficiency. If I use a table with a
single element, say
table multicast const { 224/8 }
Is it significant more expensive to in a rule than an explicit (or
macro expanded)
224/8?
Probably something like 5x-10x slower.
I understand the advantages of the table, especially as I begin to
make exceptions
for specific multicast addresses. But is there any reason to avoid
singleton tables?
Or any stylistic reason to favor them over macros?
I'm using singleton tables when:
1) I want to add/remove rules without reloading the ruleset
2) I want to benefit from the extra statistics available with table
entries.
I cannot see any other reason to use that.
I would assume that there would be some overhead when calling the radix
tree code to match the table entry. Is it small enough to be negligible?
Testing a table (with one or a few addresses) should be, as a guess,
5x-10x slower than just testing one address in a direct rule.
Now I would bet that unless you've a very high traffic FW or a very
slow machine, it will be negligible.
Cedric
Re: runtime rdr
Ed White wrote: Hi, someone asked me how to add a rdr rule on the fly. They are coding a well-known network manipulation utility and needed to apply the following redirection from the software itself. They used the following command with Linux: iptables -t nat -A PREROUTING -p tcp --destination-port 6969 -j REDIRECT --to-port 9090 What is the variable part in that dynamic rule? Port? IP Source? Cedric
Re: Per direction rule counters in PF
Michael O. Boev wrote:
Good time of the day, everybody!
Does anyone know, how to account per-direction traffic with PF?
Imagine I have a rule:
pass in on $int_if from $some_machine to any keep state label some-machine
When I invoke /sbin/pfctl -sl I get something like:
some-machine 5904 2510 130379
where 130371 (the last number) is the TOTAL traffic that was generated by
the named rule.
I wish I could know the amount of incoming traffic for that machine
separately from
the outgoing.
put $some_machine into a table.
table foo { $some_machine $another_one }
pass in on $int_if from foo to any keep state
then do:
pfctl -t ssh -vvTs
Cedric
Re: PF/spamd oddity
Jason Dixon wrote: # allow localhost pass on lo0 all keep state pass in log on lo0 inet proto tcp from spamd to 127.0.0.1 port 8025 # testing That should be pass in log on $ext_if ... Cedric
Re: Keeping a lot of states
No, i386 current pmap support is very poor, and won't allow you to reliably allocate more than 64M of RAM. You might be more lucky with sparc64 or amd64. Cedric Jon Mosco wrote: Yes. option NMBCLUSTERS=N , where N is the number of clusters. Read http://www.openbsd.org/faq/faq11.html#Network Jon On Tue, 16 Mar 2004 00:02:46 +0059 Jedi/Sector One [EMAIL PROTECTED] wrote: Hello. Is there any kernel parameter like NMBCLUSTERS or NKMEMPAGES to increase in order to let pf work with millions of states? The host has 1Gb ram and does nothing but transparent firewalling. TIA, -- __ /*-Frank DENIS (Jedi/Sector One) j at 42-Networks.Com-*\ __ \ '/a href=http://www.PureFTPd.Org/; Secure FTP Server /a\' / \/ a href=http://www.Jedi.Claranet.Fr/; Misc. free software /a \/
Re: pfctl: Cannot allocate memory
Greg Wooledge wrote: Cedric Berger ([EMAIL PROTECTED]) wrote: Here is the problem I think: 40MB of kernel memory for routing table entries... It might be PF table stuff..., not sure yet. Do you reload your ban table very often? Whenever I notice a new IP address that needs my attention. Unfortunately this can often be several times in an evening. Ok, I'm 99% convinced this has nothing to do with PF. At the time I sent my last e-mail, the box had been up approximately two weeks, so I figured I'd upgrade CVS before rebooting it. I did that, and now my 3.5-beta -current box has been up 22 hours. netstat -rn | wc shows 79 lines. Here's the top section (before the IPv6 stuff, which I don't use, as far as I know). === Internet: DestinationGatewayFlags Refs UseMtu Interface default209.142.155.254UGS 470 4603644 1492 tun0 12.169.2.37209.142.155.254UGHD0 4600038 1492 L tun0 24.57.88.139 209.142.155.254UGHD1 4603283 1492 L tun0 24.204.73.174 209.142.155.254UGHD0 4602201 1492 L tun0 62.34.2.173209.142.155.254UGHD1 4575857 1492 L tun0 62.49.7.13 209.142.155.254UGHD1 4586241 1492 L tun0 62.174.241.107 209.142.155.254UGHD1 4595161 1492 L tun0 62.234.101.184 209.142.155.254UGHD1 4594391 1492 L tun0 [...] If the routing table really does grow every time some spammer or P2P user connects to me from the Internet, and never gets pruned, then this resembles a denial of service attack. :-/ But I have a hard time believing I'd be the only person seeing such a problem. We're looking at the problem, but there is very likely a bug related to PMTU here. You can probably workaround the problem by turning PMTU off with sysctl: vm34c# grep mtu sysctl.conf #net.inet.ip.mtudisc=0 # 0=disable tcp mtu discovery I don't know if that is possible for you, though. Cedric
Re: pfctl: Cannot allocate memory
Greg Wooledge wrote: Cedric Berger ([EMAIL PROTECTED]) wrote: Now maybee you could succeed reloading your table with the command: pfctl -t ban -Tr -f /etc/ban, because this command is more optimized and will allocate less kernel memory. It will run faster too. Hope that helps, and let us know if you find something with vmstat -m output. If it is PF that leaks kernel memory, we need to fix that! Hi again, and thanks for responding earlier. Today is the first time I've seen the problem happen again. This is probably due to several reboots which have occurred since I originally reported the problem (some planned and some unplanned). Thanks for the report! During that time, I also updated to a snapshot, and then to 3.4-current by source. I'm currently running 3.4-current from Feb 23. pegasus:~$ sudo vi /etc/ban Password: pegasus:~$ sudo pfctl -t ban -Tr -f /etc/ban pfctl: Cannot allocate memory. Here's what vmstat -m says: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 1028 1431K 1431K 39322K 10910 0 16,32,64,128,256,512,1024,2048,4096,16384,32768,65536 pcb66 6K 7K 39322K158380 0 16,32,64,512 routetbl279631 39322K 39322K 39322K 11489260 0 16,32,64,128,256 Here is the problem I think: 40MB of kernel memory for routing table entries... It might be PF table stuff..., not sure yet. Do you reload your ban table very often? Do you you have a big routing table, or IPSec table? Cedric
Re: Network with PPTP and interfaces statistics ?
Vladimir Potapov wrote: 2)I want to accounting traffic which goes via PF network interfaces.Can I use for this pf options setloginterface with 2 or 3 arguments ( if1 if2 ) ? If I cannot use it, which tool I need to traffic accounting on all interfaces ? Upgrade to -current, use pfctl -vvsI, and forget about that loginterface knob. Cedric
Re: Something like pfstat for multiple interfaces
jared r r spiegel wrote: On Fri, Feb 20, 2004 at 11:46:25PM +0100, Cedric Berger wrote: Brent Bolin wrote: Hello, Does anybody know of a way to capture statistics on multiple interfaces running pf Aha! Up to recently, that was impossible to grab stats on more than one interface with PF. You can now do it now using -CURRENT by doing pfctl -i fxp0 -vvsI for example. so i had an idea which seems to be negated by that, but fwiw, what about: # sed 's/set loginterface.*/set loginterface new_interface/' \ /etc/pf.conf | pfctl -Of- where new_interface could be either a macro set earlier in a script / commandline. the -O would only load in the options. i don't know if my example above only works by virtue of me having a -current past Wed Dec 31 11:18:25 2003 UTC; which has pfvar.h 1.180 which seems to be where DIOCIGETIFACES was introduced. Yes, exactly. Before that commit, PF would only record stats for one interface. Your trick will not work on plain 3.4 version for example. Cedric
Re: How to put more IPs in tables in PF?
Bohdan Tashchuk wrote: Who knows if they're on the level or not. But at the risk of helping some nuts, there's a really simple technique that can be used to put a table of *ANY* number of IPV4 IPs into this guy's machine. Since he's from Hong Kong it might not help, since he might need IPV6, but here goes anyway. As someone else recently said: USE THE SOURCE Yes :) There are 4,294,967,296 theoretically possible IPV4 addresses. Since allocation can't go past 223.255.255.255, there are only 87% of that number that can exist. Allocating 1 bit per IP address, a yes/no lookup table can be created in 448 MB of RAM. And that's all that's needed: 1) a program that creates a 448 MB lookup table, 1 bit per IP 2) modification to pf source to do a table lookup into that table to get a yes/no answer. The lookup then becomes a a trivial operation to code, and runs in constant time (i.e. extremely fast). I'm also assuming that a single bit of information per IP is all the poster needs, e.g. to make a yes/no decision on whether or not to blacklist an IP. Yes, unfortuantely, there is a little flaw in your (otherwise good) thinking. Each IP addresses takes 152 bytes on i386 (including stats and everything). Therefore 1'500'000 address will takes something like 256 Megs of RAM. If Kent is not able to allocate 256 Megs of kernel memory for his table, I don't think allocating 448 Megs will succeed. Something else that could be done with the source is to remove table entry statistics, which will probably boost the number of entries that can be put in a table by a significant margin. Cedric
Re: pf default rule question..
Microsoft Security Center wrote: Was wondering if anybody know if it is possible to add some Default rules to the kernel or something when compiling.. Well, remember that it's OpenBSD, so you've the source code. You can probably do what you're asking for by adding 5 lines of code in net/pf.c inside case IPPROTO_TCP in pf_test(). If you want to pay someone to do that for you, you can always mail me privately :) Cedric
Re: pfctl: Cannot allocate memory
Hi Greg,
Thanks for the very detailled report!
# pfctl -T load -f /etc/pf.conf
pfctl: Cannot allocate memory
[...]
17006 pfctlCALL ioctl(0x3,_IOWR('D',0x4d,0x44),0xcfbfb630)
17006 pfctlRET ioctl -1 errno 12 Cannot allocate memory
[...]
Some of you are going to think that I should be running GENERIC, and I'd
love to, if it'd kindly stop crashing with map entry errors. Here's
the diff between GENERIC and BUSY:
===
# diff GENERIC BUSY
33a34,36
# Greg's changes, stabbing blindly in the dark
optionMAX_KMAPENT=2000
You're getting an error from pfctl because PF kernel code
cannot allocate memory to reload your address list.
When reloading an address list from pf.conf, it temporarily
use 2x the kernel memory required to store the table entries
(i.e. during the time pfctl does his job, both the old and new
tables use kernel memory)
But the real problem is that you reach some limits in your
kernel, very likely the same that makes your system crash
with the default MAX_KMAPENT. The real solution is
to find what is eating all theses kernel resources.
vmstat -m output would help.
Now maybee you could succeed reloading your table with
the command: pfctl -t ban -Tr -f /etc/ban, because this
command is more optimized and will allocate less kernel
memory. It will run faster too.
Hope that helps, and let us know if you find something with
vmstat -m output. If it is PF that leaks kernel memory, we
need to fix that!
Cedric
Re: interface improvements - help needed!
Henning Brauer wrote: On Tue, Jan 06, 2004 at 10:05:58AM +0100, Cedric Berger wrote: Henning Brauer wrote: that is in practice true for 99% of you. the state key does not include the interface, but the direction. as long as routes do not change that is equivalent to beeing bound to the interface. Yes, for normal (i.e. not spoofed) packets. og cedric, please stop that, this is horribly misleading. you don't get your packet in on the wrong interface until you match the state, and that requires a _lot_ of information (match the sequence number window, for example), taht makes it close to impossible. Not all the word is TCP. I took IKE as an example, since it: - Uses UDP (therefore no sequence number) - Use highly predictable source/destination ports (500/500). And the other protocols that can be passed keep state do not even have a port... it's certainly neat that we can bind states to interfaces now, but it is not as if the previous behaviour is a problem. I said it will protect *a bit* better against spoofed packets. Not: what was before was utterly wrong Cedric
Re: interface improvements - help needed!
Alexey E. Suslikov wrote: i can't find the discussion with daniel, where he pointed out: this is the pf.conf manual page issue in saying: here is the daniel's message http://www.benzedrine.cx/pf/msg02982.html Quoting from that message: But it's not entirely true, either, as state entries are not really bound to an interface (only to the direction). Not yet, at least, as it would have some advantages making it worth changing. Yet has come. Now you can bind them if you wish. Cedric
Re: newbie help - how 'bout ending that useless thread?
Re: Link-local addresses
Wouter Coene wrote: There is many little improvement possible, like warning if someone write fxp0:routable:local for example, or similar invalid combination, but let's see what other people say there. Why should you? That would mean you could write: if=fxp0:routable pass in from any to $if:local . and have it do exactly what you expected. What I would expect in such a case is a nice error message. Cedric
Re: Link-local addresses
Wouter Coene wrote:
Wouter Coene wrote:
Perhaps another suffix along the lines of
':network' and ':broadcast' that omits non-routable addresses
(':routable', ':network-routable')?
Attached is a patch that implements this. So now you can write:
pass in on gif0 from any to gif0:routable
and have it expand to only:
pass in on gif0 from any to 2001::x
assuming gif0 has 2001::x and a link-local address.
It allows calls to ifa_lookup() to specify a scope
(PFCTL_IFLOOKUP_ANY, _LOCAL or _ROUTABLE), and host_if() simply
translates the appropriate interface suffixes to a scope value.
ifa_lookup() does the scope check using the IN6_IS_ADDR_LINKLOCAL()
macro from netinet6/in6.h. It would probably be a bit cleaner to
check the scope id itself but since those scope values seem to be
internal-use only and since the macro is also used in other parts of
pfctl, I thought it best to use IN6_IS_ADDR_LINKLOCAL() for this.
I've also made a patch for the pf.conf manpage (see second
attachment), in which the behaviour is documented as follows:
:localTranslates to the interface's addresses that are not
routable, eg. IPv6 link-local addresses.
:network-local
Same as above, but the addresses of the network(s)
attached to the interface.
:routable Translates to the interface's addresses that are
routable.
:network-routable
Same as above, but the addresses of the network(s)
attached to the interface.
Both patches are against OpenBSD 3.4.
I like theses patch, with one little exception.
You define in the code a new concept scope
in addition to mode. I think this is very good.
But then, I don't like the:
- network-local
- network-routable
combinations. And if we expand either the scope
or mode, this will lead to a quadratic expansion
of theses combination. I would much prefer having
to specify gif0:network:local, and then you could
replace the
if ((p = strrchr(s, ':')) != NULL
in the code by something like
while ((p = strrchr(s, ':')) != NULL
and not have to define theses X-Y
combinations. I will simplify the code and
make it more future proof.
Other than that little detail, I like it a lot.
Cedric
Re: state limits
Octavian Hornoiu wrote: Is there a feature currently in pf that allows one to limit how many states one IP or group or macro or interface can use up? For example, i want my clients that i am natting out to be limited to 1000 states per machine so if they get a virus they won't be able to fill up my state tables with bogus pings or attacks on other machines on the internet. Ryan McBride has written something like that... It'll be in 3.5 I hope! Cedric
Re: DIOCCOMMITRULES ioctl(2) and File Descriptors
Jonathan S. Keim wrote: Hello, I found the problem - a thread was erroneously closing fd 0, which happened to be the /dev/pf file descriptor. fd 0 was subsequently being assigned to various sockets. This would explain why ioctl(2) was returning errno values that don't come from the PF ioctl(2)s. :) Thanks for the brisk response, though. On a somewhat-related note, are DIOCCOMMITRULES etc. going to be included in 3.4 but deprecated in -current? Yes. My unreliable CVS tree spider sense tells me 3.4 (and 3.4-stable) will not be receiving the DIOCXCOMMIT and related ioctl(2) semantics. Correct. Cedric
Re: deep packet inspection
[EMAIL PROTECTED] wrote:
Hi,
At the university i am working on a project where i have to implement deep
packet inspection(payload inspection) with some firewall(i picked OpenBSD's
pf), currently i am thinking about design and implementation of that. One of
the most obvious options is to rdr packets to user-land proxy (just like ftp-
proxy)
Yes.
however i'd like to implement that in kernel-land.
You will be flamed, be warned.
So the question is:
What are possible ways of implementing payload inspection in kernel? How is it
possible to pass data from kernel-space to user-space(with kernel being
initiator of that transfer)?
There is many way.
You can use socket like the routing socket.
You can have the userland be the initiator,
and wait for data in the kernel:
for(;;) { get_kernel_data() }
Another question is where i can get some documentation on mbuf's, etc ?
man mbuf
Cedric
Re: deep packet inspection
Daniel Carneiro wrote: I was wandering if I can make a userland program to read the packets from kernel land using ioctl insted of rdr? man tun man bpf
Re: deep packet inspection
Ed White wrote: On Tuesday 30 September 2003 06:23, [EMAIL PROTECTED] wrote: What are possible ways of implementing payload inspection in kernel? How is it possible to pass data from kernel-space to user-space(with kernel being initiator of that transfer)? This is pretty funny, I'm writing something like that... However I'm using an atypical way as usual ;-P And what's the point of writing that e-mail if you don't describe your atypical way? Cedric
Re: pfr_update_stats: assertion failed
Daniel Cox wrote: I have a router running OpenBSD 3.3 RELEASE. - it uses a negated statement: block in from !foo Hmmm, weird :( Ok, for a quick fix, you could just replace the line: printf(pfr_update_stats: assertion failed.\n); inside /sys/net/pf_table.c by: return; But if you can reproduce the problem reliably (i.e. you know which packet generate that assertion), and have some time to spare, please contact me privately (with complete pf.conf + crash recipe) and I'll try to get to the bottom of this one. Thanks, Cedric
Re: syn-proxy application-level-proxy
Can Erkin Acar wrote: I have been dreaming of passing assambled streams through the userland. I have not yet come up with a suitable design though. I've been probably dreaming too, but I would love to have some kind of scrub tcp that would reassemble the stream, before forwarding it. That would allow me to easily bypass the PMTU problems for example, without having to tweak all clients (Win2000 friends will send 1500 byte segments, the gateway will reassemble them, and regenerate 1300 bytes segments to the destination transparently, wow) Is that a crazy idea? Cedric
Re: syn-proxy application-level-proxy
Daniel Hartmeier wrote: On Thu, Sep 11, 2003 at 04:49:27PM +0200, Cedric Berger wrote: 3) somehow, a NAT rule is created to make that 2nd connection originate from the same socket as the first connection/packet. *cough* embryonic state *cough* Googling... Ok, I see.. All you need is to insert a state entry that will be completed to a normal state when the first packet goes out (and defines the priorly unknown, random source port). The translation can be done by that state, and when the connection terminates, the state is removed, and you don't have to clean up any rules. So all that's missing is time to design it properly and implement it correctly, right? Cedruc
Re: syn-proxy application-level-proxy
Mike Frantzen wrote: I've been probably dreaming too, but I would love to have some kind of scrub tcp that would reassemble the stream, before forwarding it. That would allow me to easily bypass the PMTU problems for example, without having to tweak all clients (Win2000 friends will send 1500 byte segments, the gateway will reassemble them, and regenerate 1300 bytes segments to the destination transparently, wow) Is that a crazy idea? use the max-mss scrub option. the hosts should then take care of it themselves. some nat/dsl routers automatically do this. .mike Hey, great! I guess that solves my main problem, thanks! Now about the userland inspection. I wonder if it's not possible with just what we've now, i.e a using a proxy, RDR and NAT: 1) the incoming connection is RDRed to the inspection proxy 2) the inspection proxy open a new socket / new UDP packet to the real destination 3) somehow, a NAT rule is created to make that 2nd connection originate from the same socket as the first connection/packet. Would that work? Cedric
Re: Syntax problem
Per-Olov Sjöholm wrote: Hi ! Is there a reason that a rule like this works. block in quick on $ALL_INTERFACES inet from any to $DMZ1_INT:broadcast But not this dynamic update one with () block in quick inet from any to ($INTERNET_INT):broadcast The rule simply doesn't work with the () specified. Have I missed something ? :broadcast and friends do not yet work with dynamic interfaces. I'm working on that a bit though, but this will be post-3.4 material. Cedric
Re: PF filter decisions based on source OS type
Mike Frantzen wrote: We need your help to populate the operating system database. Please go to http://lcamtuf.coredump.cx/p0f-help with as many machines with web browsers as possible and type in your OS name if it doesn't recognize the machine. I'm typing that mail on a W2K box, behind a OpenBSD Firewall (NAT). My system is not recognized, what should I put there? Cedric
Re: DIOCCHANGEADDR in 3.3-stable
Daniel Hartmeier wrote:
I'm going to fix it (will require a kernel patch, probably will end up
in -stable), but depending on what you wanted to do with the ioctl,
there's alternatives:
DIOCCHANGEADDR is meant to manipulate the pool addresses of a rule,
depending on the rule type that's
rdr ... - { a, b, c } ...
nat ... - { a, b, c } ...
pass route-to { a, b, c } ...
[...]
So, do you really want to change a pool address? If that's the case,
we'll have to fix the ioctl first. Otherwise I can supply an example for
DIOCCHANGERULE. Tell me what you want to do.
There might be an alternative way :)
Just grab the latest version of -current (2 minutes old maximum).
With that you will be able to put tables in pools, like:
nat from a to b - foo
And them manipulate addresses in foo using pfctl or table ioctls.
Feedback welcome!
Cedric
PS: you might have to wait for the code to propagate to the mirrors...
Re: Only one PF table for all connections?
Dom De Vitto wrote: Problem I've a filtering bridge, which connects in/out to another firewall (yea, yea, paranoid I know) and the local lan. I run snort on the various bits of network cable, watching the outside and inside bridges, and cross-correlating. My problem appears to be that there is only one state table in the kernel for all PF connections, and so I need to ensure that only one interface creates state table entries. Hmmm. I'll explain by flow: 1) I send a tcp SYN from my PC to my PF-bridge on fxp0 (bridge0). 2) The bridge sends this to my firewall on fxp1 (bridge0). 3) The firewall sends this on to the PF-bridge on fxp2 (bridge1). 4) The bridge sends this to my gateway out of fxp3 (bridge1). Now I can add pass rules, without keep state, on anywhere, but if I put a keep state on an i/f on bridge0, naturally it sees the same packet on bridge1 and drops it, because it's expecting a reply, not a duplicate. Does this sound right, and does anyone know how I can get around it? I'd like to keep state on all rules, if possible. You're right, 2 bridges on the same machine cannot work with PF. That was discussed before, without conclusive solution. I was in favor of tying states to interfaces, but there was objections. Maybee we need a keyword like lock or attach or tie to attach a state to a given interface, which would solve your problem (and other problems) Cedric
Re: Only one PF table for all connections?
Daniel Hartmeier wrote: You're right, 2 bridges on the same machine cannot work with PF. That was discussed before, without conclusive solution. I was in favor of tying states to interfaces, but there was objections. Maybee we need a keyword like lock or attach or tie to attach a state to a given interface, which would solve your problem (and other problems) I agree it should be done, but we'll have to solve a couple of issues first. For instance, the NATLOOK ioctl would require the caller to pass the interface name for the state lookup (otherwise it might find the wrong state). Yes, either that of having NATLOOK return all states found (potentially 1) There are several tools that use NATLOOK by now (ftp-proxy, the ssh patch, squid and other proxies in ports). We'll have to adjust them all. For instance, ftp-proxy would probably require a new command line switch to specify the interface name for the NATLOOK ioctl (it doesn't need to know the interface for anything else, and I see no way it could figure it out without an additional switch). Well, I'm really interrested in that feature. Now that I've almost finished the cleaning up of userland, I'd be interrested to work on that. After the 5 days vacations that I'm gonna take from Friday to next Tuesday... Cedric
Re: Only one PF table for all connections?
There should be a solution for your setup that doesn't require four states (bound to the interface), so the discussion got side-tracked here. The problem is that even if just one state that get's created (say on the first bridge) when the same packet traverse the second bridge it will match the state of the first bridge and bang. If it was a translation state, double bang. Cedric
Re: PF - real-time(ish) logging of state changes?
William Yang wrote: How can I get a similar stream of NAT state changes? I see how to pull the NAT states with pfctl -s, but is there any way to get a stream of state changes that can similarly be logged into a pipe, so that I can do similar analysis? Any suggestions? man pfsync Cedric
Re: College problem :)
Peter Hun wrote: Is it anyhow possible, for current allowed ports, to use all the bandwidth and to keep everything else at let's say 2Mbit? Inbound and outbound. Isn't that the purpose of ALTQ? I've tried something using altq/pf but without achieving all the objectives. :( Could you elaborate? Cedric
Re: Load Balancing and pf rdr
Jonathan S. Keim wrote:
Hello all,
I was reading the archives from October 2002 on load-balancing with
pf[1], and it seems that adding the ability to redirect to hosts from a
dynamic table would make building userland health monitoring
substantially easier.
For example, if we have the following pf.conf:
# pf.conf #
virtual_ip = 192.168.0.6
table web_servers persist { 192.168.0.7, 192.168.0.8 }
rdr proto tcp from all to $virtual_ip port 80 - web_servers port 80
###
we could manipulate the table web_servers from userland (if all else
fails, use pfctl) without having to know the rule number like we would
with DIOCCHANGEADDR (as Daniel mentioned in a different thread[2]).
Thoughts?
We will implement that someday, but I don't know when.
Cedric
Re: tabels and label macros
Henning Brauer wrote:
I prefer this instead.
Yep, it's much better!
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.390
diff -u -r1.390 parse.y
--- parse.y 9 Jun 2003 11:14:46 - 1.390
+++ parse.y 18 Jun 2003 09:25:48 -
@@ -3194,6 +3194,8 @@
if (strstr(label, name) != NULL) {
if (h-addr.type == PF_ADDR_DYNIFTL)
snprintf(tmp, sizeof(tmp), (%s), h-addr.v.ifname);
+ else if (h-addr.type == PF_ADDR_TABLE)
+ snprintf(tmp, sizeof(tmp), %s, h-addr.v.tblname);
else if (!af || (PF_AZERO(h-addr.v.a.addr, af)
PF_AZERO(h-addr.v.a.mask, af)))
snprintf(tmp, sizeof(tmp), any);
Henning Brauer wrote:
On Wed, Jun 18, 2003 at 09:49:31AM +0200, Claudio Jeker wrote:
Hi all,
out of curiosity I tried a rule like:
pass in from any to table keep state label out_$dstaddr
which results in this funny output:
out_97.108.108.111/0 290089 453609 54227731
It is clear that $dstaddr/$srcaddr can only be used on non table rules so
pfctl should bark on rule loading.
I prefer this instead.
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.390
diff -u -r1.390 parse.y
--- parse.y 9 Jun 2003 11:14:46 - 1.390
+++ parse.y 18 Jun 2003 09:25:48 -
@@ -3194,6 +3194,8 @@
if (strstr(label, name) != NULL) {
if (h-addr.type == PF_ADDR_DYNIFTL)
snprintf(tmp, sizeof(tmp), (%s), h-addr.v.ifname);
+ else if (h-addr.type == PF_ADDR_TABLE)
+ snprintf(tmp, sizeof(tmp), %s, h-addr.v.tblname);
else if (!af || (PF_AZERO(h-addr.v.a.addr, af)
PF_AZERO(h-addr.v.a.mask, af)))
snprintf(tmp, sizeof(tmp), any);
We should start using switch(type) statements in this kind of code...
For example, I wonder what pass in from any to no-route would produce...
Cedric
Re: Flush counters
Daniel Hartmeier wrote: But reloading the ruleset will reset all per-rule counters as a side- effect, while the existing state entries will continue to work (ongoing connections are not affected), so that should be close enough. Unfortunately, I think that if you do it that way, existing states will stop updating rules counters. BTW: there is a way to flush table counters (pfctl -Tz) Cedric
Re: synproxy problems with bridge
Thanks for the quick reply. Do you know if support for synproxy on a bridge is planned? it can only work if the bridge has in ip address. the same applies to the link2 for brconfig(8) and other things. I will *try* to implement a solution for that problem, assuming symetrical routing when no routing table is defined. Cedric
Re: synproxy problems with bridge
I will *try* to implement a solution for that problem, assuming symetrical routing when no routing table is defined. I don't think that makes sense... Why? I, for one, would love it. Cedric
Re: NFS rules no-df syntax
Aaron Wade wrote: 2) Does PF read faster from an external file or a table list ( a la table testnfs ) within pf.conf ? It does not make any difference in either loading or running time. In both case, the table is filled at the time you load your ruleset. Cedric
Re: pfioc_table.pfrio_esize?
James Kinney wrote: I have what is probably a stupid question. I am trying to compile an application that uses the pfioc_table structure. In the man page for pf it lists a pfrio_esize variable. In the pfctl source this variable is assigned with the size of the pfr_table buffer. When I compile my application, or try to recompile pfctl I am getting the following error. pf_tool.c: In function `pfr_get_tables': pf_tool.c:67: structure has no member named `pfrio_esize' Update your sources to -CURRENT, and don't forget to run #cp /sys/net/pfvar.h /usr/include/net/pfvar.h Cedric
Re: important pf changes
Henning Brauer wrote:
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.343
diff -u -r1.343 parse.y
--- parse.y 19 Mar 2003 15:51:40 - 1.343
+++ parse.y 1 Apr 2003 01:20:48 -
@@ -3418,93 +3418,93 @@
{
/* this has to be sorted always */
static const struct keywords keywords[] = {
- { all, ALL},
- { allow-opts, ALLOWOPTS},
- { altq, ALTQ},
- { anchor, ANCHOR},
- { antispoof,ANTISPOOF},
- { any, ANY},
- { bandwidth,BANDWIDTH},
- { binat,BINAT},
- { binat-anchor, BINATANCHOR},
- { bitmask, BITMASK},
- { block,BLOCK},
- { block-policy, BLOCKPOLICY},
- { borrow, BORROW},
- { cbq, CBQ},
- { code, CODE},
- { crop, FRAGCROP},
- { default, DEFAULT},
- { drop, DROP},
- { drop-ovl, FRAGDROP},
- { dup-to, DUPTO},
- { ecn, ECN},
- { fastroute,FASTROUTE},
- { file, FILENAME},
- { flags,FLAGS},
- { for, FOR},
- { fragment, FRAGMENT},
- { from, FROM},
- { group,GROUP},
- { icmp-type,ICMPTYPE},
- { icmp6-type, ICMP6TYPE},
- { in, IN},
- { inet, INET},
- { inet6,INET6},
- { keep, KEEP},
- { label,LABEL},
- { limit,LIMIT},
- { log, LOG},
- { log-all, LOGALL},
- { loginterface, LOGINTERFACE},
- { max, MAXIMUM},
- { max-mss, MAXMSS},
- { min-ttl, MINTTL},
- { modulate, MODULATE},
- { nat, NAT},
- { nat-anchor, NATANCHOR},
- { no, NO},
- { no-df,NODF},
- { no-route, NOROUTE},
- { on, ON},
- { optimization, OPTIMIZATION},
- { out, OUT},
- { pass, PASS},
- { port, PORT},
- { priority, PRIORITY},
- { priq, PRIQ},
- { proto,PROTO},
- { qlimit, QLIMIT},
- { queue,QUEUE},
- { quick,QUICK},
- { random, RANDOM},
- { random-id,RANDOMID},
- { rdr, RDR},
- { rdr-anchor, RDRANCHOR},
- { reassemble, FRAGNORM},
- { red, RED},
- { reply-to, REPLYTO},
- { require-order,REQUIREORDER},
- { return, RETURN},
- { return-icmp, RETURNICMP},
- { return-icmp6, RETURNICMP6},
- { return-rst, RETURNRST},
- { rio, RIO},
- { round-robin, ROUNDROBIN},
- { route-to, ROUTETO},
- { scrub,SCRUB},
- { set, SET},
- { source-hash, SOURCEHASH},
- { state,STATE},
- { static-port, STATICPORT},
- { table,TABLE},
- { tbrsize, TBRSIZE},
- { timeout, TIMEOUT},
- { to, TO},
- { tos, TOS},
- { ttl, TTL},
- { user, USER},
- { yes, YES},
+ { AndereSchlangen, ALTQ},
+ { Anker,ANCHOR},
+ { Bandbreite, BANDWIDTH},
+ { Benutzer, USER},
+ { Datei,FILENAME},
+ { Flaggen, FLAGS},
+ { Gruppe, GROUP},
+ { Hafen,PORT},
+ { Klassen-basiertes-anstellen, CBQ},
+ { Kode, CODE},
+
Re: pf rule sintax (newbie)
[EMAIL PROTECTED] wrote:
I'm almost totally new to pf.
I'v noticed that this syntax is not accepted:
Ext_If = rl0
MyVar = { 1.2.3.4/32, 2.1.0.0/24 }
pass in on $Ext_If from any to !$MyVar
beware of rule expansion.
PF would expand that to:
pass in on $Ext_If from any to !1.2.3.4/32
pass in on $Ext_If from any to !2.1.0.0/24
which is probably not what you want.
with 3.3, you can use a table to do that:
table MyVar const { 1.2.3.4/32, 2.1.0.0/24 }
pass in on $Ext_If from any to !MyVar
Cedric
Re: set loginterface
Henning Brauer wrote: Obviously, nobody of you has thought through the consequences of collecting the stats on each interface. How do you know such a thing? As I said, I've a patch that did that in the past, for 3.0 or 3.1. So obviously I know something about the consequences on the code. However, I'm not saying we need to do it. I don't know. You're raising some good points. Yor example, 'pfctl -si' would clearly need to take an extra argument, like 'pfctl -si fxp0' Yes, this will make the kernel a bit more complicated, but also note that it will make the userland simpler. i.e, set loginterface end friend could can go AWAY. We can surely have a good discussion about the plus and minuses of doing that, but with sentenses like I do not want this bloat in pf, it is difficult to have a healthy discussion. Personally, I like orthogonality. If loginterface is useless, why not killing it? if loginterface is useful, why restricting to one interface? I guess the question we need to know is the how ppl use that feature, and for what. I've no hard feeling about implementing that or not, but if ppl find it useful, I don't think it's impossible to implement cleanly. Cedric
Re: set loginterface
[EMAIL PROTECTED] wrote: you only want one because - In order to keep with the *nix ethic of one tool one job - a singular loginterface gives you one point of contact for your tool of choice for splitting out your various types of logs - i.e.. pipe it through grep tee orsee? I'm looking at the left, at the right, before me, but I still didn't see.
Re: pf rules and some confusion
Will PF load a rule for each IP given by www.example.com DNS resolution ? Yes.
Re: pf vs Linux NFS
Mike Frantzen wrote: Quite possibly the final word on the matter: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58084 I may as well clarify the purpose of SCRUB to the masses since Niels seems to be on an extended hiatus rolling a few tanks into france or something. Scrub is not fragment reassembly. Scrub is traffic normalization. Traffic normalization is resolving traffic ambiguities when possible and blocking the ambiguous traffic when it cannot be resolved. It allows the view to passive systems behind the firewall to be consistent with what the end host sees. This guarantees that intrusion detection systems will operate in the presence of evasion without having to guess at the end hosts stack and their reassembly mechanisms. In the future, it will allow us to tighten up the state code in PF if we can be more certain that packets received by the firewall will be received by the end host. Why does scrub drop MF|DF fragments? Because it is not clear whether the end host will reassemble those packets. Some people consider fragments with the Don't Fragment bit set to be perfectly logical, others of us don't know what the hell it means. That folks, is an ambiguity and is exactly what the scrubber is tasked to prevent. Perfect, so following your argumentation here, scrub should normalize the packets to ensure the end host will reassemble those packets That mean to me: 1) Reassemble the packet 2) *Remove* the DF bit (since PMTU will stop here anyway) 3) Send it to the new host (possibly refragmenting it, but *without* the DF) Or am I missing something? BTW, if the end host is this host (like in my NFS case) there is no ambiguities, we know we do accept theses packets. Cedric
Re: handle options like source routing?
Maik Kuendig wrote: Is it a good idea to filter packages, as a example with source routing, or is it not nessesary and I ask a stupid question? I personally would *love* to be able to use PF to *insert* source routing on some outgoing packets Cedric
Re: dup-to
Marco Grigull wrote: If I want to forward all ip traffic verbatim to a loghost/ids machine, would the following rules suffice? # forward stuff to our loghost/IDS pass in log on $ext_if dup-to $dmz_if all How's dmz_if defined? did you put the IP of your loghost/IDS in there? If not, I think you should. Cedric
Re: Are more than one log interfaces possible pflog0, pflog1...
[EMAIL PROTECTED] wrote: Is it possible to bring up more than one pflog interfaces on PF, like pflog0, pflog1,...etc, and be able to have a rule log to a specific interface? I tried Block on log pflog0 and made a syntax error - would this be a 'good thing' for PF? IMHO, yes. I've wanted that feature a couple of time, already. log pflog0 seems too long for me, so I'd vote for log 0! Cedric
Re: Nat and pf question
Or if there's some way of doing something like ! { fxp0, fxp2 }, that would
make things easier too.
I do not understand what you wanna do, but you can try this:
table fxp0fxp2 const { fxp0 fxp2 }
and then use !fxp0fxp2
But that doesn't seem like a shortcut to me.
Cedric
Re: RFC: libpf, simplifying pf(4) access to userland apps
If we leave out all the technical challenges involved, the real question is if the pf developers find this idea useful at all? A few points, in wrac: 1) I kind of like libraries, but they are difficult to get right, and probably more difficult is to have people agree to use it. 2) Theo doesn't like libraries too much. 3) The current way file are shared between pfctl, authpf and tcpdump is kind of ugly IMHO. 4) I've never used authpf, but I wonder why authpf does not call the pfctl binary, to have the benefit of code reuse without that tricky sharing of files. Combining binaries is usually the Unix way, I believe. Cedric
Re: RFC: libpf, simplifying pf(4) access to userland apps
Srebrenko Sehic wrote: On Thu, Jan 09, 2003 at 07:50:09PM +0100, Henning Brauer wrote: pfctl does not support inserting rules on the fly and authpf needs that. On the other hand, the overhead of having that would be too big. h, things changed... authpf uses anchors now, that IS possible with pfctl... hmmm. Didn't know that. So, authpf can insert rules on fly using anchors, but is this possible with arbitrary applications? Say I want my snort box to insert filter rules into pf, by sending a messages (something like 'block 192.168.0.1') There is a table feature that has just been commited to the kernel. You can write in pf.conf: table snortblacklist persist block in from snortblacklist to any And then, your snort box can do the following: ssh firewall pfctl -t snortblacklist -Ta 192.168.0.1 Cedric
Re: PF works for everying but 1 port??
Sabino, Justin wrote:
Okay, I'm stumped here. I'm running OpenBSD v3.1 and have the
following issue. I have PF setup (pf.conf and nat.conf) and
everything has been working great for a while. I have several
services that re-direct to one of 2 boxes on my internal (private
192.168.1.x) network. Here is the issue. I am finally getting around
to setting up a webserver on my internal network and since my ISP
doesn't allow port 80 to come into their network ever since code red
happened, I am trying to re-direct port 81 to the web server running
at port 80 on the internal box (Linux/Apache). The internal servers
IP is 192.168.1.5 and I've verified that the webserver is up and running:
[root@t5 root]# telnet 192.168.1.5 80
Trying 192.168.1.5...
Connected to 192.168.1.5.
Escape character is '^]'.
I had someone try and telnet to my OpenBSD box on port 81 (which sould
re-direct to the internal server on port 80) and I do see their
traffic hitting the external interface (via tcpdump) but when I do the
same tcpdump on the internal interface I see nothing, seems to be
getting stuck on the OpenBSD box somehow. However, all my other
services (ssh, ftp, dns, smtp) re-direct with no problem and are
working fine.
Here is an output of a pfctl -s rules leading up to the rule that
allows the port 81 traffic in:
@0 block in quick on rl0 inet from 10.0.0.0/8 to any
@1 block in quick on rl0 inet from 172.16.0.0/12 to any
@2 block in quick on rl0 inet from 192.168.0.0/16 to any
@3 block in quick on rl0 inet from 127.0.0.1/8 to any
@4 block in quick on rl0 inet from 255.255.255.255/32 to any
@5 block in quick on rl0 inet from 0.0.0.0/32 to any
@6 block out quick on rl0 inet from any to 10.0.0.0/8
@7 block out quick on rl0 inet from any to 172.16.0.0/12
@8 block out quick on rl0 inet from any to 192.168.0.0/16
@9 block out quick on rl0 inet from any to 127.0.0.1/8
@10 block out quick on rl0 inet from any to 255.255.255.255/32
@11 block out quick on rl0 inet from any to 0.0.0.0/32
*@12 pass in log quick on rl0 proto tcp from any to any port = 81
flags S/SA*
replace port=80 and it will work
Cedric
Here is an output of a pfctl -s nat that shows what the re-direct
should be:
*rdr on rl0 proto tcp from any to 67.82.111.216/32 port 81 -
192.168.1.5 port 80*
Here is the relevant stuff from my pf.conf file:
goodports={ 443, 21, 22, 25, 113, 81 }
ext=rl0 # External Interface
int=rl1 # Internal Interface
# Allow Inbound Services
pass in log quick on $ext proto tcp from any to any port $goodports
flags S/SA
Here is the relevant stuff from my nat.conf:
ext=rl0
int=rl1
ip=67.82.111.216/32
rdr on $ext proto tcp from any to $ip port 81 - 192.168.1.5 port 80
Sorry for the long post but wanted to give you guys as much
information as I could to show you what I've looked at so far. Any
help would be appreciated.
Thanks,
JMS
pfradix/pfctl patch
Attached is a patch that fixes 3 problems Daniel found in
pfctl_table.c Please also make sure you update net/pf_table.c
to the latest version (version 9), sorry for that.
Cedric
--- pfctl-0.3/pfctl_table.c Wed Jan 1 19:58:07 2003
+++ pfctl-0.4/pfctl_table.c Wed Jan 1 22:54:49 2003
@@ -69,6 +69,7 @@
static void_append_addr(char *, int);
static void_print_addr(struct pfr_addr *);
static void_print_astats(struct pfr_astats *);
+static void_perror(void);
static union {
@@ -106,7 +107,7 @@
#define DUMMY ((flags PFR_FLAG_DUMMY)? (dummy):)
#define RVTEST(fct)\
do { int rv = fct; if (rv) \
- { perror(__progname); return (1); } \
+ { _perror(); return (1); } \
} while (0)
int
@@ -137,7 +138,7 @@
struct pfr_table table;
char**p;
int nadd = 0, ndel = 0, nchange = 0, nzero = 0;
- int i, rv, flags = 0;
+ int i, j, flags = 0;
for (p = commands; *p != NULL; p++)
if (!strncmp(command, *p, strlen(command)))
@@ -299,15 +300,19 @@
if (!strcmp(*p, test)) {
_load_addr(argc, argv, file, 1);
RVTEST(pfr_tst_addrs(table, buffer.addrs, size, flags));
- rv = 0;
+ j = 0;
for (i = 0; i size; i++) {
- if (buffer.addrs[i].pfra_fback != PFR_FB_MATCH)
- rv = 2;
+ if (buffer.addrs[i].pfra_fback == PFR_FB_MATCH)
+ j++;
if (opts PF_OPT_VERBOSE)
if ((opts PF_OPT_VERBOSE2) ||
buffer.addrs[i].pfra_fback)
_print_addr(buffer.addrs+i);
}
+ if (!(opts PF_OPT_VERBOSE) !(opts PF_OPT_QUIET))
+ printf(%d/%d addresses match.\n, j, size);
+ if (j size)
+ return (2);
}
if (!strcmp(*p, zero)) {
if (argc || file != NULL)
@@ -324,7 +329,7 @@
void
_grow_buffer(int bs, int minsize)
{
- assert(minsize == 0 || minsize size);
+ assert(minsize == 0 || minsize msize);
if (!msize) {
msize = minsize;
if (msize 64)
@@ -531,4 +536,13 @@
stats_text[dir][op],
as-pfras_packets[dir][op],
as-pfras_bytes[dir][op]);
+}
+
+void
+_perror(void)
+{
+ if (errno == ESRCH)
+ fprintf(stderr, %s: Table does not exist.\n, __progname);
+ else
+ perror(__progname);
}
