Re: how to turn off pfsync globally on FreeBSD-CURRENT
On Sat, Jul 16, 2005 at 01:41:24PM +0200, Michael Weiser wrote: > Hello, > > I'm having trouble silencing pfsync on my FreeBSD-CURRENT box. It > insists on broadcasting packets like this > > rule 38/0(match): block out on xl1: 10.10.1.2 > 0.0.0.0: pfsync 228 > > to the external network interface for every state change. Up until now I > circumvented that by adding the no-sync option to every rule. But since > I installed pftpx I get those broadcasts again, seemingly because > pftpx's dynamic rules don't have the no-sync option. Now I did another > hack and just said > > ifconfig pfsync0 syncdev lo0 why are you creating pfsync0 at all if you don't need it? ifconfig pfsync0 destroy should get rid of it. make sure you dont have any ifconfig_pfsync0="..." in your /etc/rc.conf to keep it from reappearing on reboots. -j -- "Quagmire: Don't look at me like that. Fat chicks need love too... but they got to pay." --Family Guy
Re: Newbie question.
On Tue, Jun 21, 2005 at 08:23:49PM -0400, Jason Dixon wrote:
> On Jun 21, 2005, at 6:24 PM, Bill Swisher wrote:
>
> >After reading over the pf-faq.pdf file I have, at this time, one
> >question. The home/small office example assumes that the internet
> >lives off of "ep0". In my case this is partially true. What really
> >is there is a router running on the network 192.168.2.* (my internal
> >network is the standard 192.168.1.*) and if I use the command "block
> >drop in quick on $ext if from $priv_nets" and it's corresponding
> >output block I'd pretty much be sitting deaf and mute, as far as the
> >rest of the computing world goes near as I can figure.
> >
> >I like that router! It does the PPoE for me, along with minimal
> >blocking. I don't want to toss it.
> >
> >Anyone have a way around this?
>
> priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
> !192.168.2.0/24 }"
i'm certainly missing something here, as i am somewhat new-ish to pf
(long time with ipf, though)...
the above macro definition of priv_nets will create the rules:
block drop in quick on ep0 inet from 127.0.0.0/8 to any
block drop in quick on ep0 inet from 192.168.0.0/16 to any
block drop in quick on ep0 inet from 172.16.0.0/12 to any
block drop in quick on ep0 inet from 10.0.0.0/8 to any
block drop in quick on ep0 inet from ! 192.168.2.0/24 to any
where the second rule will drop traffic from 192.168.2.0/24, and the
fifth rule will effectively drop all other traffic.
in my experience--lists of networks/IP's that need to be negated always
seem to need to go in a table to work properly. now i never tried this
before, but i just tested it (on 3.7-release), and it appears to work
(tables *really* kick ass):
ext_if = "ep0"
table const \
{ 127/8, 10/8, 172.16/12, 192.168/16, !192.168.2/24 }
block drop in quick on $ext_if from
with that--traffic from the RFC1918 space plus the loopback net (*) gets
dropped, but 192.168.2.0/24 gets to the next rule.
HTH...
-j
(*) i'm pretty sure that the openbsd routing code drops traffic from
127/8 received "on the wire" before pf ever sees it--so the inclusion of
127/8 in the table is not strictly necessary.
--
"Stewie: Damn you, vile woman, you've impeded my work since the day I
escaped your wretched womb."
--Family Guy
Re: (src_addr) && (dst_addr)
On Wed, Apr 20, 2005 at 09:44:59PM +0930, alex wilkinson wrote: > Hi all, > > I have a macro defined such as: > > EXT_IF="tun0" > > I want to refer to this interface in parentheses in case tun0's DHCP > ip address changes. > However, when I use the (...) feature in the following rule for example: > > block return-rst in log on ($EXT_IF) proto tcp all "on $EXT_IF" resolves to the interface name, not the IP address. the interface NAME is not dynamic--the IP address is. use the parentheses when the token is expanded to the IP address, like if you had: block return-rst in log on $EXT_IF proto tcp from any to ($EXT_IF) > I get "/etc/pf.conf:83: syntax error" > > I can't see anything odd about my rule except for tun0 is a virtual interface. > Should or can I use 'ppp' for $EXT_INT ? might i recommend a re-read of the PF User's Guide: http://openbsd.org/faq/pf/index.html -j -- "Chris: Here, it's a Candy-cane. But don't stick it up your nose, it burns like hell." --Family Guy
Re: ranges within a table ... is it possible ?
On Wed, Apr 20, 2005 at 09:56:48PM +0930, alex wilkinson wrote:
> Hi all,
>
> Is it possible to specify a range within a table ? e.g.
>
> table 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 ?
tables hold IP addresses, not port numbers. and even with IP
addresses--no, tables do not support IP addresses ranges (break it down
to CIDR).
how about:
itunes = "8000 >< 8999"
pass in inet proto tcp from any to any port $itunes
-j
--
"Brian: Seriously, who buys a novelty fire extinguisher?
Peter: I'll tell you who: someone who cares enough about physical
comedy to put his entire family into serious danger, that's who."
--Family Guy
Re: dup-to problem with specific packets
On Sun, Apr 10, 2005 at 11:18:58PM -0400, Michael W. Lucas wrote: > Hi, > > I'm trying to duplicate packets matching one particular rule. > > Background: I have softflowd running on OpenBSD 3.5 i386. This is > exporting flows to a logging host. Works beautifully. > > The old logging host is being replaced. I would like to run the two > logging hosts in parallel temporarily, until I'm sure all the bugs are > out of the new one. > > While I could fire up a second instance of softflowd, it seems like > this would be a good application of dup-to. I don't want to duplicate > the entire mass of traffic going through this box, just the netflow > packets. > > pass out on $int_if proto udp from any to a.b.c.251 port 8641 dup-to ($int_if > a.b.c.252) > > (port number changed to protect the guilty, of course) > > pfctl -nf gives me a syntax error on line 80, but won't be specific on > what the problem is. > > Any suggestions? Or am I just outright misunderstanding dup-to? dup-to goes in the same spot as route-to and reply-to, so: pass out on $int_if dup-to ($int_if a.b.c.252) inet proto udp \ from any to a.b.c.251 port = 8641 appears to be the correct syntax here (3.6 GENERIC#0 sparc64) -j -- "Contestant: I'll take the dying boy to block. Tom Bergeron: Ok, Jeremy... is there anything lower than absolute zero? Jeremy: Uhh, yeah... my white cell count." --Family Guy
Re: Anchors with tables
On Sat, 2005-03-26 at 17:56, Jason Dixon wrote:
> Looking at pf.conf (5), it claims that anchors can "hold rules, address
> tables, and other anchors". Unfortunately, neither the man page nor
> the PF User's Guide give an example of using an anchor to hold address
> tables. I've tried this on 3.6 -release, and it does not appear to
> work:
<--snip-->
> It appears that pfctl assumes that anchors only contain filter rules.
> Have I stumbled over a bug in either pf.conf (5) or pfctl, or am I
> doing/assuming something wrong?
dunno if this is a remotely useful response, but the snippets of file
you provided work fine here (on both 3.6-release and the latest
snapshot):
-release machine:
$ uname -a
OpenBSD obiwan 3.6 GENERIC#0 sparc64
-snapshot machine:
$ uname -a
OpenBSD snappy 3.7 GENERIC#50 i386
$ cat pf.conf
ext_if="fxp1"
int_if="fxp0"
pfsync_if="xl0"
anchor pf_labels_tables
load anchor pf_labels_tables from "pf_labels_tables.anchor"
$ cat pf_labels_tables.anchor
table { 10.0.0.101 }
table { 10.0.0.102 }
table { 10.0.0.103 }
table { 10.0.0.104 }
table { 10.0.0.105 }
table { 192.168.0.31 }
table { 192.168.0.32 }
table { 192.168.0.33 }
table { 192.168.0.34 }
table { 192.168.0.35 }
$ pfctl -vvnf pf.conf
Loaded 345 passive OS fingerprints
ext_if = "fxp1"
int_if = "fxp0"
pfsync_if = "xl0"
@0 anchor pf_labels_tables all
warning: macro 'ext_if' not used
warning: macro 'int_if' not used
warning: macro 'pfsync_if' not used
Loading anchor pf_labels_tables from pf_labels_tables.anchor
table { 10.0.0.101 }
table { 10.0.0.102 }
table { 10.0.0.103 }
table { 10.0.0.104 }
table { 10.0.0.105 }
table { 192.168.0.31 }
table { 192.168.0.32 }
table { 192.168.0.33 }
table { 192.168.0.34 }
table { 192.168.0.35 }
all output is from the -release machine, but the -snapshot output is
identical.
my guess is that there's something else going on in the part of the
pf.conf that we haven't seen.
-j
--
"I'm better than dirt. Well, most kinds of dirt... not that fancy
store-bought dirt... that stuff's loaded with nutrients, I... I
can't compete with that stuff."
--The Simpsons
Re: AIM connection issues
On Fri, 2005-03-25 at 13:03, florian mosleh wrote: > The only other factor that I see as possibly contributing to the problem (i'm > not sure how) is that the internet connection is a set of 4 bonded t1s, but > I've > been given the impression that this shouldn't make a difference. you're pretty light on details--so the quality of help you receive is going to reflect that. the only thing that jumps out at me is that awhile back, AOL changed its login process such that the user actually connects to about 4 different servers in order to complete the login process. if the user's source IP changes during this process--the login fails. if you are performing outbound NAT for your clients and using a pool of addresses like so: nat on $outside inet from $inside_nets to any -> $nat_pool round-robin (where prefix length of $nat_pool < 32) try adding "sticky-address" for TCP 5190 connections (this obviously must come before the previous rule): nat on $outside inet proto tcp from $inside_nets to any port = 5190 \ -> $nat_pool sticky-address if this doesn't help...well--what did you really expect? -j -- "Mr. Simpson, why are you here? Don't say revenge! Don't say revenge! Revenge? That's it! I'm outta here!" --The Simpsons
Re: pf and Cisco route map equivalent?
On Wed, 2005-03-23 at 15:21, Xavier wrote: > Hi, > > Just one question... Maybe stupid, pardon me! > Can I define sort of "route maps" such as > in Cisco devices with pf? > > Ex: if source address = x.x.x.x -> send to next hop "y.y.y.y" yes--"route-to" can be used for this: pass in on $int_if route-to ($ext_if y.y.y.y) inet from x.x.x.x \ to any keep state -j -- "Asleep at the switch? I wasn't asleep, I was drunk!" --The Simpsons
Re: PF and promiscuous mode
On Fri, 2005-03-18 at 10:48, Michael W. Lucas wrote: > Hi, > > I'm using two PF boxes as traffic shapers, with CARP, running 3.5 > GENERIC#127 i386 (to be updated to 3.7 as soon as it hits the > shelves.) > > Will promiscuous mode see traffic before or after queueing on an > interface? inbound to an interface: before. outbound from an interface: after. promiscuous mode apps normally attach at the BPF layer which is below where a layer 3 filter like PF hooks into the stack. so as a packet go up the stack it hits BPF, then layer 3 filter. as a packet goes down the stack on the way out, it hits layer 3 filter then BPF. -j -- "If I wanted smoke blown up my ass, I'd be at home with a pack of cigarettes and a short length of hose." --The Simpsons
Re: pf vs ASIC firewalls
On Mon, Mar 14, 2005 at 03:50:23PM +0530, Siju George wrote: > So probably no checks "later" in the protocol. Similar problem with > CheckPoint's "fastpath" option, btw." 1) check point fw-1 is software, not hardware. 2) the "fastpath" option hasn't been around since 4.0 (and has always been deprecated). 3) in NG--all packets pass through the deep inspection filter engine (even if you enable the securexl acceleration feature). -j -- "Beer. Now there's a temporary solution." --The Simpsons
Re: CIDR Networks in recursive Macros
On Thu, 2005-02-17 at 10:21, Aaron Spanik wrote:
> I couldn't find this issue in any of the documentation I could find, so
> I thought I'd ask here.
>
> Macros in pf can be defined recursively, but it doesn't seem to work
> when the macros that are being expanded are CIDR-style network
> specifications.
>
> For instance, while this works:
>
> wibble = { 192.168.1/24 192.168.4/24 }
>
> This does not (fails with a syntax error when trying to load):
>
> muh = "192.168.1/24"
> fuh = "192.168.4/24"
> wibble = "{" $muh $fuh "}"
>
> I've tried it with commas, with one macro and one literal, with
> non-abbreviated style (i.e. 192.168.1.0/24), etc., but nothing seems to
> work.
>
> Recursive macros work normally with individual hosts, but not netblocks.
>
> Is this a feature or a bug?
quirk in the parser--need more quotes.
net1 = '"172.16.0.0/12"'
net2 = '"192.168.0.0/16"'
net3 = '"10.0.0.0/8"'
rfc1918 = "{" $net1 $net2 $net3 "}"
-j
--
"I'll leave the world the same way I came into it - dirty, screaming
and torn away from the woman I love."
--The Simpsons
Re: blocking IP range Q
On Tue, Feb 15, 2005 at 09:42:40AM -0800, Dominic Opferkuch wrote: > Hello > > I need to block certain IP's on my webserver. Can > anyone point out how to do that. > > Here the IP address range I need to block > > (*-ed out the first three digits) > ***.139.192.0 --***.139.223.255 > > Thanks for the help friends generically: block drop in quick inet from ***.139.192.0/19 to any -j -- "English - Who needs that? I'm never going to England!" --The Simpsons
Re: new feature
On Fri, Jan 28, 2005 at 10:37:44AM -0800, Gustavo A. Baratto wrote: > hello all, > > Is it (or will be) possible to set different state timeouts for different > rules? > > For example, if I'm using http, and I need to keep the state for 10 minutes > because of an e-commerce session, and I dont want to keep the state for > smtp for more than 30 seconds. > > Something like: > - > set timeout 60 #default timeout > > # http rule > pass out on fxp0 proto tcp from any to any port www keep state timeout 600 > > # smtp rule > pass out on fxp0 proto tcp from any to any port smtp keep state timeout 30 you can do that today: pass out on fxp0 proto tcp from any to any port = www \ keep state (tcp.established 600) pass out on fxp0 proto tcp from any to any port = smtp \ keep state (tcp.established 30) man 5 pf.conf for more details. -j -- "Asleep at the switch? I wasn't asleep, I was drunk!" --The Simpsons
Re: First time user comments
On Thu, 2005-01-20 at 17:05, Peter Fraser wrote:
> The very broad: I don't understand why there is separate configuration
> files for bridges and routing and packet filtering.
routing and bridging are two separate things.
> Now for the picky ones.
>
> Could the "syntax error" message, give the position in the line that the
> error occurred, or at least the token that caused it. When you are a
> first time user you syntax errors are not obvious.
>
> I could find no where in the documentation that says what happens when
> you omit the "on " clause. The documentation implies that it
> must always be given, and grammar in "man pf.conf" shows it as being
> required, but several examples don't supply one.
the GRAMMAR section in pf.conf show this:
pf-rule= action [ ( "in" | "out" ) ]
[ "log" | "log-all" ] [ "quick" ]
[ "on" ifspec ] [ route ] [ af ] [ protospec ]
hosts [ filteropt-list ]
where "on ifspec" is in [] denoting that it's optional. in the intro
paragraph of the PARAMETERS section it also states "Most parameters are
optional." from the above--the only required parameters are "action"
and "hosts" making the simplest rule possibilities:
block all
pass all
> I believe that not
> supplying a "on " means the statement applies to all
> interfaces.
correct. just like not specifying in|out means the packet can match in
either direction.
> What needs to be quoted in a macro is not documented. One of my first
> mistakes was to write
> Internal_net = 192.168.200/24
> I could not find any documentation that said it had to be written as
> Internal_net = "192.168.200/24"
> with quotes. I also tried
> DebugLog = log
> and got a similar error.
i have never seen an example where the value of a macro was not quoted.
the exception to this is macros inside of macros, which is pointed out
in the MACROS section of the man page:
Macros are not expanded inside quotes.
For example,
ext_if = "kue0"
all_ifs = "{" $ext_if lo0 "}"
> I have several (actually three) segments, each of which have their own
> set of IP address. I wanted each segment to be only allowed to send in
> from IP addresses belonging to the segment, (and for good message stop
> the
> firewall from putting out packets onto a segment that they did not
> belong on). I expected an option on the antispoof directive to implement
> this effect, but it was not there so I wrote:
> InternalInterfaces = "{" ste1 ste2 ste3 "}"
> block in quick on $InternalInterfaces from !$id:network
> block out quick on $InternalInterfaces to !$id:network
> and was surprised to get "macro id is not defined". I believe the $id is
> only defined in certain contexts. Now I can get the same effect by
> writing the six statements which is what I did, but I was surprised.
um--that's what "antispoof" is for--source address verification inbound
on a given interface. as for your good measure(?) of blocking packets
outbound from the firewall...that's what the routing table is for...IMHO
i don't see the "good" in that measure(?).
as for pf not magically knowing what $id is supposed to mean; i'm not
sure why you think it would--also not sure why you'd be surprised that
it would tell you that the macro isn't defined, as you clearly didn't
define it. the macro $magic_miss_cleo_psychic_logic isn't defined
either--so it doesn't surprise me when my rules fail to load when i
reference it. computers do what you tell them to do--they're funny that
way.
<--snip dns resolving in rules comments-->
> It would be nice if there was a predefined macro for the unrouteable
> address.
all IP address are routeable, as IP is a routed protocol; unlike say,
NetBEUI for example... i could be so bold as to assume you mean the RFC
1918 address spaces reserved for private networks, but i would just be
assuming. maybe you mean the RFC 3330 special-use addresses, sans the
cable modem 24/8 network. maybe you mean all the network blocks listed
on http://www.iana.org/assignments/ipv4-address-space as
Reserved|Private Use|Returned. ah--but this list is a moving target
that can be modified at any time--last update was 02Aug2004, fyi... the
pf developers; much like the parsing engine, are not
mind-readers--firewalling is a personal thing: say what you mean and
mean what you say. how hard is it to define what *you* actually mean by
"unrouteable" in a template file that you create your firewall configs
from?
> It would be nice if there is only one interface type on the computer to
> define a macro automatically for them, I suggest $id0 $id1 etc. That way
> pf config files could be more portable, particularly in the case of a
> server machine that only has one interface.
not 100% sure what you mean here, but if you mean being able to refer to
hme0, hme1, hme2, hme3, and hme4 simply as hme--then it's already there.
> I could not find a documentat
Re: my firewall
On Wed, Jan 19, 2005 at 02:07:10PM -0700, R T wrote: > Hello folks. Thanks to everyone who responded to my problem. The laptop can > use the internet now, however it wont resolve host names properly. For > example, it wouldnt connect to www.google.ca but it would to 64.233.167.104 > Same for IRC, xhat wouldnt connect to eu.undernet.org but it would connect to > 195.68.221.221 ...wierd, huh? it sounds like you don't have the proper DNS servers set on your client machine. > Heres the pf.conf Im using: > === > # Gatewolf pf rules > # > ext_if = "xl0" > int_if = "ep1" > > nat on $ext_if from 192.168.1.2 to any -> ($ext_if) any reason you're only NAT-ing for a single IP? > block in log all > block out log all > > pass in quick on lo0 all > pass out quick on lo0 all > > pass in quick on $int_if from any to any > pass out quick on $int_if from any to any > > pass quick all you *do* realize that your firewall doesn't actually *firewall* anything, right? -j -- "Kids, you tried your best and you failed miserably. The lesson is, never try." --The Simpsons
Re: My firewall
On Wed, Jan 19, 2005 at 09:04:30AM -0700, R T wrote:
> Hello folks. Im trying to get my OpenBSD 3.5 machine set up as a router.
> Heres the info so far:
> xl0 network card getting dhcp address from my isp
> ep1 network card hooked to my laptop 192.168.1.1 netmask 255.255.255.0
>
> The laptop is windows and has 192.168.1.2 as its ip. I can ping the laptop,
> and the laptop can ping the OpenBSD box, but so far I cant get the laptop
> onto the internet at all. My pf.conf is quite simple compared to some
> examples I've seen and I'm thinking its too simple perhaps...#
> $OpenBSD: pf.conf,v 1.21 2003/09/02 20:38:44 david Exp $
> # gatewolf rules (experimental)
> #
> ext_if="xl0"
> int_if="ep1"
> internal_net="10.1.1.1/8"
> external_addr="192.168.1.1"
>
> # Filtering: the implicit first two rules are
> pass in all
> pass out all
>
> # block all incoming packets but allow ssh, pass all outgoing tcp and udp
> # connections and keep state, logging blocked packets.
> block in log all
> pass in on $ext_if proto tcp from any to $ext_if port 22 keep state
> pass out on $ext_if proto { tcp, udp } all keep state
>
> # pass incoming packets destined to the addresses given in table .
> pass in on $ext_if proto { tcp, udp } from any to port 80 keep state
>
> # My silly rules
> pass in on xl0 all
> pass out on xl0 all
> pass in on ep1 all
> pass out on ep1 all
>
> any ideas as to what I have done wrong folks?
> Thanks...
yeah--where's your:
nat on $ext_if from $int_if:network to any -> ($ext_if)
-j
Re: blcoking multiple connections
On Fri, Jan 14, 2005 at 08:51:57AM -0800, Bryan Irvine wrote: > Is there a way to limit people to only 1 or a few simultaneous connections? > Every morning the same IP makes about 100 simultaneous connections and > hogs all the resources until it's through. Is their a way to only > allow them 5? or 10, or whatever? might adding "max-src-states" to your rule do what you want? -j -- "I'll leave the world the same way I came into it - dirty, screaming and torn away from the woman I love." --The Simpsons
Re: Strange ? keep state behaviour
On Thu, 2005-01-06 at 16:48, Jason Murray wrote:
> Hello new to the list, but not exactly new to pf.
>
> I've got a 3 interface firewall and I'm seeing what I would call strange
> behaviour. Here is the scenario. I want to allow http in from the Internet
> to a web server on an isolated segment. I have a rdr rule set up and it
> works just fine (traffic flows when no filtering is being done).
>
> If I have a rule set like the following:
>
> block log all
> antispoof quick for { lo0 $uat_if $dev_if }
> # Allow web traffic to the UAT (marlin) box.
> pass in log quick on $ext_if proto tcp from any to $marlin port { 80, 443 }
> flags S/SA keep state
i *really* hope someone will smack me if i'm off-base here, because i'm
not sure i'm 100% clear on this...BUT...as *i* understand it, as soon as
you use "on $if" in a rule--the state that is created is if-bound even
if your state-policy is floating. so you either (a) create 2 rules, one
"pass in" for the inbound interface and one "pass out" for the outbound
interface, (b) create strict rules on the inbound interface and a single
lax rule on the outbound interface or (c) don't use the "on $if"
construct in your rules.
personally--i use (b) for internal->external rules and (a) for
external->internal rules. i always assumed that if i needed to build a
pf.conf to support an enormous number of states--i would use (c).
-j
--
"I'm having the best day of my life, and I owe it all to not going
to Church!"
--The Simpsons
Re: Use two nat's for an extra IP
On Sun, 2005-01-02 at 06:56, Daniel Johansson wrote: > Hi, my setup looks like the usual one. Internet -> router with openbsd 3.5 -> > switch -> hosts. > > I recently got a second IP from my ISP but I don't want to use it on an > external box directly to the internet. So I used ifconfig alias and added the > second IP tp my openbsd box. > > I just needed ssh, http and https to an internal box but with the new IP so I > used PF > and added this rule, 192.168.1.12 is the internal ip of the box I want to > forward the traffic. I also wanted all traffic from 192.168.1.12 to use the > new IP and not my old one. > > nat on $ext inet from 192.168.1.12/32 to any -> new_ip > > I already had this rule in my config: > > nat on $ext inet from ($int)/24 to any -> old_ip > > I then added my rdr-rules to the new box. It all seems to work perfectly but > what I would like to know if is this is a correct way of doing what I want to > do or is there any better or more correct solution? if it works the way you want, then no--i wouldn't say there's a "more correct" way to do it. if $new_ip is solely dedicated to 192.168.1.12; you could use "binat" instead of "nat" + "rdr" but that's really just a matter of preference. > Does it matter which one of my nat rules comes first in my config? yes. from man 5 pf.conf For each packet processed by the translator, the translation rules are evaluated in sequential order, from first to last. The first matching rule decides what action is taken. -j -- "Silly customer, you cannot hurt a Twinkie!" --The Simpsons
Re: CARP again, again
On Thu, 2004-12-23 at 17:28, ed wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello again, sorry to bother you all again. > > I have a question, we have two DSL connections, and I plan on using two > boxes, which are carped. But, I'd like to do this in a fashion such that > I can failover to a different connection when the primary one becomes > unusable. > > Would anyone have experience of doing this, and how exactly does one > determine that the connection has failed? Does it base the failure on > link status or on IP untouchables? well--setting 'net.inet.carp.preempt=1' will allow you to fail-over all interfaces on the primary if a single interface loses link. if you want to get fancier than that; i.e., pinging upstream hosts over each link--take a look at ifstated: DESCRIPTION The ifstated daemon runs commands in response to network state changes, which it determines by monitoring interface link state or running external tests. For example, it can be used with carp(4) to change running services or to ensure that carp(4) interfaces stay in sync, or with pf(4) to test server or link availability and modify translation or routing rules. the source is present in 3.6, but not compiled in the default system--have a look in: /usr/src/usr.sbin/ifstated for the bits. -j -- "Television! Teacher, mother, secret lover." --The Simpsons
Re: pf port knocking
On Fri, 2004-12-17 at 15:51, Peter GILMAN wrote: > Ed White <[EMAIL PROTECTED]> wrote: > > | On Friday 17 December 2004 15:45, Roy Morris wrote: > | > change your ssh port to like 30222 or something .. > | > | That's dumb. > > why? > > > Choose a port < 1024. > > why? not trying to speak for ed, but IMHO...it's dumb because any yahoo with a local account on a machine can create a listening socket on a port >= 1024. running a daemon on a port < 1024 requires privilege (thus the name)...sshd deserves the VIP treatment. if it doesn't conflict with an ssl httpd...443 is an awfully remote-side-firewall-friendly choice for an alternate sshd port... -j -- "I hope I didn't brain my damage." --The Simpsons
Re: missing something simple with rdr
On Thu, Dec 16, 2004 at 10:16:14AM -0500, Chad M Stewart wrote: > > I don't know what it was, but after a reboot things are redirecting as > they should. Now I just need to configure spamd to my liking. :) is it possible that you never did a "pfctl -e" -j -- "What's the point of going out, we're just going to end up back here anyway?" --The Simpsons
Re: missing something simple with rdr
On Thu, Dec 16, 2004 at 07:16:48AM -0500, Chad M Stewart wrote: > # pfctl -vv -f /etc/pf.conf > Loaded 345 passive OS fingerprints > table persist > table persist > @0 rdr inet proto tcp from any to any port = smtp -> 127.0.0.1 port 8025 > > # telnet localhost 8025 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 bia.com ESMTP hello world; Thu Dec 16 12:09:16 2004 > quit > 221 bia.com > Connection closed by foreign host. > > # telnet localhost 25 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 Chads AVS appliance > quit > 221 Bye > Connection closed by foreign host. have you tried telnet-ing to port 25 from a machine other than localhost? i could be mistaken, but i don't think your rdr rule will apply to a connection from localhost to localhost. -j -- "This has purple stuff inside - purple is a fruit." --The Simpsons
Re: two bridges on an etherchannel link
On Mon, 2004-12-13 at 11:24, Alain wrote: > Hi, > > I'm working on an high availability bridged firewall solution. > Would it be possible to put two openbsd bridged firewall on an > etherchannel link (between two cisco switch) and let the switch manage > the failover ? i don't think etherchannel is the technology you're looking for. i've seen setups where you put the two bridging firewalls in between two switches and allow spanning tree to handle fail-over if one of the firewalls dies. -j -- "It takes two to lie. One to lie and one to listen." --The Simpsons
Re: Internal IP Address Detection Through NAT
On Wed, 2004-12-08 at 14:34, messmate wrote: > >This is correct. Squid by default includes a "X-Forwarded-For: header > >on each HTTP request showing the original requesting IP address. This > >can be disabled in squid.conf with "forwarded_for off". > > > Sorry, not correct. I'm behind my squid and forwarded on or off the > header is there ! the X-Forwarded-For header is present whether you set the "forwarded_for" directive to "on" or "off"--the difference is that with it set to "off" the header reads: X-Forwarded-For: unknown\r\n which would rule it out as the source of the IP leak that the OP is asking about. you can also control what is shown in the Via header by setting the "visible_hostname" directive. again--ruling out squid as the source of the leak... oh--and if the "Via: " header bugs you: header_access Via deny all works without and recompile... as does: header_access X-Forwarded-For deny all -j -- "Oh, so they have internet on computers now!" --The Simpsons
Re: Note: states with asymmetric routing
On Wed, 2004-11-24 at 01:32, Ilya A. Kovalenko wrote: >Greetings, > > Just note. > > Stateful inspection on gateway can hamper tcp-connections, when > inbound or outbound packets goes another route (i.e. when one of > directions not goes thru gateway). > > Connection works fine on low rate, but fast transfers stops on > each 64K (because suddenly PF stops passing packets). > > I guess, it is not bug, just some feature (like some > tcp-window-related state protection). So think, is there reasons to > correct this PF behavior. > > Thank you > > Ilya A. Kovalenko stateful firewalls are built on the premise that the firewall is in-line between client and server; and therefore, sees all requests/replies. asymmetric routing violates that premise; and therefore, all bets are off. if you *_must_* do this--allow states to be created on non-SYN packets (note: this is an *awful* idea). i will assume that you do not have delusions that this should work with NAT-ed connections, because it most certainly will not. -j -- "Another day, another box of stolen pens." --The Simpsons
Re: SSH from admin machine
[EMAIL PROTECTED] wrote: On Sun, 7 Nov 2004, messmate wrote: Hi all, i've a problem to ftp from my admin machine to the router/firewall/proxy. This rule seems not correct :( #Autorise SSH from admin machine pass in quick on $internal proto tcp from $TRUST_IP to any port = 22 flags S keep state #seemms a syntax error ?? remove the = sign pass in quick on $internal proto tcp from $TRUST_IP to any port 22 What did i wrong ? and decide whether you mean FTP or SSH. -j
Re: port 6881
On Sat, 2004-10-30 at 16:20, messmate wrote: > Hi list, > as a newbie i've installed pf and closed everything. > But i have to open port 6881 TCP/UDP to get > azureus ( torrent) working. > For one machine on this internal network. > How can i do that ? > Sorry for this ignorance > mess-mate mmm...bittorrent... rdr pass on $ext_if proto tcp from any to $ext_if port 6881 -> $inside_host port 6881 -j -- "Well, I'm tired of being a wannabe league bowler. I wanna be a league bowler!" --The Simpsons
Re: Help with NAT rules
On Wed, Oct 27, 2004 at 04:21:36PM -0400, Lester wrote: > Hi all > New to Open BSD and PF > > Trying to set up nat for a 10.x.x.x/24 public 1.2.3.4 > Below is my rule set for NAT only > I am enabling PF for nat only .. pfctl -eN > however it is not working , > I get no results with pfctl -s state > pfctl -s nat does show the rule set correctly > TCP dump on the xl1 shows that the interface is receiving traffic ... > what I am I missing > > Thanks for any insight did you enable IP Forwarding: sysctl -w net.inet.ip.forwarding=1 see /etc/sysctl.conf for preserving this across reboots. -j -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ The water was not fit to drink. To make it palatable, we had to add whiskey. By diligent effort, I learned to like it. -- Winston Churchill =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: Layer2 Filtering
On Wed, 2004-10-20 at 18:59, eric wrote: > What's the method by which you folks filter layer 2 traffic? Some of > my methods don't scale well (static arp entries, etc) and was > curious to know if there was working being conducted in this area > for pf, or any other BSD licensed goodies. man 8 brconfig check out the examples on creating rules. especially nifty is the ability to tag packets at the bridge level and utilize those tags in your PF rules. dunno if this qualifies as "scalable" though... maybe the "rulefile" ability adds scalability. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Drinking coffee for instant relaxation? That's like drinking alcohol for instant motor skills. -- Marc Price =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: Carp & Ftp-proxy address translation
On Sun, Oct 17, 2004 at 08:21:56PM -0700, Yuri wrote: > Heyo > > I have a failover firewall setup with 2 boxes using CARP. Everything > works ok, but i have a question about ftp-proxy... > > Box #1 has external ip: 100.100.100.2 and internal ip: 10.0.0.2 > Box #2 has external ip: 100.100.100.3 and internal ip: 10.0.0.3 > They both share external CARP address 100.100.100.1 and internal CARP: > 10.0.0.1 > > All requests that come from internal network, go out on CARP address so > from outside you see that all requests are coming from 100.100.100.1: > nat on $ext_if from $internal_net to any -> $external_carp > > All active ftp requests that use ftp-proxy are taken care of by this: > 1) rdr on $carp_int proto tcp from any to any port 21 -> 127.0.0.1 port > 8021 > 2) pass in on $ext_if inet proto tcp from any to $carp_ext user proxy > keep state > > But when i do that, the ftp requests are coming from Box's #1 external > interface ( 100.100.100.2) and not the CARP address ( 100.100.100.1 ), > and when the second box takes over they're coming from 100.100.100.3 > > Is there any ways i can force all the outgoing active ftp requests come > from CARP address (100.100.100.1) instead? If so, what changes to i need > to make in pf/carp/ftp-proxy setup...? man 8 ftp-proxy says: -a address Specify the local IP address to use in bind(2) as the source for connections made by ftp-proxy when connecting to destination FTP servers. -j -- Jason Opperisano <[EMAIL PROTECTED]>
Re: Application Layer Tagging
On Tue, Oct 12, 2004 at 03:38:49PM -0700, Jon Simola wrote: > I've searched a fair bit and started some research into the pf code > looking for a way to identify packets at the application layer. > I believe that the functionality (just some simple text searching > inside the packet payload) would have to be inserted inside > pf_test_tcp() using a functional block similar to pf_osfp_match(). > > What I'm trying to do, exactly, is identify and tag P2P streams based > on signatures so that they can be sent to a lower-priority queue or > blocked. Given that the newer P2P protocols are no longer using static > ports and I have a requirement to constrain undesirable bandwidth > usage by my users, I've started looking at this as a possibility. > > Has there been any other work done in this direction with PF, or am I > forging my own trail, so to speak? i think daniel summarizes the view on this quite well in: http://marc.theaimsgroup.com/?l=openbsd-pf&m=108846519101164&w=2 -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Booze is the answer. I don't remember the question. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: rdr with tagging
On Mon, 2004-10-11 at 14:49, Andy Wettstein wrote: > So I wonder if I can use the tagged keyword with rdr, and if I can't > what are the alternatives? as people authenticate, add them to a table; i.e. AUTH, and redirect people not in that table to the auth page: rdr on $wireless_if proto tcp from ! to any \ port www -> ($wireless_if) -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Drinking is not a spectator sport. -- Jim Brosnan =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
RE: Trouble using route-to
On Fri, 2004-10-08 at 17:41, Ben wrote: > Great, thanks! So the hostname.* file would look like (for example) > > dhcp NONE NONE NONE > !-s route add 128.195.0.0/16 128.195.88.1 > > > Ben heh, no... that was an attempt to make an exclamation point plural... man 5 hostname.if you would use: !route add 128.195.0.0/16 128.195.88.1 -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ There are only two kinds of tequila. Good and better. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: pfctl and macro expansion
On Fri, 2004-10-08 at 08:08, Ben Hughes wrote:
> Hello,
>
> I'm having some grief with the macro parser of pf and wondering if
> I've either done something dumb or am expecting too much from it.
>
> I have, for the sake of simplicity the following ruleset:
>
> place1 = "10.0.0.1"
> place2 = "10.0.0.2"
> all_places = "{" $place1 $place2 "}"
> pass all
>
> That loads in to pf fine.
>
> however if I make the places be subnets, eg:
>
> place1 = "10.0.0.1/32"
> place2 = "10.0.0.2/32"
> all_places = "{" $place1 $place2 "}"
> pass all
>
> I get:
>
> openbsd# pfctl -n -f ./testpf.conf
> ./testpf.conf:3: syntax error
>
> It'd be really useful if I could expand macros with subnets in, save
> duplicating IP blocks all over the ruleset. Is this a bug with me of
> pfctl?
>
> Thanks.
this has been covered in the archives several times. you need extra
quotes, as in:
net1 = '"172.16.0.0/12"'
net2 = '"192.168.0.0/16"'
net3 = '"10.0.0.0/8"'
rfc1918 = "{" $net1 $net2 $net3 "}"
block from $rfc1918
-j
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
The Celts invented two things, Whiskey and self-destruction.
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: Stalled connections [LONG]
On Thu, 2004-09-30 at 04:55, Martin Lexa wrote: > # Normalization: reassemble fragments and resolve or reduce traffic > ambiguities.# scrub in all > scrub in on $ext_if all no-df > scrub out on $ext_if all no-df random-id max-mss 1440 > scrub in on enc0 all no-df > scrub out on enc0 all no-df > scrub in on $int_if all no-df > scrub out on $int_if all no-df random-id have you tried lower max-mss values than 1440? you're cutting it pretty close there (1500 - 20 - 40). i know it makes mathematical sense in theory; but in reality, i've always had to ratchet my WiFi over IPSec traffic down to an MTU of 1350-1370 (MSS of 1310-1330) to eliminate "stalls." just a thought. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ These days the necessities of life cost you about three times what they used to, and half the time they aren't even fit to drink. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: Carp address !as source IP
On Thu, 2004-09-16 at 08:58, Steven S. wrote: > Greetings, > > I'm experiencing an interesting problem and I'm googled out. > > Trying to get mail from a firewall which is the carp master to an internally > hosted e-mail server. The mail server is using a private IP address and the > firewall is using a "binat" rule to translate a public carp IP to the > private mail server ip. When the firewall tries to send mail to the mail > server the firewall uses the carp address as the source address. > > Here's some relevant info, > > /etc/pf.conf: > .. > email_pub="1.1.1.180/32" > email_pri="10.0.1.50/32" > .. > binat from $email_pri to any -> $email_pub > .. > Pass this and that... > > [EMAIL PROTECTED] [~]# telnet 1.1.1.180 port 25 > In another window... > [EMAIL PROTECTED] [~]# tcpdump -n -i em3 port 25 > tcpdump: listening on em3 > 21:25:07.753097 1.1.1.180.3944 > 10.0.1.50.25: S 672757334:672757334(0) win > 16384 > (DF) [tos 0x10] > 21:25:07.753349 10.0.1.50.25 > 1.1.1.180.3944: S 634049029:634049029(0) ack > 672757335 win 17520 0,nop,nop,sackOK> (DF) > 21:25:07.753376 1.1.1.180.3944 > 10.0.1.50.25: R 672757335:672757335(0) win > 0 (DF) > ^C the above seems to be the result of a blocked packet with "set block-policy return" or a "block return ..." rule ...SYN goes out but SYN-ACK coming back in gets a RST... > My only thought is to try rdr and nat instead of binat, but binat seems > cleaner to me. Any thoughts? my only thought would be to "telnet 10.0.1.50 25"... NAT is for machines outside the firewall that don't know any better. the firewall knows better. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ God is a comic playing to an audience that's afraid to laugh. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: blocking gnutella
On Tue, 2004-09-14 at 15:33, Bryan Irvine wrote:
> I can't seem to get gnutella to break.
>
> gnutella = "{" 6346 6348 8436 "}"
> block out quick proto { udp tcp } from any to any port $gnutella
> block in quick proto { udp tcp } from any to any port $gnutella
>
> pftop still shows connection on 6346 though, ideas?
>
> --Bryan
pftop still shows new connections being established or still shows old
connections that were established before you implemented the new rules
and didn't flush the state table or kill the individual states?
-j
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
It has been said that Public Relations is the art of winning friends and
getting people under the influence. -- Jeremy Tunstall
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: PF without NAT : filtering, but leaving IP address the same
On Fri, 2004-09-10 at 00:02, Miles Keaton wrote: > All the PF examples and even Jacek's book seem to assume you want to > do NAT : the small-office setup : the one public IP and many > 192.168.0.__ IPs inside. > > But how would PF be used as a router with many incoming IP addresses > and many receiving IP addresses? > > Say I have incoming: from 123.45.67.80 to 123.45.67.89 on a T1 connection. > > One OpenBSD/PF machine is receiving that input on a single NIC card, > and wants to send out some traffic on another NIC card connected to a > switch like this: > > incoming 123.45.67.81 allow port 22,80,443 to go to internal 123.45.67.81 > incoming 123.45.67.82 allow port 22 to go to internal 123.45.67.82 > incoming 123.45.67.83 allow port 22,25,110 to go to internal 123.45.67.83 > > Can PF do this kind of filter-and-route without doing NAT? > If so, any URLs of examples? I can only find examples with NAT. > > Thanks! i'm probably totally missing the point of your post, but here goes: read all that same info and ignore the nat, rdr, and binat statements. pf's filtering does not rely on nat in any way, shape or form. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ We don't smoke and we don't chew, and we don't go with girls that do. -- Walter Summers =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: perceived strange behavior
On Fri, 2004-09-10 at 03:11, Ryan McBride wrote: > 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. yes--precisely. the OP on "other firewall mailing list" was essentially asking for pf's sticky-address feature. forgot where i was posting there for second... -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ I hate it when my foot falls asleep during the day cause that means it's going to be up all night. -- Steven Wright =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: perceived strange behavior
On Thu, 2004-09-09 at 19:49, Nick Buraglio wrote: > I built an openbsd firewall for a group of people that I do some > consulting for from time to time to go in an apartment building that > serves about 150 - 175 college students. Overall the machine is doing a > stellar job doing NAT as well as some basic priq QoS. The box is > running vanilla 3.5, no custom kernel yet, no over the top hardware. > Specs are p4 2.4ghz(I believe) intel mobo, rl chipset ethernet card and > onboard fxp chipset card. > I'm seeing some strange behavior in one service though and I cannot > seem to figure out why. Everything is working, as I said, except some > users are unable to use AIM. Unfortunately I was unable to get any > tcpdump information before they took the box offline, but from > descriptions of the helpdesk people it only affects some people and I > can find no pattern as to who. Has anyone seen similar behavior or am > I looking in the wrong place. I saw no one else having similar issues > when checking through the archives, and I know that probably the only > way to tell is to get some traces from a user having issues, but I > figured I'd ask. > I can provide as much information as needed if anyone wants it. If > not, thanks for reading. there was just a discussion about this on another mailing list. by chance are you using multiple IP's for outbound NAT? it seems that AOL has changed it's login process such that the client makes multiple connections, and if the IP the client is coming from changes during this process--the "connection" fails. i just tcpdumped a login and i saw three connections: 1) AIM sign-on server (64.12.161.185) 2) AIM Generic Service server (64.12.24.65) 3) AOL Instant Messenger server (205.188.176.90) 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. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ There are two problems with a major hangover. You feel like you are going to die and you're afraid that you won't. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: rdr rule
On Thu, 2004-09-09 at 18:21, Bryan Irvine wrote:
> anyone know why this rule doesn't work?
>
> I've read and re-read the pf users guide but this specific example
> isn't covered.
>
> ftpservers = "{" ftp.kingcountyjournal.com intranet,kingcountyjournal.com "}"
^
'cause of the comma? |
> rdr on $LANS proto tcp from any to ! $ftpservers port ftp ->
> $localhost port ftp-proxy
>
>
> --Bryan
-j
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
If God had wanted us to be concerned for the plight of the toads, he
would have made them cute and furry. -- Dave Barry
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: preventing dos attacks with pf
On Thu, 2004-09-02 at 10:16, Wolfgang Pichler wrote: > hi all, > > 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 ? > > Thanks > > regards, > Wolfgang man 5 pf.conf read the section titled "STATEFUL TRACKING OPTIONS" you appear to be asking for the functionality of: max-src-states Limits the maximum number of simultaneous state entries that a single source address can create with this rule. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Time is an illusion, lunchtime doubly so. -- The Hitchhiker's Guide to the Galaxy =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: pf same rule passes some, blocks some?
On Tue, 2004-08-31 at 19:31, cmustard wrote: > > are those the complete log entries? my log entries look more like > - no, i truncated, I was running tcpdump -neq -ttt -r /var/log/pflog > they were the 'standard/normal' entries: > Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.74.50.80 > > 192.168.x.xxx.61265: P 4294966553:0(743) ack 1 win 5792 (DF) > Aug 31 01:20:15.287341 rule 1/0(match): block in on rl0: 69.42.xx.xx.80 > > 192.168.xx.x1.61265: P 4294966553:0(743) ack 1 win 5792 (DF) > etc,... > > > > > rule 0/0(match): block out on hme1: 10.1.1.15.139 > 10.1.2.16.32962: R > > 8:8(0) ack 1 win 58410 (DF) > > > > the reason i ask, is because all your rules use "flags S/SA" and "keep > > state" which; in the normal course of operation, create a lot of log > > entries where the flags are RST-ACK, FIN-ACK, etc... they are just > > trailing packets that arrive after the state entry has been removed... > > > -hmmm, so your saying just because I see a rule being matched it doesnt' > mean a packet is being blocked. it may be matching flags S/SA but is > still passing in to the interface, cool, I haden't thought of that, > thanks. > that's what I get using rules I don't really understand yet,... :) actually, what i was saying is: when you use "flags S/SA keep state" *only* a packet with the SYN bit (out of SYN, ACK) can match the rule and create a state. those states are also interface-bound (if you specify an interface), and once that state is removed, any packets lagging behind the closing of that connection will be blocked by your default rule because they don't match anything else and have no state associated with them. generally, these will be FIN-ACK, RST-ACK, or PSH-ACK packets. here's the rules i try to follow with respect keeping state, either: don't specify interfaces when keeping state, or only keep state on one interface (usually the external) -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ If God had intended Man to Smoke, He would have set him on Fire. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: A Firewall and Routing Question
On Mon, 2004-08-30 at 12:46, [EMAIL PROTECTED] wrote: > Hi, > > I have tried to set up a firewall with BSD (3.5). > I experimented with filtering bridge, so far ok. Now I needed a DMZ, so > I didn't want to play with two PCs, all should be in one PC. I > understand, I'd have to use a firewall with three interface cards. > Meanwhile I have read the book from Jacek Artymiak (second edition), and > I have looked into the mailing lists ... But: I have problems to > understand routing. > Which routes do I need to setup in this straight forward example ? all you need is a default route pointing to your internet router's IP address (attached to xl0). the openbsd gateway is directly attached to the networks on xl1 and xl2 and will automatically know how to get to those networks. the output of: $ netstat -rn -f inet should confirm this. > INTERNET > | > | > - > |xl0| -- > | | |DMZ | > | xl1 |---|| > | | | Mail & WWW | > |xl2| -- > - > | > | >LAN > > On top is the Internet, on the right hand side my DMZ (actually with a > WWW and a Mail server). Below is my local area LAN. I would like to > setup the firewall with PF and NAT. I have three network cards (3COM > PCI), which are configured as xl0, xl1 and xl2, lets assume I have these > IP adresses: > > ext-if: x.x.x.x (xl0) > dmz-if: 192.168.255.250 (xl1) > Mailserver: 192.168.255.1 > Webserver: 192.168.255.2 > int-if: 192.168.0.250 (xl2) > > I would store these informations in the corresponding interface.xl? > files. > In /etc/mygate on the firewall I would put the xl0 interface address > (would that be also my default route ?). um, no. in /etc/mygate you need to put the IP address of the upstream router that connects you to the internet > All clients in the LAN shall > have XL2's interface adress as gateway. yes. > Routing: > Everything shall leave the firewall via ext-if (xl0) by default. > Assume, I have no PF activated (but net.inet.ip.forwarding=1), then I > would have to tell packets from the LAN, that the www and mailserver are > in a different LAN. And for their different subnet I'd need a routing > entry. yes--but it's already there for you once the interface is configured with an IP address. > When the mailserver sends his mails to the internet, his gateway adress > would be that of dmz-if (xl1), same applies for the WWW server. If > traffic comes from DMZ, it would leave over the default gateway ext-if > (xl0). yes. > If traffic from both DMZ servers is destinated into the LAN, I would > think I need a corresponding routing entry to pass via int-if. no. again--this will be automatic, as the internal LAN is directly connected. > If I set up PF now, with rules in pf.conf, do I need to delete these > routes ? not quite sure what you mean by this, but i'm going to say the answer is 'no.' -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ I am two with nature. -- Woody Allen =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: pf same rule passes some, blocks some?
On Mon, 2004-08-30 at 14:18, cmustard wrote: > rule 1/0(match) block in on rl0: 84.2x.xxx.xx > 192.168.3.2.6346: tcp 0 (DF) > rule 1/0(match) block in on rl0: 224.2x.xxx.xx > 192.168.3.2.6346: tcp 0 (DF) > to me, this rule says it's blocking traffic on my external interface that is > comming from any (internet) and bound for my dmz interface. are those the complete log entries? my log entries look more like (produced with "tcpdump -netttr /var/log/pflog"): rule 0/0(match): block out on hme1: 10.1.1.15.139 > 10.1.2.16.32962: R 8:8(0) ack 1 win 58410 (DF) the reason i ask, is because all your rules use "flags S/SA" and "keep state" which; in the normal course of operation, create a lot of log entries where the flags are RST-ACK, FIN-ACK, etc... they are just trailing packets that arrive after the state entry has been removed... -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ I was at this restaurant. The sign said "Breakfast Anytime." So I ordered French Toast in the Rennaissance. -- Steven Wright =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: TODO: pass unidir. TCP connections
On Thu, 2004-08-19 at 06:51, Ilya A. Kovalenko wrote: >Good day, > > I trying to pass any outgoing TCP connections from my > office () onto campus network () sites, > but block any incoming connections from campus to office. > > Can use for it, PF ruleset like this (on 2-ifaced GW > between office & campus): > > > blockinall > > block return-rst in proto tcp all > > > > pass in on lo0 all > > > > pass in from to > > pass in from to > > pass in from to > > > > pass in proto tcp from to keep state > > > I suppose to think, that last rule would create state for > outgoing connection and pass all campus packets for it. > But it seems to does not work ... or I missed some other > factors. > Should it work ? > > Previously, I've used construction like this > > > pass in proto tcp from to > > block in proto tcp from to flags S/SA > > but it has security issue - public host could send spoofed > TCP packet, on which, internal host responds with RST. > So public host could perform ping-scan (by nmap, for example) > for internal network. if that's your concern--do some anti-spoofing (there's actually a shortcut version of this in 3.5, but it's just as easy to do it manually): block in all block return-rst in proto tcp all block in quick on ! $private_if from [ ... rest of rules ... ] -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Drunks are rarely amusing unless they know some good songs and lose a lot a poker. -- Karyl Roosevelt =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: route-to problem; traffic remains on the default link
On Fri, 2004-08-13 at 04:18, Paul Cusbish wrote: > My problem is with route-to. It seems to have no effect in my case. For the > record, I don't have any nat rules on this link - My suspicion is that the nat'd > link is "grabbing" the packet bound for the route-to gateway, but i'm probably wrong. while it seems unrelated to the question at hand--if you don't have an outbound NAT for traffic exiting this interface, how is this supposed to work? is your LAN addressed with publicly-routed IP's? > my route-to line is as follows: > > pass in quick on xl0 route-to ($adsl_if $adsl_nexthop) inet proto tcp from > $workstation to any port 25 keep state > I can attach more rules if needed i think that would be beneficial. -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Faster, faster, you fool, you fool! -- Bill Cosby =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: DHCP pf and bridges
> Hello There, > I'm a complete newbie to OpenBSD - a veteran from FreeBSD attracted by > the green grass of pf for a new firewall. Here's the rub - simple setup > with nic connected to internet, nic connected to subnet, wireless card > bridged to internal subnet. Dhcpd is running, working fine, handing out > licenses on the internal ethernet - but no licenses on the wlan. If I > manually configure a machine on the wireless lan - all is fine...also I > can't ping from one side of the bridge to the other - but both sides > reach the internet and router fine. Attached is a messy (well hacked) > pf.conf i'm not an expert on this--but i've seen it posted multiple times on openbsd-misc that your cannot bridge with a wireless nic. you're going to have to subnet wireless & wired networks and route between them. http://marc.theaimsgroup.com/?l=openbsd-misc&m=109170776211283&w=2 http://marc.theaimsgroup.com/?l=openbsd-misc&m=108558996927905&w=2 -j
Re: load balncing and default to block
On Sat, 2004-08-07 at 02:38, Reza Muhammad wrote:
> ash-2.05b# pfctl -s rules
> scrub in all fragment reassemble
> block drop log all
> pass in on xl0 route-to { (rl0 202.x.x.1), (rl1
> 202.x.x.169) } round-robin inet proto tcp from
> 172.16.0.0/16 to any flags S/SA modulate state
> pass in on xl0 route-to { (rl0 202.x.x.1), (rl1
> 202.x.x.169) } round-robin inet proto udp from
> 172.16.0.0/16 to any keep state
> pass in on xl0 route-to { (rl0 202.x.x.1), (rl1
> 202.x.x.169) } round-robin inet proto icmp from
> 172.16.0.0/16 to any keep state
this may be a stupid question, but do you have rl0 and rl1 configured to
be on the same subnet? i.e., is the prefix length of 202.x.x.0 a /24?
if so--that's your problem. either subnet that network down so that rl0
& rl0's gw are on one subnet, and rl1 & rl1's gw are on a different
subnet (i.e. 202.x.x.0/25 and 202.x.x.128/25). another possibility
would be to leave everything on the same subnet, and bridge rl0 and rl1
together and just assign one IP address to the bridge interface.
-j
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
PLEASE DON'T SMOKE HERE! Penalty: An early, lingering death from cancer,
emphysema, or other smoking-caused ailment.
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
RE: NAT with two external interfaces
On Sat, 2004-07-31 at 21:55, Coda Hale wrote: > # nat on both interfaces from internal > nat on $adsl_if from $int_if to any -> ($adsl_if) > nat on $sdsl_if from $int_if to any -> ($sdsl_if) in the above, $int_if expands to the IP address of your internal interface. my guess is you want the network definition: nat on $adsl_if from $int_if:network to any -> ($adsl_if) nat on $sdsl_if from $int_if:network to any -> ($sdsl_if) -j =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ I had no shoes and I pitied myself. Then I met a man who had no feet, so I took his shoes. -- Dave Barry =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Re: PF "$if:network" syntax with more than one interface IP.
$if:network:0 will only grab the network for the primary address; ignoring aliases. not sure if there's a way to grab a specific alias through some other syntax. -j On Mon, 2004-07-05 at 14:29, 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 > > > 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. > > > > Thanks > Per-Olov -- Jason Opperisano <[EMAIL PROTECTED]>
Re: What am I missing? (4-leg setup)
the "teach a man to fish" response here is: change your 'block all'
line to 'block log all' and then 'tcpdump -n -e -ttt -i pflog0' and see
what's getting blocked.
the "give a man a fish" response would involve something along the lines
of (possibly amongst other things):
pass in on $sec_if from $wi_net tag WI_INET keep state
as an unrelated tip, you could also exploit the super-handy
'$if:network' syntax to avoid creating macros for your networks...
HTH...
-j
On Fri, 2004-07-02 at 22:15, RZR wrote:
> Following the directions from
> http://openbsd.sfobug.org/faq/pf/tagging.html, plus a little tweaking to
> include access for ipsec laptops on $wi_if (isakmpd on firewall), I came
> up with this.
> However, ALL access becomes blocked; namely
> -access from the firewall out
> -access to the firewall from the ipsec laptops
> -access to DMZ boxes from the ipsec laptops.
>
> I know I'm missing something (hopefully small).
>
> Any help would be much appreciated.
> -RZR
>
> pf.conf ->
> # macros
> int_if = "fxp0"
> wi_if = "fxp1"
> dmz_if = "sk0"
> sec_if = "enc0"
> ext_if = "tun0"
> int_net = "192.168.1.0/24"
> wi_net = "192.168.2.0/24"
> dmz_net = "172.16.1.0/24"
> www_server = "172.16.1.2"
> mail_server = "172.16.1.3"
>
> table persist file "/etc/spammers"
> set loginterface $ext_if
>
> ### AltQueue
> altq on $ext_if priq bandwidth 100Kb queue { q_pri, q_def }
> queue q_pri priority 7
> queue q_def priority 1 priq(default)
>
> ##
> # classification -- classify packets based on the defined firewall
> # policy.
> #rdr on $ext_if proto tcp from to port smtp \
> # tag SPAMD -> 127.0.0.1 port 8025
> rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
> rdr on $sec_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
> #rdr on $DMZ_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
> rdr on $ext_if proto tcp from any to $ext_if port 22 \
> -> $mail_server port 22
> rdr on $ext_if proto tcp from any to $ext_if port 25 \
> -> $mail_server port 25
> rdr on $ext_if proto tcp from any to $ext_if port 80 \
> -> $www_server port 80
> rdr on $ext_if proto tcp from any to $ext_if port 443 \
> -> $www_server port 443
> nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)
>
> block all
> pass in on $int_if from $int_net tag LAN_INET keep state
> pass in on $wi_if from $wi_net tag WI_INET keep state
> pass in on $int_if from $int_net to $dmz_net tag LAN_DMZ keep state
> pass in on $wi_if from $wi_net to $dmz_net tag WI_DMZ keep state
> pass in on $ext_if proto tcp to $www_server port {www, https} \
> tag INET_DMZ keep state
> pass in on $ext_if proto tcp to $mail_server port {ssh, smtp} \
> tag INET_DMZ keep state
>
>
> # policy enforcement -- pass/block based on the defined firewall policy.
> pass in quick on $ext_if tagged SPAMD keep state
> pass out quick on $ext_if tagged LAN_INET keep state queue(q_def, q_pri)
> pass out quick on $ext_if tagged WI_INET keep state queue(q_def, q_pri)
> pass out quick on $dmz_if tagged LAN_DMZ keep state
> pass out quick on $dmz_if tagged WI_DMZ keep state
> pass out quick on $dmz_if tagged INET_DMZ synproxy state queue(q_def,
> q_pri) label "$dstaddr:$dstport" queue(q_def, q_pri)
>
--
Jason Opperisano <[EMAIL PROTECTED]>
