Re: How not to ask questions + some resources (was: Re: IP Filter Documentation.)

[Karl O. Pinc]

On 05/05/2013 06:29:01 AM, Peter N. M. Hansteen wrote:

> First, in contast to at least some Unix-like systems, you can expect
> OpenBSD's man pages to be up to date, correct and relevant.

And, IMO, the OpenBSD man pages are some of the best
technical references anywhere, ever.  They are on-par
with the IBM 368-370 Assembly Language Reference Manual
from the 1970's.

Sadly well written reference material requires the
ability to read.  Information is not repeated and
anything missed or mis-understood when first read
will cause endless confusion.  Anyone not familiar
with the material must read with care, and re-read.
Those who do so will be rewarded with full understanding.

Alternately, a plethora of advice is available from
random strangers on the Internet

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: throttle traffic by amount of time or amount of used traffic in GB?

[Karl O. Pinc]

On 04/12/2013 04:11:47 PM, Sebastian Singer wrote:
> Hi Kirk,
> Hi Peter,
> 
> Thank you both for your quick and inspiring answers. I think I will
> first try setting up a table and continue with scripting around pfctl
> -vt tablename -T show as proposed by both of you.If I run into
> problems I will have a go at the solution with labels.

For a completely general solution you could try logging with pf
and scripting something with, say, swatch/pfctl that either 
changes tables or reloads anchors.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Best/simplest/fastest approach for creating "virtual switch" out of

[Karl O. Pinc]

Come to think of it you wouldn't need to frob
the arp tables since I presume the gateway is
all on the soekris.  And with proper dhcp
configuration you could just frob the gateway
address supplied to each access point.

On 03/18/2013 08:03:39 AM, Karl O. Pinc wrote:
> On 03/17/2013 07:47:43 PM, Karl O. Pinc wrote:
> 
> > Um, given these requirements, a physical switch would seem to be 
> > optimal.  (Of course this is the lazy way out, but
> > this way there's absolutely no danger of burning out
> > any precious brain cells from design-fatigue.  ;-)
> 
> Note that the above reply is a bit snarky.  If you want
> to avoid extra hardware there's surely a "best" way
> to do it.  I'm not paying enough attention to think
> what it might be.  Thinking out loud
> (my having forgotten your requirements) is to use
> a separate network for your access points.  You
> could deliver them dhcp, etc.  You could frob
> the soekris arp table so that the gateway IP
> address is reachable by all ports with access
> points plugged in.  (Something avoided
> by bridging?)  Then your pf rules would filter
> by network.  Of course you'd have to setup
> routing tables for the wireless networks
> and I can't remember if you're looking for handover
> to pass a roaming device from one to the next.
> 
> Perhaps not the most general solution.
> 
> All the same, spending the time to engineer
> something sounds like it might not be cost effective,
> interesting as it may be to find a way to do it
> "right".
> 
> 
> Karl 
> Free Software:  "You don't pay back, you pay forward."
>  -- Robert A. Heinlein
> 
> 




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Best/simplest/fastest approach for creating "virtual switch" out of

[Karl O. Pinc]

On 03/17/2013 07:47:43 PM, Karl O. Pinc wrote:

> Um, given these requirements, a physical switch would seem to be 
> optimal.  (Of course this is the lazy way out, but
> this way there's absolutely no danger of burning out
> any precious brain cells from design-fatigue.  ;-)

Note that the above reply is a bit snarky.  If you want
to avoid extra hardware there's surely a "best" way
to do it.  I'm not paying enough attention to think
what it might be.  Thinking out loud
(my having forgotten your requirements) is to use
a separate network for your access points.  You
could deliver them dhcp, etc.  You could frob
the soekris arp table so that the gateway IP
address is reachable by all ports with access
points plugged in.  (Something avoided
by bridging?)  Then your pf rules would filter
by network.  Of course you'd have to setup
routing tables for the wireless networks
and I can't remember if you're looking for handover
to pass a roaming device from one to the next.

Perhaps not the most general solution.

All the same, spending the time to engineer
something sounds like it might not be cost effective,
interesting as it may be to find a way to do it
"right".


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Best/simplest/fastest approach for creating "virtual switch" out of

[Karl O. Pinc]

On 03/16/2013 10:45:57 PM, Bonnie Packet wrote:
> The question is how best to create a "virtual switch" out of em2 and
> em3,

> I'd love some advice on what the "best" way to accomplish this is.
> ("Best" =
> in my particular case means first, lowest total firewall cpu cost to
> route/=
> filter; second, lowest PF ruleset complexity;  and third, lowest
> network tr=
> affic [ie, no packets going out ports that will just drop them
> anyways]. An=
> d I guess fourth, future lexibility in case I need to add a third or
> fouth =
> damn access point...)

Um, given these requirements, a physical switch would seem to be 
optimal.  (Of course this is the lazy way out, but
this way there's absolutely no danger of burning out
any precious brain cells from design-fatigue.  ;-)




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: forwarding loop

[Karl O. Pinc]

Thanks very much for the reply.

On 01/15/2013 01:25:50 PM, Daniel Hartmeier wrote:
> On Tue, Jan 15, 2013 at 09:46:37AM -0600, Karl O. Pinc wrote:
> 
> > Something that's not mentioned that
> > comes to mind is ICMP redirection.  (Without thinking
> > about it a lot it seems like it should be a good candidate.)
> > However when I tried ICMP redirection on OpenBSD
> > years ago I couldn't get it to work.  Never looked to see why, 
> > or whether it's been fixed since.  Or, I might have been doing 
> > something wrong.   If anyone can send a clue my way
> > I'd appreciate knowing more.
> 
> An ICMP redirect, if it is honored by a client, does not mean "if you
> want to talk to external-server, connect to proxy-on-local-network
> instead", but "if you want to reach external-server, route through
> next-hop-on-local-network".

Yes, when I tried it some time ago it was in the context of routing.

> 
> The difference is that the reaction will not change the destination
> IP address, but the destination MAC address. Its really the same as 
> if
> you added a temporary host route on the client.
> 
> The proxy will simply ignore the IP packet for a foreign IP address
> sent
> to its MAC address (like a default gateway that has IP forwarding
> disabled).

I was thinking that the way to use icmp redirects in a "reflection"
setting is to assign a second IP address to the webserver, the server's
public IP address, and, on the router use the internal address 
of the webserver as the gateway in a route statement designating
a route to the external address.  The router would then issue icmp
redirects and packets would be delivered from the lan to the webserver.
The webserver, having a second IP address, would respond.  However
I did not think the whole process through since you could
need additional foolery on the webserver to force it to send
all outbound packets from the LAN IP number -- or at least
that's something you'd always have to ensure.  

The advantage
is that 2nd IP numbers on interfaces and adding a route
are easy configuration changes to make.  The big disadvantage
is that you're messing around in the bottom part of the
network stack to solve a problem higher up in the stack,
and so it's a kludge that you don't want to hand over
to the random "next guy" who will maintain the network.

I always go for the split-horizon dns setup.  It's
obvious what's happening and there's only one place where
the functionality is maintained.

> 
> OpenBSD ignores ICMP redirects by default, you can enable it with
> sysctl
> net.inet.icmp.rediraccept, if you want to try. The security risk is
> that
> someone on the local network could send you ICMP redirects for 
> various
> destinations (like DNS server), for a man-in-the-middle attack.

FYI, FWIW.

I was not trying to get OpenBSD to respond to icmp redirects, but
to get it to issue icmp redirects.  I don't recall messing with a
sysctl, but I also don't see a security disadvantage in
a router issuing icmp redirects since that's what they're supposed
to do.  That does not mean there's not a sysctl I should have
frobbed, but I'd hope it'd be a different systcl from the one
involving responding to icmp redirects.  Looking at the
list of sysctls in sysctl(8) nothing jumps out.

Thanks again for the reply.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: forwarding loop

[Karl O. Pinc]

On 01/15/2013 04:10:33 AM, Daniel Hartmeier wrote:
> Wait, the squid server is on a separate host, on the $int_if side of
> the
> firewall (the same side the clients are on)?
> 
> Then transparent proxying would require "reflection", and doesn't
> work, see
> http://www.openbsd.org/faq/pf/rdr.html#reflect

Just read the FAQ and had a few thoughts.

Something that's not mentioned that
comes to mind is ICMP redirection.  (Without thinking
about it a lot it seems like it should be a good candidate.)
However when I tried ICMP redirection on OpenBSD
years ago I couldn't get it to work.  Never looked to see why, 
or whether it's been fixed since.  Or, I might have been doing 
something wrong.   If anyone can send a clue my way
I'd appreciate knowing more.

Another option for TCP proxying that's not mentioned
is socat.   It's like nc, but (I think) would not require
inetd.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Simultaneous CARP failover for multiple interfaces

[Karl O. Pinc]

On 04/23/2012 03:19:44 PM, Stuart Henderson wrote:
> On 2012/04/23 11:49, Kyle Lanclos wrote:
> > In order for our firewall to operate effectively, we use 'keep
> state'
> > pf rules. 

> 
> pfsync(4)'s "defer" option might help. there is a penalty but it 
> might
> be acceptable for your use case.

I didn't notice _any_ reference to pfsync in the original
post.  Perhaps this is part of the problem?



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: inbound queueing on external interface due to multiple internal interfaces

[Karl O. Pinc]

On 04/12/2012 07:40:47 AM, Stuart Henderson wrote:
> Yes, that thread is talking about creating multiple queues with the
> same name, this is good for traffic classification but it is not a
> single queue shared between multiple interfaces.

I am all wet then.  Isn't the first time.  Sorry to distract you.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: inbound queueing on external interface due to multiple internal interfaces

[Karl O. Pinc]

On 04/11/2012 08:02:41 AM, Andy Lemin wrote:
> Hello,
> I know this has been discussed before, 

You will want to see this thread:
Working example of bi-directional asymmetric ALTQ + NAT ruleset?
http://marc.info/?t=12947296581&r=1&w=2

It talks about being able to have a single queue
on more than one interface, so you'd use a single
outbound queue on all your internal interfaces to
effectively rate-limit your inbound wan traffic.
You'll want to use the hfsc scheduler because
you're trading bandwidth for latency.  And hfsc has
sub-queues too so that might help allocate the
traffic per internal interface.  I haven't thought 
about this in quite some time but I think that this approach
will work.  But because I've not thought about
it I could be all wrong.  :-)

It's not a perfect solution; it won't work in the
general case where you've more than one interface
you want to limit inbound traffic on.

If sharing a queue on your internal 
interfaces does not do it you could get ugly and
use an extra 2 real interfaces (instead of the loopback interface
as you suggest) and a separate routing table and physically
loop the traffic back.  This is less ugly than having another box.

I suspect the loopback interface approach won't work, but that's
a total guess.  If it does work I'm not sure I'd want
to count on such a kludge continuing to work long-term.

I'm very interested in what works and what doesn't so
it would be good to hear back from you.

> We have to use inbound queuing, without it our WAN link saturates 
> with
> low priority traffic, and we need to maintain headroom for high
> priority VoIP traffic etc.

Don't forget the "empty" ack packets.

> If we had to bounty this, how much? I might be able to get =A3100 for
> a
> bounty?

I heard the number $20,000 (US) thrown around.  I have no idea if
that's a realistic number.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: I want copy pf.conf from FreeBSD 8.2 to OpenBSD 5 and use it

[Karl O. Pinc]

On 11/02/2011 12:30:37 PM, Gholam Mostafa Faridi wrote:
> Hi
> In work place , we have over 24 computer and all of them are windows
> and 
> , I have NAT server . this NAT server use FreeBSD 8.2 AMD 64 , and I
> use 
> PF for NAT with FreeBSD 8.2 . after many search in google , I find
> this 
> pf.conf

Have you looked at the pf faq at www.openbsd.org or the man page,
especially the "Translation" section?

I seem to recall simple nat examples that you could use
once you change the IP numbers/networks to the ones you're
using.

I don't understand your english but it sounds like you may
want "match binat-to" to get a 1-to-1 mapping between internal
and external IP numbers -- either assigned per individual ip
number, or with "bitmask" or perhaps with some other natting
method and "sticky-address".

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Suggestion for a new feature, port code

[Karl O. Pinc]

On 02/28/2011 09:17:25 AM, Johan Söderberg wrote:
> A ridiculously simple idea.
> Protect your port, say ssh, by adding a code to access it.
> Ok, that's nothing new, but maybe how it's done.
> 
> For a client to connect to a service, it need to unlock the port with
> a code.
> The code is made of predefined blocked ports, that makes pf trigger.
> If the first code port is triggered, IP address enters a state with
> timestamp.
> If the next port that the address triggers, matches the next code 
> port
> within a timeframe, let it enter new state, else lose state.
> When all code ports have been triggered in the right order, allow
> address to pass.
> 
> Sure it's not safe from MITM, but it protects from scans, and allows
> you to connect from dynamic IP addresses.
> There are 65536 ports, that gives you 65536^n possible combinations
> where n is the number of ports in your code.
> So you probably won't need more than 2-3 ports in your code.
> 
> Say what you think! And if you like my brain fart, would you want to
> implement it?

Your idea is called port knocking, and it's pointless security by
obscurity -- and can be sniffed.  If you want it to be 
secure you make the knock code a
ome-time-pad.  In which case you may as well use skey for your
one-time-pad and be done with it.

If you want to "protect the port" redirect repeat offenders off
into a honeypot.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: binat-to address that's not assign to interface (4.9)

[Karl O. Pinc]

On 01/25/2011 01:30:45 PM, Brian Keefer wrote:
> I'm embarrassed to ask such a simple question.  Since 3.4 I've been
> running PF firewalls, but mostly for very small networks with 32 or
> fewer external addresses.  I always assigned my external IPs to my
> external interface and then did NAT or bi-NAT.
> 
> Now I'm building firewalls for much larger networks with /25 of
> external IPs.  They will all be either static or dynamic NAT, so
> proxy-ARP doesn't seem like the way to go.  Do I absolutely have to
> assign all these addresses to the external interface in order to use
> them for nat-to/binat-to, or can I simply have the upstream router 
> set
> a route to one IP that I assign to the external interface (this is
> done already) and PF will be able to handle the translations?

You should expect the ISP to route.  (On their DSL lines, at least
here, they often bridge, which is why you must fuss about with
ARP.)

Of course, it all depends on how the ISP does it.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Working example of bi-directional asymmetric ALTQ + NAT ruleset?

[Karl O. Pinc]

On 01/14/2011 04:48:48 AM, Stuart Henderson wrote:

> I'm not sure what the 3.9 docs said, this is what the current OS has
> to say about "queue...on" in pf.conf(5):
> 
>  on 
>Specifies the interface the queue operates on.  If not
> given, it
>operates on all matching interfaces.

That seems clear to me.

It's been years since I fiddled with my queuing setup.
I'm now motivated to revisit it.



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Working example of bi-directional asymmetric ALTQ + NAT ruleset?

[Karl O. Pinc]

On 01/11/2011 01:17:02 PM, Kyle Lanclos wrote:
> Karl O. Pinc wrote:
> > There are may proofs that throttling TCP works, starting
> > with the original paper (Van Jacoson) in 1988 through
> > to the many products today that _do_ manage to reserve enough
> > inbound bandwidth that, e.g., VOIP works reliably. 


> It is only effective for our situation if we deliberately sacrifice a
> fraction of our inbound bandwidth.

Right.  And this becomes especially problematic with low bandwidth
connections, or multiple priority levels that slice bandwidth
too thinly, where single datagrams of MTU size take significant
amounts of the available bandwidth.

(FYI, I found ECN to be even better than RED.)

In any case, yes, it can be made to work.  However if you
want to throttle both inbound and outbound I found it
easiest to use 2 boxes, one as a bridge, and have each
box queue in one direction.  (I could have just
done all the queuing on the bridge too.)  Note that this is
only necessary if you've more than 2 interfaces.
If there are only 2 then each can do outbound
queuing.  (As noted in the start of this thread,
there may be stateful firewalling issues.)  But 
as soon as one interface is "feeding"
2 others this is no longer a sane approach if you
want to have any sort of bandwidth sharing/overflow between
the two interfaces "fed".  (I hope I'm making sense
here.)

This is a shame; it'd
sure be nice if altq let you do both directions.
Perhaps this thread will push things in that direction.

I never got around to trying to loop an ethernet
cable back into another nic, and setting up 2 routing
tables, effectively pretending one box is 2 just to
get inbound and outbound queuing on a single piece
of hardware.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Working example of bi-directional asymmetric ALTQ + NAT ruleset?

[Karl O. Pinc]

On 01/11/2011 09:23:48 AM, Daniel Staal wrote:
> 
> On Tue, January 11, 2011 1:35 am, Bonnie Packet wrote:


> The problem with trying to throttle incoming bandwidth is that no
> matter
> what you do, you have already received the packets.  As long as your
> internal network is faster than the external network feeding it,
> throttling incoming is useless: you've got the packets, putting them
> on
> your internal network won't slow things down, and dropping them will
> only
> cause them to get retransmitted.  (And use up *more* of your
> already-scarce external connection.)

It is oft-repeated that you can't throttle inbound traffic, 
and while true in some special cases, not true in most
real-world use-cases.  

If all your traffic was UDP, then yes, your argument holds.
But most real-world traffic, especially that which is bulky,
is TCP -- which contains it's own throttling
mechanism to adjust to "downstream" changes in bandwidth.
So, the sender will slow down transmission if you drop
packets.

There are may proofs that throttling TCP works, starting
with the original paper (Van Jacoson) in 1988 through
to the many products today that _do_ manage to reserve enough
inbound bandwidth that, e.g., VOIP works reliably.  I once
promised on this list to setup a test environment and
re-prove it but have never gotten around to it and it
hardly seems worth bothering.

Exactly how well TCP throttling works and how
to best make it work in the real world is still
up for grabs, but it can be made "good enough".
It may or may be able to be made to work in the
future as there seem to be increasing problems with
'bufferbloat', where equipment manufacturers decide
to buffer TCP, which breaks TCP's congestion control
and introduces the very latency that throttling is
(usually) trying to eliminate.  Still, if you're willing 
to waste enough bandwidth they'll probably always be a way to
reserve a bit of unused inbound bandwidth for low-latency
needs.

Congestion Avoidance and Control. ∗. Van Jacobson†. Lawrence Berkeley 
Laboratory. Michael J. Karels‡. University of California at Berkeley. 
November, 1988
http://ee.lbl.gov/papers/congavoid.pdf

rfc1323
TCP Extensions for High Performance
http://tools.ietf.org/html/rfc1323

The criminal mastermind: bufferbloat!
http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-
mastermind-bufferbloat/

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Redirection - feeling utterly stupid

[Karl O. Pinc]

On 12/29/2010 03:06:27 PM, Johan Helsingius wrote:
> I am starting to despair at ever understanding pf redirection/NAT.
> 
> I have been trying to build a very simple redirection where
> a openbsd firewall running pf sits between the ADSL modem
> and a controller.
> 
> I have now simplified the pf config to this:
>  
> 
> ext_if = ¨rl0¨
> int_if = ¨xl2¨
> 
> controller = ¨172.24.44.89¨
> 
> set skip on lo
> 
> block log all
> 
> pass in log on $int_if
> pass out log on $int_if
> 
> pass log on $ext_if from $controller to any binat-to $ext_if:0
> pass log on $ext_if
> 
>  
> 
> but it still seems like there is no natting, as packets from the
> controller seem to go out with the internal, non-routable address,
> so no packets ever get back.

The rule in pf is that the last pass/block match wins, unless you
say otherwise with "quick".  So, your last two lines should be
either:

pass quick log on $ext_if from $controller to any binat-to $ext_if:0
pass log on $ext_if

or:

pass log on $ext_if
pass log on $ext_if from $controller to any binat-to $ext_if:0

However it's probably more clear to separate your filter rules
from your natting.  You use "match" to do your natting, which
is "sticky".

Put this at the top and get rid of the binat part of the
pass rule:

match on $ext_if from $controller to any binat-to $ext_if:0


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

PF doc oddity

[Karl O. Pinc]

Hi,

I'm wondering why pf.conf(5) has an example
scrub setting where the mtu is 1440 when
1460 would be the usual mtu for a 1500
byte IP datagram.

From OpenBSD 4.8:
-
 For example:

   match in all scrub (no-df max-mss 1440)
-

Is my brain just not clicking?

Thanks.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: pf, synproxy, max-src-conn, FIN_WAIT_2

[Karl O. Pinc]

On 10/25/2010 06:22:23 PM, Nerius Landys wrote:
> During the time when a large download is happening using wget, the
> pf state table will have "ESTABLISHED:ESTABLISHED".  If wget was in
> the
> process of performing a large download and I hit Ctrl+C (or kill it),
> the state table will have "TIME_WAIT:TIME_WAIT".  If wget 
> successfully
> finishes downloading something, I will see "FIN_WAIT_2:FIN_WAIT_2" in
> the state table.

>  What I
> _really_
> would like to do is limit the number of established and maybe broken
> connections per IP address, and I probably _don't_ want to count
> the "FIN_WAIT_2:FIN_WAIT_2" connections towards my max of 36. 

> Do you guys have any thoughts about this?  Based on my feeling that
> the OpenBSD community tends to always do things "the right way", I'm
> thinking that there is a reason why things are the way they are, but 
> I
> would like to know those reasons if possible. 

See RFC 793 section "3.3.  Sequence Numbers"
particularly the subsection titled "The TCP 
Quiet Time Concept".




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Use an specific ADSL depending on IP

[Karl O. Pinc]

On 12/30/2009 02:40:03 AM, Jordi Espasa Clofent wrote:
> > I'm not paying much attention to the rest of your
> > rules, but note that traffic
> > going out the internal interface is coming from the
> > Internet and so is _inbound_ traffic not outbound
> > traffic as the comment would indicate.  (You have other
> > inbound quick rules in your ruleset so you can't just
> > change out to in here and expect it to work.)
> 
> Ok Karl, thanks.
> I think I've a problem of missconception.
> 
> So, I understand that this schema
> 
> Internet ---bge1 --- bge0 --- LAN
> 
> means at least 4 traffic to bge0 ruleset point of view:

There is no bge0 point of view, there is only the point
of view of the kernel.
> 
> 1- Traffic from internet (coming from bge1): it's IN

In on bge1 (from Internet).
It may or may not get to bge0, if it does it's...

> 2- Traffic 1 to LAN: it's OUT

Out on bge0 (to LAN)

> 3- Traffic from LAN to bge0: it's IN

In on bge0 (from LAN).
It may or may not get to bge1, if it does it's...

> 4- Traffic from bge0 to bge1: it's OUT

Out on bge1 (to Internet)



Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Use an specific ADSL depending on IP

[Karl O. Pinc]

On 12/29/2009 11:16:29 AM, Jordi Espasa Clofent wrote:


> 
> # dept_a using their own ADSL to outbound
> pass out on $int_if route-to \
>  ($ext_if1 $ext_gw1) \
>  proto { tcp udp } from $dept_a to any keep state


> 2) Use an specific ADSL depending on IP. Doesn't work.

I'm not paying much attention to the rest of your
rules, but note that traffic
going out the internal interface is coming from the
Internet and so is _inbound_ traffic not outbound
traffic as the comment would indicate.  (You have other
inbound quick rules in your ruleset so you can't just 
change out to in here and expect it to work.)

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Restricting source with dDNS (dynamic DNS)

[Karl O. Pinc]

On 12/19/2009 06:06:30 AM, Peter N. M. Hansteen wrote:
> Alvaro Mantilla Gimenez  writes:
> 
> > It would be awesome if pf could implement some port knocking
> features in
> > next releases...maybe and associate daemon (like spamd with email
> > attempts delivers...or something like that). Do you think is it
> > possible?
> 
> The first hurdle in getting port knocking functionality into the base
> system or a port would be to demonstrate that the added complexity is
> worth it in a very practical sense.  
> 
> Basically it's just one more feature that would need to be 
> implemented
> in a sane way and be demonstrated to be useful enough to warrant
> inclusion.  I wouldn't want to rate the chance of success, but if you
> think you can do it, what's stopping you?

There is, for that matter, no particular reason to incorporate
the functionality into pf.  You could as easily write a
script/daemon that listens for port knocking and uses
pfctl to add allowed IPs to a table.

But the problem you face with port knocking is that it
is just another way of delivering authentication
information.  Anyone who's
sniffing the wire can sniff your port knocking as well.
You may as well be using telnet and sending passwords
in the clear.  Of course you could knock in a
pattern known by both sides that does not repeat,
in which case you may as well be using skey.  Or
you could cryptographically secure the knocking
pattern, in which case you may as well be using
public keys (or shared, depending) keys. 

Given this analysis it seems a difficult task
to come up with an advantage port knocking has
over existing authentication methods.  Even if
you're looking for security through obscurity
there are much more obscure methods, and ones
that defeat casual sniffing:  E.g.
uploading a picture to flicker containing
stegonography reveling from where, when
and on what port you plan to ssh in, with 
a daemon on the server that randomly browses
flicker while occasionally polling for
pictures containing hidden information.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Restricting source with dDNS (dynamic DNS)

[Karl O. Pinc]

On 12/18/2009 11:25:18 AM, Michiel van Baak wrote:
> You can go with the previously mentioned table +
> resolvingscriptcronjob,
> or you can not restrict access to ssh based on ip but disable root 
> ssh
> login and passwordauthentication, ask for public keys, and go with
> that.

And if you need access beyond that there's also 
one-time-passwords/skey.





Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Restricting source with dDNS (dynamic DNS)

[Karl O. Pinc]

On 12/18/2009 10:16:44 AM, Peter N. M. Hansteen wrote:
> Jim Flowers  writes:
> 
> > To lock down services (particularly ssh) as tightly as possible, I
> like to allow
> > administrative access to a firewall only from specific ip 
> addresses.

> > Unfortunately, some of the administrators are working from dynamic
> ip addresses
> > that change with some frequency.
> >
> > Is there a straightforward way to incorporate dynamic ip source
> addresses in the
> > pf ruleset?
> 
> I'd say this sounds like a situation where authpf could come in quite
> handy.  

How?  I thought authpf grants additional rights to those who
can ssh.  But he wants to restrict those allowed to ssh period.


Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Restricting source with dDNS (dynamic DNS)

[Karl O. Pinc]

On 12/18/2009 09:40:36 AM, Jim Flowers wrote:
> To lock down services (particularly ssh) as tightly as possible, I
> like to allow
> administrative access to a firewall only from specific ip addresses.
> 
> Unfortunately, some of the administrators are working from dynamic ip
> addresses
> that change with some frequency.
> 
> Is there a straightforward way to incorporate dynamic ip source
> addresses in the
> pf ruleset?

Yes.  Make a table with the dynamic source addresses.
Control access using that table.
Update the table with pfctl from a script that
runs periodically and does dns lookups. 




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Binat and if macro issue

[Karl O. Pinc]

Hi,

I may be missing something obvious, but I've
a problem with macros for interfaces and binat.

OpenBSD 4.4 stable

-
net_main_if = "vr1"
net_stndby_if = "vr2"
net_if = "{" $net_main_if $net_stndby_if "}"

binat on $net_if inet from $static_intwks_block1 \
   to any -> $static_pubwks_block1
-

When I do pfctl -s nat I see a binat only on vr1.
Changing the binat to nat and rdr I see nat and rdr
on both vr1 and vr2.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: pf configuration subleties

[Karl O. Pinc]

On 09/12/2009 03:50:54 PM, Daniel Malament wrote:

> 1) The big one is what I would call the 'double state problem'.  It 
> seems to me that the big disadvantage of a default-deny ruleset is
> that 
> because explicit pass rules are required on all interfaces, traffic 
> passing through the firewall machine needs state on all interfaces. 

...

> The most obvious benefit of a default-deny ruleset is that it saves
> you 
> if you make a block rule too narrow, or comment it out by accident or 
> something. 

The big benefit of default-deny is that you're sure you know what
traffic you are passing.

 But is there a way to have only one state per connection 
> with a default-deny ruleset?  And if not, does it ever actually
> matter, 
> or am I just being pedantic?

You have a choice.

set state-policy if-bound|floating

Whether it matters or not depends on your application.  It surely
can matter, e.g. with muti-homed hosts where replies may come in
an interface other than the one out which the request was sent.
OTOH if you're gatewaying multiple very different networks you may want 
things locked down tightly with state bound to the interfaces 
because there's no way such traffic should be allowed.

> 2) The other (shorter) question:
> If I want one of my internal networks to be able to access the
> internet, 
> but not be able to access my other internal networks, is

...

> better or worse in speed and resources than

I don't know.  My general rule is that unless performance is
really an issue it's a lot more important to write programs/
configurations in a way that people can read than it is to
write them so that they are executed optimally.  If nobody
can read the file then it's useless.

> table  { 0.0.0.0/0 !$int_net1 !$int_net2 }
> pass in on $int_net3 from any to 

At first glance, this won't work.  An address in
$int_net1 will match !$int_net2 and so will pass
and vice versa.  My brain is full right now so I
could be wrong but I am sure there are issues just
like this with ! to watch out for.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Initial TCP SYN packet dropped

[Karl O. Pinc]

Hi,

I'm using OpenBSD 4.4 as a firewall running pf.

When running a program (darcs) to sync to
a revision control repository there are
repeated http requests made.  I find that
after an indeterminate number, typically
50 to 250 such requests, the program
aborts with connection refused.

I did a tcpdump of both the inside (sis0)
interface and outside (sis1) interface and found
that the final tcp/http request consists
of a single SYN packet that is received
on the internal interface but not sent
out the external interface.  The firewall
is sending an ICMP unreachable to the client.

pfctl -s info shows that state-insert
increases by 1 every time I have the
problem.  The number of states is only
about 400 to 600, far below the 10,000
limit.  vmstat 1 seems to show free memory
the whole time.

netstat -s shows an increase of 1 in
"packets not forwardable".  And of course
there's an increase of 1 in both
"calls to icmp_error" and "destination unreachable".

Setting pfctl -x to misc or loud leaves
nothing in the log.  (I once messed with
the log, so it's remotely possible I've broken
something here.  But I don't think so.)

How can I find out more about what's going on?
If there's congestion on the outbound wire
shouldn't the SYN just be dropped so the
sending TCP stack (Linux/libcurl) can retry?

FWIW, I had queueing in my pf.conf but removed
it and there was no difference either way.

I can make the tcpdumps available to anyone
who wants them.  I'll post them somewhere public if
anybody asks.  (~700K each, gzipped)
I would prefer to send my pf.conf privately.

If this is not a pf issue please let me know
and I'll try the OpenBSD misc list.

Thanks.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: What's the progress of in-kernel proxy for pf NAT?

[Karl O. Pinc]

On 07/23/2009 05:52:38 AM, Henning Brauer wrote:

* hu st  [2009-07-23 12:35]:



> AFAIK pf has only a ftp-proxy anchor.

it has userland helpers for the most relevant protocols.


Is there a list of these anywhere?  ftp-proxy is the only
one that comes to mind, of those where the protocol is
stupid and utilizes multiple connections/ports.  Other
proxies, as for http, can be implemented entirely in
userspace.

I'm not sure but I believe that SIP is also bad this way.
Is there a SIP proxy?  Are there other "bad" protocols
that require things like anchor updates?

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Binat with exceptions

[Karl O. Pinc]

On 07/04/2009 04:59:21 AM, Falk Husemann wrote:

Hello all on the pf list,

for a really stupid german ISP I need to setup a binat with  
exceptions.



Thanks in advance for any suggestions.


You could take advantage of the fact that the first
matching translation rule ends the processing,
so put your exceptions first and then a general
catch-all.

Don't forget that because binats are processed
before nats and rdrs a binat rule will cause
ftp-proxy anchors to be ignored.  So use a nat together with an rdr
instead of binat for those ports that ftp-proxy
might use.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: rdr of ip range

[Karl O. Pinc]

On 06/19/2009 02:05:36 AM, giuliano wrote:

Hello,
I’m new to pf, so maybe the question is silly, but I’ve looked around  
and can’t find a clear answer (maybe I’m looking for the wrong  
terms…).


From pf.conf(5)

 rdr-rule   = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts  
")" ] ] ]

  [ "on" ifspec ] [ af ]
  [ protospec ] hosts [ "tag" string ] [ "tagged"  
string ]

  [ "->" ( redirhost | "{" redirhost-list "}" )
  [ portspec ] [ pooltype ] ]


 hosts  = "all" |
  "from" ( "any" | "no-route" | "urpf-failed" |  
"self" | host |
  "{" host-list "}" | "route" string ) [ port ] [  
os ]

  "to"   ( "any" | "no-route" | "self" | host |
  "{" host-list "}" | "route" string ) [ port ]



 host   = [ "!" ] ( address [ "/" mask-bits ] | "<" string  
">" )



FYI, when the traffic passes through the LAN it does not sound much
like a DMZ.

Can I do the same with pf without having one rdr rule for every DMZ’s  
host ?


Yes, if all the DMZ hosts use the same ports.

Do I have to setup an alias on the LAN connected interface for every  
IP on the networks 10.10.1-4.0/24 ?


Yes, unless the DMZ hosts all uses different pots.


Is there a better way to have a similar setup ?


Setup a VPN and route traffic normally?   Connect all the
networks to the gateway and use public IPs on the DMZ boxes?

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Group/negate tables and other objects

[Karl O. Pinc]

On 04/17/2009 09:25:22 AM, Helmut Schneider wrote:

Karl O. Pinc  wrote:

On 04/17/2009 04:10:35 AM, Helmut Schneider wrote:

Helmut Schneider  wrote:


can I group tables? Or specify something like

myNet1="192.168.0.0/24"
myNet2="192.168.1.0/24"
otherNet1="192.168.2.0/24"
otherNet2="192.168.3.0/24"

table  { $myNet1, $myNet2 }
table  { $otherNet1, $otherNet2 }
table  { ,  }

internet = ! { ,  }
internet = ! "{"   "}"
...

Purpose is to create an object called "internet" which excludes  
all  my

known  networks/objects.



To start with you need to recognize that macros won't do
the trick.  You need to put everything you want to
exclude into a single table.  A macro will expand
into two rules, so what does not match one rule will
match the other when you negate the macro's test.


So e.g.

 { !$myNet1, !$myNet2, !$otherNet1, !$otherNet2 }
block in log quick from  to (self) port 22

will do the trick?


You left off the word "table".  Beyond that, no, I don't think
that will work, although I've not tried that particular syntax.
The problem being, as with the macros, is that the logical
operation used in table lookup, as with rule matching, is "or".
So, something that matches $myNet1 will not match $myNet2,
but that does not matter because $myNet1 has already matched.
Likewise, something that matches $myNet2 will match the table
even though it does not match $myNet1.

You could try it and tell me if I'm wrong.

Instead, negate the whole thing:

table  { $myNet1, $myNet2, $otherNet, $otherNet2 }
block in log quick from !  to (self) port 22

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Group/negate tables and other objects

[Karl O. Pinc]

On 04/17/2009 04:10:35 AM, Helmut Schneider wrote:

Helmut Schneider  wrote:


can I group tables? Or specify something like

myNet1="192.168.0.0/24"
myNet2="192.168.1.0/24"
otherNet1="192.168.2.0/24"
otherNet2="192.168.3.0/24"

table  { $myNet1, $myNet2 }
table  { $otherNet1, $otherNet2 }
table  { ,  }

internet = ! { ,  }
internet = ! "{"   "}"
...

Purpose is to create an object called "internet" which excludes all  
my

known  networks/objects.


[ ] It's not possible
[ ] RFTM
[ ] What was the question?


To start with you need to recognize that macros won't do
the trick.  You need to put everything you want to
exclude into a single table.  A macro will expand
into two rules, so what does not match one rule will
match the other when you negate the macro's test.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Anchor "foo" vs. anchor "foo/*"

[Karl O. Pinc]

On 04/16/2009 10:03:59 AM, Jim Rosenberg wrote:

pf.conf(5) is reasonably clear about this, I think...


"Anchors may end with the asterisk (`*') character, which  
signifies
that  all anchors attached at that point should be evaluated in  
the

alphabeti-  cal ordering of their anchor name.  For example,

   anchor "spam/*"

 will evaluate each rule in each anchor attached to the spam  
anchor."


Maybe:

Evaluate all anchors, in alphabetical order, contained within an
anchor using the asterisk ('*') character.  For example,

anchor "spam/*"

evaluates each rule in each anchor attached to the spam anchor.

This may not address Jim Rosenberg's concerns, but it's shorter
and punchier and so should be easier to understand.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: dual ISP puzzle

[Karl O. Pinc]

On 02/23/2009 05:06:51 PM, Chris Smith wrote:


However, when not routing normally, that is using route-to instead of
the routing tables default gateway, ftp for the inside clients is not
working. I'm guessing I need to use the -T argument, tag the packets
and use some route-to and/or reply-to rules to get it to all work.
==

The last group of pass-out rules from the pf.conf (in case this
helps):
==
pass out on $ext_if   route-to ( $wow_4_if $wow_4_gw ) from $wow_4_if
pass out on $ext_if   route-to ( $wow_8_if $wow_8_gw ) from $wow_8_if
pass out on $wow_4_if route-to ( $wow_8_if $wow_8_gw ) from $wow_8_gw
pass out on $wow_4_if route-to ( $ext_if $ext_gw ) from $ext_gw
pass out on $wow_8_if route-to ( $wow_4_if $wow_4_gw ) from $wow_4_gw
pass out on $wow_8_if route-to ( $ext_if $ext_gw ) from $ext_gw
==


(FWIW, I'd write it like this because I think it makes
the pattern more clear.)

pass out on { $ext_if $wow_8_if } \
  route-to ( $wow_4_if $wow_4_gw ) from $wow_4_gw
pass out on { $ext_if $wow_4_if } \
  route-to ( $wow_8_if $wow_8_gw ) from $wow_8_gw
pass out on { $wow_4_if $wow_8_if } \
  route-to ( $ext_if $ext_gw ) from $ext_gw

If you've 3 separate ftp-proxy instances, one each with
a -a for each gateway, then I'd think you could use -T
and tag with any tag and forget about writing special
rules that look for the tag.
The ftp-proxy -T should be enough to turn off the "quick" and
then your rules above would catch the outbound traffic
and do the appropriate route-to.

Dunno if it works, but that's what I'd try.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: dual ISP puzzle

[Karl O. Pinc]

On 02/22/2009 10:28:30 PM, Chris Smith wrote:


Was hoping I could more easily apply your example to my problem. I
have multiple ISP connections, not doing load balancing, and using
route-to to send groups of systems out different interfaces. The only
glitch seems to be with the clients doing ftp. I'm tagging the packets
with ftp-proxy (separate instances for each interface) but not sure
how to use these tags in the ruleset.
Any assistance is appreciated.


Tagging does not (necessarily) enter into ftp, if I understand
your setup.  You run different instances of ftp-proxy on different
ports, so the rdr takes care of that.  Then you use
the -a argument to ftp-proxy to so that the "right"
nic is used for each ftp-proxy running, where "right"
means the interface that the passive mode data connection
is natt-ed to or otherwise transits so that passive mode f
tp works.

The only other issue is that you can't binat the clients
(for all ports)
and still do passive ftp because binat is evaulated
before nat so the ftp-proxy nat anchor is not seen.
The workaround is to split each binat rule into a
rdr and a nat rule.

Then again, maybe I'm guessing wrong as to your ruleset.
You'd have to post detail.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Using state table with a transparent firewall

[Karl O. Pinc]

On 12/25/2008 07:54:35 AM, Federico Giannici wrote:
We have an OpenBSD server acting as a firewall/QoS router (no nat or  
rdr).


It has two requirements:

A) It has to be as "transparent" as possible. So, if firewall is  
rebooted or the state table is flushed, it don't block already  
established connections or not assign the packets to the right queue.


If you really want uptime then get 2 devices and use carp and
pfsync.  That way one can fail or be upgraded and the other
will take over.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Tuning PF Round Robin and State Expiration

[Karl O. Pinc]

On 10/08/2008 06:03:14 PM, Mike Sweetser - Adhost wrote:


rdr on ! $vlanX_if proto { udp tcp } from any to $web_183_ext port {
80
443 } ->  round-robin sticky-address



Is there any way to set this so that a given client IP will hit the
same
server in the pool, regardless of port?


Anything wrong with using source-hash instead of round-robin?



In addition, we're noticing that states seem to expire pretty quickly



Is there a way to modify the state timeouts on a more granular level?


Yes  You may want: set timeout src-track
or other settings.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Rare problem with HTTPS

[Karl O. Pinc]

On 09/22/2008 10:03:53 AM, Jordi Espasa Clofent wrote:

Stuart Henderson escribió:

You may be recycling port numbers before the state fully expired.

If that's the case you can try reducing the tcp.closed timeout:
"keep state (tcp.closed XX)".


Wouldn't that be tcp.finwait for "normal" tcp connection closes?

FYI, I have seen Microsoft OSs reuse the source IP, source port,
destination IP, destination port quad before the 2MSL timeout
required by the TCP spec.  The point being that you can see
repeats without rotating through all available port numbers
if the client is stupid.  I seem to recall that poking
at the problem with a stick lead me to conclude that
Microsoft was using some small fixed time limit for
TCP_FINWAIT.  Something like 3 or 5 seconds.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Reality check

[Karl O. Pinc]

On 09/10/2008 08:54:21 AM, Stuart Henderson wrote:


HTTP redirects might be the least-overhead method and are usually
pretty simple to setup... add a record "www2 A 5.6.7.8", and have the
old server just redirect to www2 after the switch-over date to catch
any late queries that arrive due to over-cached DNS.


The problem with http redirects are that they are visible to the
end-user.  Depending on your requirements, it can be a problem
if the user is redirected to www2, bookmarks it, and finds
at a later date that www2 no longer responds.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Two external interfaces routing issues?? int_if, ext_if, tun_if

[Karl O. Pinc]

On 08/29/2008 11:11:51 AM, [EMAIL PROTECTED] wrote:

On Aug 29, 3:10=A0pm, [EMAIL PROTECTED] (Karl O. Pinc) wrote:
> On 08/28/2008 08:13:50 AM, [EMAIL PROTECTED] wrote:
>
>
>
> > On Aug 28, 12:45=3DA0am, [EMAIL PROTECTED] wrote:
> > > # =3DA0 =3DA0 =3DA0 $OpenBSD: pf.conf,v 1.35 2008/02/29 17:04:55
reyk=
 Exp
> > $
> > > #Map internal addresses to external
> > > binat on $tun_if proto {tcp, udp, icmp} from $intaddr_irishcoffe
to
> > > any -> $tunaddr_irishcoffe
> > > binat on $tun_if proto {tcp, udp, icmp} from $intaddr_bloodymary
to
> > > any -> $tunaddr_bloodymary
> > > binat on $tun_if proto {tcp, udp, icmp} from
> > $intaddr_longislandicetea
> > > to any -> $tunaddr_longislandicetea
>
> > > #Traffic on addresses not mapped with BINAT should be NATed via
vr0
> > > (ie. not be pushed via the tunnel but rather pushed directly on
the
> > > DSL line)
> > > #The below does not work though
> > > nat on $ext_if from $int_if:network to any -> { $ext_if }
>
> > > #Enabling the below makes it possible to access the Internet via
> > > $ext_if from 10.0.0.10 but only 10.0.0.10.
> > > #This is what I want with NAT above but for the whole
10.0.0.0/24
> > net
> > > (except BINATed addresses).
> > > #binat on $tun_if proto {tcp, udp, icmp} from 10.0.0.10 to any
->
> > > $ext_if:0
>
> > > nat-anchor "ftp-proxy/*"
> > > rdr-anchor "ftp-proxy/*"
> > > rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1
port
> > > 8021
> > If I made the NAT rule look like this it worked:
>
> > nat on $tun_if from $int_if:network to any -> $ext_if
>
> > Now the uestion is why
>
> It's because your binat rule has already translated the datagrams
> IP addresses before your nat rule sees the datagrams, so as
> originally written the nat rule does not match.
>
> FYI, binat rules are done before nat rules regardless of the
> order in which they appear in pf.conf.
>
> Karl <[EMAIL PROTECTED]>
> Free Software: =A0"You don't pay back, you pay forward."
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Robert A. Heinlein

Thank you very much for the reply
But... The BINAT rule is between $int_if and $tun_if
And the NAT rule is between $int_if and $ext_if

I cannot see how the BINAT rule could translate anything which makes
this not work.


You're right about what IPs should be affected by what rule,
I was not reading closely enough.  My mistake.  Sorry.



BINAT only handles 3 ip addresses in the 10.0.0.0/24 net.
Then the rest of the addresse is not affected I thought?
Wouldnt the NAT rule handle the rest of them then?
and push it over to the $ext_if interface?


The NAT rules don't do any "pushing" through interfaces,
that's what the routing tables do.

Clearly something's sending your traffic through the
tunnel, or the binat rule you added wouldn't have
had any effect.

I have some suggestions.

Get the firewall working without the tunnels, then add
the tunnels.  I suspect something in OpenVPN is
messing with the way your traffic is routed in a way
you don't expect.

Begin with a "block all".  "block in", "pass out" works
when you've only 2 interfaces, but does not scale well
to multiple interfaces.  Better to retain finer control
and be sure you know where all traffic is going and why.
You may even want "set state-policy if-bound" to be sure
you know what's going on, then relax the policy (and possibly
remove rules and/or tags/policy based filters) if performance
is an issue.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Two external interfaces routing issues?? int_if, ext_if, tun_if

[Karl O. Pinc]

On 08/28/2008 08:13:50 AM, [EMAIL PROTECTED] wrote:

On Aug 28, 12:45=A0am, [EMAIL PROTECTED] wrote:



> # =A0 =A0 =A0 $OpenBSD: pf.conf,v 1.35 2008/02/29 17:04:55 reyk Exp
$



> #Map internal addresses to external
> binat on $tun_if proto {tcp, udp, icmp} from $intaddr_irishcoffe to
> any -> $tunaddr_irishcoffe
> binat on $tun_if proto {tcp, udp, icmp} from $intaddr_bloodymary to
> any -> $tunaddr_bloodymary
> binat on $tun_if proto {tcp, udp, icmp} from
$intaddr_longislandicetea
> to any -> $tunaddr_longislandicetea
>
> #Traffic on addresses not mapped with BINAT should be NATed via vr0
> (ie. not be pushed via the tunnel but rather pushed directly on the
> DSL line)
> #The below does not work though
> nat on $ext_if from $int_if:network to any -> { $ext_if }
>
> #Enabling the below makes it possible to access the Internet via
> $ext_if from 10.0.0.10 but only 10.0.0.10.
> #This is what I want with NAT above but for the whole 10.0.0.0/24
net
> (except BINATed addresses).
> #binat on $tun_if proto {tcp, udp, icmp} from 10.0.0.10 to any ->
> $ext_if:0
>
> nat-anchor "ftp-proxy/*"
> rdr-anchor "ftp-proxy/*"
> rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port
> 8021



If I made the NAT rule look like this it worked:

nat on $tun_if from $int_if:network to any -> $ext_if

Now the uestion is why


It's because your binat rule has already translated the datagrams
IP addresses before your nat rule sees the datagrams, so as
originally written the nat rule does not match.

FYI, binat rules are done before nat rules regardless of the
order in which they appear in pf.conf.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: counters | labels matching all pass rules?

[Karl O. Pinc]

On 07/31/2008 10:01:51 AM, Dil Doe wrote:


The problem right now is I block everything and have multiple pass
rules for -exactly- what I need. It would be incredibly tedious to add
a label or counter to every pass rule I have. Is there a way to
simplify this, a passive 1-liner that will match all incoming and
outgoing bandwidth to my $ext_if without affecting my current rules?


No, not that I've been able to figure out.

I've the same problem.  What I want to pass has little to do
with what I want to measure which either means that I've
got to manually aggregate lots of pass rules and/or
split some of the many existing pass rules into 2 or
more separate rules just so I can measure what I want to
measure.  While this is not a defect in the pf design,
IMO it is a deficiency.

If would be nice if pf had another type of statement that
only collected stats, to be "executed" after all filter
rules.

I've decided to try pmacct for my monitoring and reporting
needs.  There are other choices and as yet I've not
gotten far enough to be a proponent of any particular
choice.  http://www.pmacct.net/

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Why is my carp demotion counter 1?

[Karl O. Pinc]

Hi,

OpenBSD 4.2 stable patched to Feb 27, 2008

I've two firewalls with carp failover between them.
One is configured with the carp interfaces having an
advskew of 100, so that machine is normally the backup.
Something happened and the backup has become the master,
and the master has a demotion counter of 1 on the
carp group.

I imagine that rebooting would fix things, but what's
going on?

FWIW, this happened around the time of the nightly fs
backup.  Occasionally at this time the backup machine
momentarily becomes the master.  I'm presuming that
this is because the network link is saturated
enough to mess with the carp protocol.

On a related note, the ifstated daemon on the backup
firewall did not pick up on the fact that it became
master.  Appended is the configuration.  Should I
discuss this problem on the openbsd misc list or
is it related to my demotion counter problem?

Thanks for the help.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

# /etc/ifstatd.conf
#
# The whole idea here is that we want 3 things:
#  1) to be emailed when interfaces go up and down
#  2) to record whether we're running as master, and
#  3) we want to ensure that DHCP runs only on the master firewall.
#(Because there's no way to sync dhcp state between
# two servers we could get conflicts if both servers ran dhcp.)

# net.inet.carp.preempt must be enabled (set to 1) for this to work  
correctly.


master_up = "(carp0.link.up && carp1.link.up && carp2.link.up &&  
carp3.link.up)"
master_down = "(!carp0.link.up) && (!carp1.link.up) && (!carp2.link.up)  
&& (!carp3.link.up)"
master_sync = "!((carp0.link.up && carp1.link.up && carp2.link.up &&  
carp3.link.up) || ((!carp0.link.up) && (!carp1.link.up) &&  
(!carp2.link.up) && (!carp3.link.up)))"


init-state in_startup

state in_startup {
  # initial startup state
  run "/usr/local/sbin/yellboot"
  run "rm -f /var/mirror_system/bootnote"
  if $master_up
set-state in_master
  if $master_down
set-state in_backup
}

state in_sync {
  # state for when we're neither all master or all backup.
  if $master_up {
run "/usr/local/bin/wail 'sync attained, got master'"
set-state in_master
  }
  if $master_down {
run "/usr/local/bin/wail 'sync attained, in backup'"
set-state in_backup
  }
}

state in_master {
  init {
# Note that we're now in master state
run "touch /var/mirror_system/am_master"
# Tell dhcp it's the master
run "/usr/sbin/dhcpd sis2"
  }
  if $master_down || $master_sync {
# Note that we're no longer in master state
run "rm /var/mirror_system/am_master"
# Have dhcp stop running
run "pkill dhcpd"
# Tell the sysadm our current state.
if $master_down {
  run "/usr/local/bin/wail 'lost master, in backup'"
  set-state in_backup
}
if $master_sync {
  run "/usr/local/bin/wail 'lost master, trying to sync'"
  set-state in_sync
}
  }
}

state in_backup {
  if $master_up {
run "/usr/local/bin/wail 'out of backup, got master'"
set-state in_master
  }
  if $master_sync {
run "/usr/local/bin/wail 'out of backup, trying to sync'"
set-state in_sync
  }
}

Re: pfsync/carp races?

[Karl O. Pinc]

Thanks for all the help.

On 07/14/2008 12:52:16 AM, Ryan McBride wrote:



The carp demotion twiddling in RC isn't disabled until after rc.local
is
run, so this shouldn't be a problem (but in general it's safe to turn
on
forwarding during boot, because the boot-time pf.conf won't pass
forwarded traffic.


So, my problem must be that the pfsync interface is brought
up before the real pf rules are loaded, and so states do
not associate with the right rules.  Fixed in 4.3.

Because I'm loading pf.conf myself in rc.local (so it starts
after named, which is a secondary that caches local DNS names
so they can be used in pf.conf) I'll need to make sure that
the pfsync interface does not come up until I bring it up
in rc.local.  I'll put "down syncdev vr0" into hostname.pfconf0,
and the bring it up with ifconfig in rc.local after loading
pf.conf.  I get the boot order I want without having to alter
rc or netstart.

(FWIW I don't recall that hostname.if(5) matches with the
netstart code particularly well regarding where the "up"
and "down" keywords are allowed.  IIRC, the code allows
"up" and "down" to be used with any interface.  I could be wrong,
or maybe the "up" and "down" can occur elsewhere because
they're ifconfig options but have to occur first with
pfsync and bridge interfaces to make netstart happy?
I'm not sure it matters.)





> Which brings me back to the question of how the demotion counter
> works,




There is some usage information in ifconfig(8), and you can look at
/etc/rc to see how it's being used.


Thanks.  I'd gone though ifconfig, but have now looked at (IIRC)
carp.c and /etc/rc.  As you point out I don't need to mess
with the demotion counter because rc has already done
so while rc.local is running.  This is good because at
first glance the demotion counter appears to be modulo 256
and with rc modifying it in increments of 128 and bgp
and whatnot also modifying it I was concerned that any
changes I might introduce could lead to overflow.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: pfsync/carp races?

[Karl O. Pinc]

On 07/14/2008 12:52:16 AM, Ryan McBride wrote:

On Sun, Jul 13, 2008 at 02:44:40PM -0500, Karl O. Pinc wrote:
> On 07/12/2008 04:12:14 PM, Karl O. Pinc wrote:
>> The one unusual thing about my configuration is that
>> I don't bring up pf with rc.conf.local.  Pf is
>> started in rc.local so that it starts after
>> the (secondary, local ,caching) nameserver so that I can
>> use the dns names of my domain in pf.conf.
>
> This is clearly going to cause a problem because
> I also don't allow forwarding until after pf is up,
> so as soon as the carp interfaces become master
> the clients will start receiving icmp unreachable messages
> in response to traffic.

The carp demotion twiddling in RC isn't disabled until after rc.local
is
run, so this shouldn't be a problem (but in general it's safe to turn
on
forwarding during boot, because the boot-time pf.conf won't pass
forwarded traffic.


FWIW in my case, because rc.conf.local has pf turned off, the
boot-time pf rules are not loaded.  To prevent indiscriminate
forwarding I don't want forwarding turned on
until after my pf ruleset is loaded in rc.local.  Because
the carp interfaces won't go into MASTER while rc.local is
running I don't need to worry about the time during which
the pf ruleset is loaded but forwarding is not yet on.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: pfsync/carp races?

[Karl O. Pinc]

On 07/13/2008 08:14:30 PM, Ryan McBride wrote:

On Sat, Jul 12, 2008 at 04:12:14PM -0500, Karl O. Pinc wrote:




> Aside from dumping state tables on the master and standby
> boxes and comparing them, is there a way to ask
> if the state tables are synchronized?

Not really, because



> Knowing would help prevent shutting down the master when the standby
> is not yet synchronized.

Don't shut your "master" down until all it's carp interfaces are in
the
MASTER state.


The case I'm now concerned about is shutting down the active
firewall before the standby firewall has synchronized it's
state and and is ready to take over.  E.g. while doing
maintenance after rebooting the standby firewall
you'd want to know it's synchronized (mostly anyhow)
before shutting down the active firewall.

Maybe it's a non-issue because synchonization(ish) happens
fast enough even on a slow box that it's just not likely
to ever happen.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: pfsync/carp races?

[Karl O. Pinc]

On 07/12/2008 04:12:14 PM, Karl O. Pinc wrote:

Hi,

I've two firewalls configured to synchronize state with pfsync
and failover transparently.  The other day I was bringing
the firewalls up and down and was surprised to find that
when I did so some connections were dropped.



The one unusual thing about my configuration is that
I don't bring up pf with rc.conf.local.  Pf is
started in rc.local so that it starts after
the (secondary, local ,caching) nameserver so that I can
use the dns names of my domain in pf.conf.


This is clearly going to cause a problem because
I also don't allow forwarding until after pf is up,
so as soon as the carp interfaces become master
the clients will start receiving icmp unreachable messages
in response to traffic.

Which brings me back to the question of how the demotion
counter works, so I can do something to use it to keep
the carp interfaces out of the master state until
pf is up and forwarding on.  It seems the demotion counter
is the tool for that task.  And, I'll be wanting
to keep the carp interfaces out of master until
pfsync has synchronized, so would appreciate help
regarding how to monitor pf's synchronization-ness.

Sorry for the long emails.  I figure better more info
than less.

Thanks for the help.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: A PF Certification - what do you think?

[Karl O. Pinc]

On 07/10/2008 05:10:50 AM, Peter N. M. Hansteen wrote:

Would a creating a PF certification be worth putting some effort into?


No problem, just so long as you grandfather all of us in.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Patch for pf.conf.5

[Karl O. Pinc]

The wording here has always bugged me.

Attached is a patch against
.\" $OpenBSD: pf.conf.5,v 1.397 2008/05/19 14:57:31 markus Exp $
(Which should be cvs head.)

What prompted me to do this was page 60 of
'The Book of PF', "Once a packet has been tagged by a matching rule,
it can potentially be tagged by all other matching rules too, not
just the last one." which implies (to me) that a packet can be have
more than one tag.  An incorrect implication.

As long as I'm playing editor...  On page xvii, the Preface
of 'The Book of PF', it says "Instead, the interfaces are
assigned names that equal the driver name plus a sequence
number."  Better would be "... the interface names are composed of
the driver name followed by a sequence number."  Or more simply "...
interfaces are given names made from the driver name and a
sequence number."

And finally, the same paragraph ends with "Quite logical, really, and
you will find this system easy to get used to."  IMHO this
sentence is better left off, considering that the book repeatedly
revisits how to replace the driver specific name with something
more abstract.  Or maybe "get used to" is the wrong phrase.
Something like "replace where appropriate" would be more apt.

Regards,

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
--- pf.conf.5	2008-05-26 15:09:57.0 -0500
+++ pf.conf.5.new	2008-05-26 15:11:36.0 -0500
@@ -1811,7 +1811,7 @@
 meaning that the packet will be tagged even if the rule
 is not the last matching rule.
 Further matching rules can replace the tag with a
-new one but will not remove a previously applied tag.
+new one but cannot untag a packet already tagged.
 A packet is only ever assigned one tag at a time.
 Packet tagging can be done during
 .Ar nat ,

Re: binat question

[Karl O. Pinc]

On 05/13/2008 12:35:28 AM, Christer Solskogen wrote:



This is my full pf.conf:


The only thing I notice offhand is that I prefer to put
the ftp-proxy anchors above all the other translation
rules so that whatever magic ftp-proxy is working
does not get inadvertently preempted.  (I don't
know why you're opening those large port ranges, but
if it's for FTP this might solve that problem.)

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: binat question

[Karl O. Pinc]

On 05/12/2008 12:07:45 PM, Christer Solskogen wrote:
I have been trying to get some of my online games to work. Normally  
on a NAT-ed network rdr's are needed to get the port forwarding to  
work.



My pf.conf is:

funshine = "192.168.0.12"
rdr pass log on $ext_if proto { tcp, udp } from any to $ext_if port {  
-> $funshine

binat on $ext_if from $funshine to any -> 85.200.10.151


You report what does work, but not what didn't work so it's difficult
to say why it didn't work.

It could be the order in which the rules are evaluated confused you:


 Evaluation order of the translation rules is dependent on the  
type of the
 translation rules and of the direction of a packet.  binat rules  
are al-
 ways evaluated first.  Then either the rdr rules are evaluated on  
an in-
 bound packet or the nat rules on an outbound packet.  Rules of  
the same
 type are evaluated in the same order in which they appear in the  
ruleset.

 The first matching rule decides what action is taken.

I.e. the rdr rule in your ruleset does nothing.  On the other hand,
both endpoints probably need to be able to initiate traffic, so binat
is probably what you want.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: binat question

[Karl O. Pinc]

On 05/12/2008 04:32:05 PM, Christer Solskogen wrote:
If I do not use the binat-rule, connecting to games (in CoH) will not  
work. But CoH also seems to be the only game with that kind of  
problem.


If I am not mistaken, using a binat-rule also makes my machine  
vurnable for other stuff. I am under the impression that the ports I  
define in the rdr rules are wrong (which means the documentation for  
CoH is wrong)


Based on your previous post you are using an RFC1918 address
space inside your LAN.  Unless you NAT your traffic it will
not route on the Internet.  I suggest you read up on
networking and what NAT does.

"The Book of PF" might be good.  It will surely teach
you about pf.  I've not read it yet so don't know
how much basic networking is explained.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: authpf, but with a shell too

[Karl O. Pinc]

On 04/23/2008 01:38:22 AM, Adam Richards wrote:


So, is there a way to achieve both authentication and interactive
access?  Am I missing something stupid?  :)


Authpf is just a shell.  Write your own that runs it,
and have that be your user's shell.  Like:

#!/bin/ksh
/usr/sbin/authpf&
/bin/ksh

(Note: I have no idea whether the above is sane or
secure.  The whole goal seems a little wack to me)

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Need stateless NAT

[Karl O. Pinc]

On 04/08/2008 10:41:07 AM, Daniel Hartmeier wrote:


No, pf can't do it. Not because it's technically impossible or
unreasonable, it's just not a typical use case. For most users,
routable
address space is a scarcer resource than RAM for state table entries
(they have much less external IP addresses than internal ones).


Which makes me wonder what the problem with state is in the first
place.  Seems to me that just because replies might go through
a different device than the original packet does not mean that
you can't have state, it just means that you want all the
devices to have the same state.  Wouldn't something like
a binat rule that does source-hash where the key is specified
always do the same translation regardless of whether the flow
has been seen before?  Then you put the same binat rules
on all your devices and you're done.

Perhaps binat's source-hash is sensitive to the direction
of the initial packet.  ?  If so that's a problem, but a
problem that I'd guess is a lot easier to solve than
getting rid of state.

(There's also pfsync for sharing state, but I can't imagine
how you'd get rid of race conditions.)


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Need stateless NAT

[Karl O. Pinc]

On 04/08/2008 01:45:00 AM, Adam Richards wrote:

On Sun, Apr 06, 2008 at 07:53:39PM +0900, Ryan McBride wrote:



> Keeping state is required for NAT to work, because you need to keep
> track of the mapping so that the return packets can be translated
back
> the other way;

Required?  Technically, no (although it's a good idea for many
reasons in most situations).


..


Quoting from 

" Stateless NAT is useful in controlled environments where
restrictions are placed on through traffic such that we don't
need connection tracking to correctly NAT protocol-specific
data.


What restrictions would those be?  The only one I can think of is
when the NATting is 1-to-1 with respect to internal and external IPs.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Allowing active FTP on a PF self-protecting host

[Karl O. Pinc]

On 03/05/2008 09:47:10 AM, Saad Kadhi wrote:

Do you any ideas of how to be able to use active FTP on a PF  
self-protecting FreeBSD 7.0 host (PF running on the host itself and  
not on a gateway protecting the host) with a default block policy?


ftproxy is only for proxying to other hosts.

With active FTP the server initiates the data connection.
By default this is to the same port on the client
which the client has used for it's side of the
control connection.  So, either:

Force the client to fix the port the client side of the
connection uses for the control connection.
Have pf allow inbound connections to that port.
(Beware of servers that do not follow the RFC.
There's bound to be at least 1 on the Internet.  :-)

Have the client issue a FTP PORT
command to control the port used
for the data connection on the client side.
Have pf allow inbound connections to that port.

Use a FTP client that knows enough about pf
to add/remove rules from an anchor,
in the manner of ftp-proxy, to allow establishment
of data connections to arbitrary ports.
Tell pf about that anchor.

Your other options are not having a default block
policy or using passive FTP instead of active FTP.
Unless there's something I've not thought of.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Allow nmap

[Karl O. Pinc]

On 03/04/2008 01:59:43 PM, Jordi Espasa Clofent wrote:

Hi all,

I've a boxe called nagios which does some services checks; the usual  
form would be:


$ nmap -p  




¿Why the nmap output is randomly open or filtered when pf is enabled?


I have not done more than skim your config, but you might try
temporarily disabling your "block " rules and see
if that makes a difference in case your nmap scan is triggering
whatever it is that populates the brutes tables.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Slow SSH connection

[Karl O. Pinc]

On 02/24/2008 10:27:42 AM, Jordi Espasa Clofent wrote:

Stuart Henderson escribió:

On 2008/02/24 12:21, Jordi Espasa Clofent wrote:
Very happy with performance and capabilities of PF. But when I try  
ssh connections from outside to my net boxes, they're very very  
slow. They work, but work so slowly.


Describe this in a bit more detail...


Yes Stuart, I know my words are vague, but it's exactly what I've  
said: the ssh connection with pf enable seems a slow process.


A few points:

* With pf disabled you get the ssh Password prompt in (aprox) 3  
secons.
* With pf enabled you'll get the ssh Password prompt in (aprox) 15  
secons.


So, it takes a long time to get going but works fine once it does?
That feels a bit like a DNS issue.

Nothing in the sshd logs?

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Documenting 'set ' values

[Karl O. Pinc]

Any hope of documenting the various 'set ' default values,
maybe in pf.conf(5)?  Is there a reason why it's _not_ documented?
Would entries like:
  tcp.first
 The state after the first packet.  Defaults to 120
 seconds.
have the proper structure?

I needed to know the udp.multiple timeout to configure
a vpn so that it'd send traffic frequently enough to keep the state
alive, and it was a pain to find the numbers in pfvar.h.

Once upon a time this was documented in the default pf.conf
file, but no longer.  (That's probably not a good place
to put it.)

Thanks.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Concurrency and table updating

[Karl O. Pinc]

On 12/20/2007 12:44:48 AM, Camiel Dobbelaar wrote:


Karl O. Pinc wrote:
> Are there any concurrency issues involved in
> updating pf tables?



In the case of ftp-proxy you mean anchors, right?


Oops.  Right.

So multiple ftp-proxy's will never collide.


Awesome.   Thanks!


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Network performance tool with little sized packets

[Karl O. Pinc]

On 12/19/2007 09:11:48 AM, Jordi Espasa Clofent wrote:
So, I need to benchmark the FW with little size packets. The question  
is
¿Is there any tool which generates small packets traffic to benchmark  
the network performance as iperf or netperf does?


You can give a payload to ping.  And ttcp is in OpenBSD ports.  YMMV.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Concurrency and table updating

[Karl O. Pinc]

Are there any concurrency issues involved in
updating pf tables?  Specifically, I'd like to
run 2 instances of ftp-proxy but it has no
options to allow the separate copies to update
separate tables.

Thanks.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Accommodating 2MSL violators -- Was: Re: Strange BAD state errors ...

[Karl O. Pinc]

On 12/18/2007 02:29:38 AM, Henrik Johansen wrote:

[Karl O. Pinc] wrote:



I'll need to examine my traffic to see whether
I need to mess with tcp.closed, interval, or tcp.finwait.
(I know in one case it's RST packets that are the trouble
so tcp.closed/interval would do the trick for that.)


What version of OpenBSD are you running? I remember something in the
commit logs regarding finwait and PF that might relate to your  
problem.


http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c?rev=1.559&content-type=text/x-cvsweb-markup


I'm running 4.2 Stable (to patch #4), so this is not in
my system.  :-(

Thanks for the help.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Accommodating 2MSL violators -- Was: Re: Strange BAD state errors ...

[Karl O. Pinc]

On 12/17/2007 03:32:39 AM, Henrik Johansen wrote:

[Karl O. Pinc] wrote:


On 12/14/2007 02:17:22 AM, Henrik Johansen wrote:

Hi list,

We are experiencing a steady flow of BAD state error messages that  
I  cannot explain.


I continue to have problems with (Microsoft) hosts that
violate the 2MSL TCP rule (STD7, RFC793, page 27
"Knowing When to Keep Quiet")

It would, *urp*, be nice if pf had a way to
specify the MSL in the scrub directive to
work around the brokenness.

[...]

I don't think that this is my problem however. Most BAD state  
messages are generated by ACK packets, not SYN packets.


I just saw the 1 minute (rather, 59 second) time period and
started coding to see if the rest matched.   Ah well.



AFAIK, when a client violates the 2MSL rule should I not see the  
initial

SYN blocked by PF (since it would create a state mismatch, hence a BAD
state log entry) ?


Yes.  (I'm not clear about what I'm looking at when I look at
bad state log entries.  I couldn't find documentation
and decided not to turn my brain on.)

As a side note, have you tried scaling down the tcp.closed parameter  
for

PF ? I have seen numerous references that this might help against 2MSL
violations ...


Duh.  That's exactly the sort of thing I need.  I
can't believe I've not explored that option.  Thanks!

I'll need to examine my traffic to see whether
I need to mess with tcp.closed, interval, or tcp.finwait.
(I know in one case it's RST packets that are the trouble
so tcp.closed/interval would do the trick for that.)

What am I missing?  Based on google searching
RSTs (fixed with tcp.closed)
more likely associated with 2MSL violations than
FINs (tcp.finwait).  Why is this?  Do perverse
TCP stack programmers prefer RSTs?

I've not thought this through, but it seems
to me that there are two general cases when
RSTs are received: when the receiving system
returns to LISTEN (receiving system in
un-synchronized state, RST received while in
SYN-SENT or SYN-RECEIVED), and otherwise.
If the 2MSL violators are violating 2MSL
only for those connections that never reached
the ESTABLISHED state (I _think_ I remember this
from my tcpdump analysis) then would it make
sense for pf to have a separate timeout for
these sorts of resets?  A tcp.aborted timeout
for when RSTs are received before the tcp.established
state is reached?


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

P.S.

I also don't get the tcp.opening state.  As
pf.conf(5) is written I can't tell what sends
pf out of tcp.first into tcp.opening.

After reading the udp.single entry I thought
it was something like:

"tcp.opening  The state if the
source host sends more than one packet before
the destination host ever sends a packet."

But that does not make sense if pf is always supposed to
be in one of the listed tcp states.  So, I suspect
it's something like:

"tcp.opening  The state before the destination host
sends it's first packet after the SYN/ACK tcp handshake
packet."

Or alternately:

"tcp.opening  The state before the destination host
sends it's first packet with a data payload."

Why wouldn't it be:

"tcp.opening  The state after the first packet but
before the 3-way tcp handshake has been completed."

Perhaps not the last because pf does not know the
handshake got through until the destination sends
it's first packet with a data payload?

Re: Strange BAD state errors ...

[Karl O. Pinc]

On 12/14/2007 02:17:22 AM, Henrik Johansen wrote:

Hi list,

We are experiencing a steady flow of BAD state error messages that I  
cannot explain.


I continue to have problems with (Microsoft) hosts that
violate the 2MSL TCP rule (STD7, RFC793, page 27
"Knowing When to Keep Quiet").  I strongly suspect
that MS is setting the MSL to 1 minute rather than the
2 minutes of the standard.  (I don't know about Vista,
which supposedly has a new TCP stack.)  This causes
pf to see state errors.

It would, *urp*, be nice if pf had a way to
specify the MSL in the scrub directive to
work around the brokenness.  I've had to replace
a lot of stateful rules with stateless filtering.
Not only is it ugly and less secure that way, but
diagnosing the problem is a real pain in the butt.

I can't say if this is your problem.  I ran the
following script against your log after I did a
random check and saw a 1 minute interval during
which a particular sourceip/sourceport/destip/destport
was failing.  The script (kinda) does a frequency analysis
on how long the bad state persists on any particular
connection.  The results tell me nothing.  Maybe
somebody else will have better luck.

---
#!/bin/sh

export IN=/tmp/messages.sanitized

cat $IN \
  | grep ' BAD state: ' \
  | cut -d ' ' -f 11-12 \
  | sort -u \
  | while read conn ; do
  #echo
  #echo $conn
  cat $IN \
| grep "$conn" \
| awk 'BEGIN {fst = ""; };
   {if (fst == "")
  fst = $3;
lst = $3;
#print $0;
   };
   END {
 #print fst, lst;
 gsub(":", " ", fst);
 gsub(":", " ", lst);
 fststmp = mktime("2007 12 13 " fst);
 lststmp = mktime("2007 12 13 " lst);
 print lststmp - fststmp;
   };'
done \
  | sort -n \
  | awk '# Do frequency analysis
 BEGIN {print "Seconds Count";
l = "";}
 {if (l != $0) {
   if (l != "" ) {
 print l, c;
   };
   c = 0;
   l = $0;
  };
  c = c + 1;
 }
 END {print l, c;}
'




Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Redirect Syntax Errors

[Karl O. Pinc]

On 11/19/2007 11:05:02 PM, Shane Harbour wrote:


# spamd #
rdr on $ext_if inet proto tcp from  to $mail_svcs port smtp
-> $mail_svcs port smtp


 I am using

binat for my mail server and $mail_svcs contains my server IPs.

I'm using 4.2-stable.  Any help/info/pointers are very much
appreciated.


This has nothing to do with syntax, and I'm unclear exactly
what you're doing with binat, but caution is called for
using both binat and rdr.  binat is done before rdr
which means that if you do both the rdr is effectively ignored,
regardless of the order of the statements in pf.conf.
Use nat instead of binat and do inbound and outbound
separately.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Several questions

[Karl O. Pinc]

On 11/15/2007 03:36:27 AM, Jordi Espasa Clofent wrote:

Hi all,

I'm planning to use OpenBSD and PF to build a gateway which has to:




¿Is capable a simple OpenBSD+PF box to do this amount of work?


If you search the list archives you will find plenty
of discussion about hardware requirements along the lines
of your question.

My understanding is that many people are using OpenBSD in your
sort of environment.  However, every site is different so
the best thing to do would be to install OpenBSD on some
computer you've already got, try to get the configuration
right and try it out in a test environment and see how it
performs.  You're going to need to test things out anyway
if you're new to OpenBSD before you go into production.
You may well find that your test box will perform beyond
expectations.  Regardless, you can just move the drive
and whatever NICs you've got into a larger box when
you need to go live.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Need more performance (FreeBSD or OpenBSD)

[Karl O. Pinc]

On 11/03/2007 08:06:10 AM, Peter N. M. Hansteen wrote:


It would be interesting to hear any data that comes out of tests like
that.  That is, as long as the OP doesn't mind being a guinea pig.


I don't know enough about internals to know whether it would really
make a difference, but it occurs to me that if you're looking
for raw number-of-interrupts performance it might be better to
get one of the older chips that runs (hot) at a clock speed
closer to 4GHz than one of the newer 3GHz-ish (cooler) multi-
core chips.  Obviously the answer will depend on how well
the software takes advantages of multiple cpus under this
type of load.

In my experience there's nothing like a benchmark of a
real workload.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: ECN congestion with SSL and SSH

[Karl O. Pinc]

On 10/02/2007 08:37:22 AM, Serge Basterot wrote:

Hello list,

I have a problem with a soekris 4801 machine. Outgoing SSL and SSH
connections are impossible with it.


ssh -v (or -vv etc) can be helpful in diagnosing this sort
of problem.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: include macros

[Karl O. Pinc]

On 08/20/2007 11:43:08 AM, Daniel Hartmeier wrote:

On Fri, Aug 17, 2007 at 11:01:20AM -0700, Dylan Martin wrote:

> Or, is there another way around this problem?  A way to make an
> alias for an interface, say?

Interface groups work pretty well for that, see ifconfig(8). In most
cases, the default 'egress' group (containing only the interface where
the default route points out through) is appropriate, and if not you
can
define your own.


I tried this in OpenBSD 4.0 and while it works for rules, it does
not work for queueing.

The 4.0 pf.conf(5) bnf syntax seems to say interface
group names can be used for queueing (IIRC).
Anyone happen to know if I can use interface groups for queueing
in later releases?


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: nat and ftp-proxy on ethernet bridge

[Karl O. Pinc]

On 07/09/2007 07:45:58 AM, Igor Popov wrote:


Bridge works, NAT works, but problems with ftp - control connection is

established, but data connection is dropped. Of course, without
ftp-proxy
passive ftp works, but some clients need working active ftp too.


I don't know FreeBSD but you might try assigning an IP address to
an interface, _and_ bridging.  Then you could run ftp-proxy.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: No route to host

[Karl O. Pinc]

My random thoughts...

On 07/05/2007 02:09:20 PM, Jeff Santos wrote:


This firewall runs "route -s" because there is a need
to publish RIPv1 routes for these networks.


(You mean routed.)

I'm always suspicious of RIP.  It's so easy for
a rouge device to mess up the whole network.
You might examine RIP logs.  Just a thought.



Now, every once in while I get errors like:

PING 200.132.120.2 (200.132.120.2): 56 data bytes
ping: sendto: No route to host
ping: wrote 200.132.120.2 64 chars, ret=-1
64 bytes from 200.132.120.2: icmp_seq=1 ttl=64 time=0.231 ms
64 bytes from 200.132.120.2: icmp_seq=2 ttl=64 time=0.238 ms
--- 200.132.120.2 ping statistics ---
3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/std-dev = 0.231/0.234/0.238/0.015 ms

I know there is an arp entry for the IP address above.


You could prove it by manually locking an entry in the arp
table and seeing if that makes the problem go away.


I would be really thankful to anyone that can suggest some
possible reason, test, insight.


Bad port on a switch?

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: nat on ip range and ftp-proxy

[Karl O. Pinc]

On 07/04/2007 03:10:50 PM, Попов Игорь Николаевич  wrote:

   Hi,
I have router under OpenBSD, it main purpose is NAT.

some rules from /etc/pf.conf

#...
table   const { 80.0.0.21 80.0.0.22 80.0.0.23 80.0.0.24 }
table   const { 192.168.0.0/25 192.168.10.0/24 }

# NAT
nat pass on $ext_if inet tagged LAN_INET ->   round-robin
sticky-address

#...

# nat marker
pass  in  on $int_if inet from   to !(self) keep state flags
S/SA \
tag LAN_INET queue q_traff

#...

There are 4 ip addresses (aliases) on $ext_if - the first is used for
controlling router, others are used for NAT.
And question is how to make ftp-proxy work in this situation?
Both source addresses for control and data connections must be the
same - many ftp servers deny data connection when control connection
has another ip.


Where are you putting your nat-anchor and rdr-anchor anchors in
the config above?  I'm a bit tired but it seems to me that if
they go above your NAT section things should work.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: PF and forwarding to dmz

[Karl O. Pinc]

On 07/04/2007 03:54:57 AM, Norman Maurer wrote:

Hi all,

we are on the way to migrate some linux firewall to a pf firewall.
After I read the pf faq and manual pages I'm still not sure whats the
best way to replace iptables "FORWARD" rules.
It seems to me that I need one "in" and one "out" rule for each
FORWARD rule. Is this right ?


Right-ish, but there's better ways.


Or whould the prefered way be:
--
block all

pass in on fxp0 proto tcp from any to 1.2.3.4 port {80,443} synproxy
state
pass out on fxp1 proto tcp from any to 1.2.3.4 port {80,443} synproxy
state
--


block all

pass in on fxp0 proto tcp from any to 1.2.3.4. port {80.443} \
  tag WEB \
  synproxy state

pass out quick on fxp1 tagged WEB



More likely you'd use very general tags, like "internet traffic"
(e.g. "tag NET") to pass broad classes of traffic out of an
interface.  That way there's only a few extra rules.
The phrase for this is "policy based".  As the traffic comes
in you pass it and assign it a policy (a tag), then you
use the policy to let it out of the box.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Advice needed for altq rules

[Karl O. Pinc]

On 05/31/2007 07:35:25 PM, ECEG / Daniel Duerr wrote:

  I don't care about bandwidth numbers
and I'm afraid to even set them because I don't want to impose limits  
on my bandwidth.


Specifically, there are a couple scenarios I need help with:
1) Asterisk server inside the colo with a bunch of IAX clients on the  
outside; IAX sends/receives on a single udp port (4569, I believe).   
I need to give these packets really high priority.
2) Web servers inside the colo, traffic comes in on ports 80 or 443  
but leaves on random ports.  I'd like to prioritize web server  
traffic so as to provide the highest throughput on file downloads.


Some thoughts, while I think out loud.

My first suggestion would be to write something and post it
here for comment.

You do have a maximum bandwidth, the speed of your interfaces.
To ignore bandwidth the easiest thing would be priority queuing.

There's probably a 3rd catagory of traffic, empty ack datagrams.
You can assign these with 'queue (q1, q2)' where q2 is your
empty ack queue.  To maximize downloads you want to be sure
the downloading server gets acks quick so it fills the pipe.

Oh and then there's probably ssh, or whatever else you use to
manage the boxes.  Don't want to give that low priority.

(And then there's the "everything else" catagory.  There
must be other traffic or you wouldn't need to prioritize web
traffic.)

So:

1) IAX traffic.
2) SSH traffic.
3) Empty Acks
3) HTTP, HTTPS
4) everything else

Depending on your level of paranoia 1 and 2 can be the
same thing.  It'd probably be a good idea to have ssh
to your firewall box and to your Asterisk box(s)
have the same priority as the IAX traffic, to ensure
that you can always reach the boxes that might be
causing trouble with too much IAX traffic.

You will want to queue on both interfaces.  My experience
has been that the TCP throttling mechanisim works well
enough that throttling back, for example, inbound HTTP traffic
keeps IAX from choking even when the limiting factor is
inbound bandwidth.  (Your inbound HTTP will probably be
download requests, whereas mine is download data, so
the details won't work out the same for you as me.  The
theory works like this:  A large amount of inbound TCP data
can be throttled enough for IAX to work, at least
when the TCP traffic is part of longer lived flows.
Because of the bursty nature of IAX this approach
works best when you know your inbound bandwidth and
throttle so that there's _always_ some room left in the
pipe for IAX traffic.)

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Real-world production experiences with pf please...

[Karl O. Pinc]

On 05/04/2007 05:34:16 AM, Jason Dixon wrote:

 The important thing is to get

quality network interfaces.


The OpenBSD FAQ makes recommendations and there's
periodically a thread on the openbsd misc discussion
list regarding the question so you can check those
archives.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: DNS answers blocked?

[Karl O. Pinc]

On 03/05/2007 01:05:25 PM, Peter N. M. Hansteen wrote:

hard to tell without taking a peek at your actual rule set, but could
it be that you forgot "keep state"


with: flags S/SA


in the pass rules which let your
name service queries through?


the omission of which is a common mistake.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Question about port Forwarding (or Triggering ?)

[Karl O. Pinc]

On 02/10/2007 02:23:42 PM, Arnaud Feix wrote:

Hello,

I am wondering if it is possible to implement a kind of port  
triggering ( http://en.wikipedia.org/wiki/Port_triggering ) in  
OpenBSD.


This is related to what ftp-proxy(8) does.  Perhaps you
could submit a patch that makes it work in a more generic
fashion?  Without really thinking it through myself,
it seems that you'd mostly just need to disable the
parts of the code that peer into the ftp control connection.

Maybe such a patch would also be a way to have multiple
bittorrent clients behind an OpenBSD firewall too.
(I forget the bittorrent protocol details but
recall a similar "another connection back in" sort of
issue.)

Or maybe there's another userspace utility out there
that doesn't come to mind

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Problems with PF Sync (FreeBSD 6.2)

[Karl O. Pinc]

On 02/06/2007 03:16:28 PM, Daniel Hartmeier wrote:


The state entry doesn't get associated with a corresponding rule on
the
backup (because the rulesets are not identical), but with the default
rule instead. This means that aspects of the state entry might stop
working on failover (like route-/reply-to or such), effectively
breaking
the connection.


Just what will be lost if failover happens when the
pf rules are not in sync?  I put a rule on the master
and make sure it's working, the backup gets updated
later.  What would happen if failover occurred while
the pf.conf files were not in sync?  Would all the
rules after the difference fail, or just the
new/changed rule, or what?


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Carp/pfsync kernel panic

[Karl O. Pinc]

On 01/29/2007 09:33:45 AM, Thomas Althoff wrote:

Hi,


My firewall cluster is two simple Dell PowerEdge 750 with Pentium4/256
MB RAM and 4 Intel giginterfaces (em driver).  I have been using the
same hardware since OpenBSD 3.6, upgraded to 3.7 and 3.8 at "release
time". Same procedure when 3.9 was relased and now also with 4.0 and
4.0-current.



Where to start? I normally love my OpenBSD firewalls, but not today


FYI, -current is not stable and may have problems.  You may want to
try -stable.

http://www.openbsd.org/faq/faq5.html#Flavors

Note also that if you've updated your source to -current
with cvs you can't just switch to -stable because the
-current changes will be kept as your modifications.
(I believe, I've not actually tried it.)
You need to start over from 4.0 sources and upgrade
that to -stable.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: FUP implementation in PF

[Karl O. Pinc]

On 01/06/2007 02:46:10 AM, Lada 'Ray' Lostak wrote:


I have some experimence with pf, but mainly as firewall/routers. I
don't
know "where to start" to implement above thing. PF FAQ and others
doesn't help much.


My guess is that if you explained to us what was confusing about
the documentation (http://www.openbsd.org/faq/pf/queueing.html)
we might be able to improve it to the point where you find it
helpful.

FYI, when I read your post I had no idea what FUP stood for.
The industry term is seems to be "quality of service", borrowed
from the telcom industry.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Re[2]: PF - Removing Server from Pool when Service is Down

[Karl O. Pinc]

On 12/13/2006 09:40:03 AM, Sylwester S. Biernacki wrote:

On Wednesday, December 13, 2006, at 15:59:02, Karl O. Pinc wrote:

> OpenBSD has ifstated, which is pretty simple to configure
> state engine.

it's true, but it's unusable here - if machine get 100% cpu load it
won't put down their interface.


ifstatd will run scripts. You'd have to
write various scripts on the load balancer
to monitor various aspects of the webservers.
And various scripts to fiddle with the load balancing
as a result.  The only thing ifstatd would do "automatically"
is detect if one of the load balancer's interfaces went down
for whatever reason.  That _is_ something that
you'd want to do to be through.  You could use
snmp or roll your own for whatever
monitoring plugin scripts you'd need.  All
ifstatd provides is a basic control
framework.   This is an advantage because the state engine
approach makes things nice and modular.
The only limitation is that ifstatd uses polling
for everything but the interface detection.

YMMV.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: PF - Removing Server from Pool when Service is Down

[Karl O. Pinc]

OpenBSD has ifstated, which is pretty simple to configure
state engine.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Bug in pf FAQ?

[Karl O. Pinc]

On 11/30/2006 11:57:30 PM, Daniel Hartmeier wrote:


If you, or anyone else, can suggest a sentence or paragraph to add to
the FAQ that makes this clear, please do.


I think a little additional specificity would make clear
the example-ness of it all.  Like this:

On 11/30/2006 07:14:14 PM, Russell Fulton wrote:




IP Options

By default, PF blocks packets with IP options set. This can make the
job
more difficult for "OS fingerprinting" utilities like nmap. If you
have
an application that requires the passing of these packets, such as
multicast or IGMP, you can use the allow-opts directive:


multicast or IGMP, you can use the allow-opts directive.  E.g. to
pass IGMP packets with options:


pass in quick on fxp0 all allow-opts

pass in quick on fxp0 proto igmp all allow-opts





Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: ext_if, int_if?

[Karl O. Pinc]

On 11/30/2006 04:25:12 AM, Sergey Prisyazhniy wrote:


Yes, Luca :). The think is, that I want, for example, to setup
remote machines
via siteXYtools (also load to pf.conf).
And as you can get, I don't know anything about the remote
NIC's, so in this case
I wana make fully automatical process... :)


This relates to a problem I have, carp failover
of 2 firewalls that do not have identical
nics. Normally, changing the macros in /etc/pf.conf is no big deal,
but in this case you're faced with maintaining
almost-duplicate pf.conf files on
two boxes, files that differ only in the nic cards used.
This is a pain.
(OTOH, _duplicating_ pf.conf ie easy with rsync.)

To think out loud here, suppose you custom configured
/etc/hostname.if and added a description to the interfaces
that indicate the purpose of each interface.
What would be the right way to use that description to
establish appropriate pf macros to abstract those interfaces?

This would still require you know _something_ about the interfaces,
but you'd at least have only one place to maintain the information.

My inclination would be to activate pf manually in rc.local, after
running awk on the output of ifconfig to find out the
right device names, and then feeding the result to m4 to
generate pf.conf from a m4 file.  The flaw here is that any
other sysadm coming in to look at pf.conf would hate me,
even if the generated pf.conf file had a big warning at the
top saying where to look for the real pf.conf file.

The clean solution would be if pf had some sort of #include
mechanisim.  Then the macros that abstract the interfaces could
be written into include-ed files and everything else would be
sane.

Anybody else have any ideas?

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: pf.conf + altq more problem..

[Karl O. Pinc]

(pf is the right list for this.)

On 11/06/2006 06:12:12 AM, Reza Muhammad wrote:

Dear All.

I start with the simple rule set in my pf bridge
machine to limit
bandwidth 3Mbps  from my server on lan to internet and
from internet to
my server on lan

my_server_on_lan="172.16.0.228"
internet="202.x.x.x"
lan = "172.16.0.0/16"



pass out  on xl1 from $my_server_on_lan to $internet \
keep state queue
(int_out)



pass  out  on xl2 from $internet to $my_server_on_lan
\ keep state queue
(int_in)


These rules match only traffic with IP source/destination
addresses of $my_server_on_lan and $internet.
You want to match all traffic passing between
your lan and the internet, entire networks, not just between those
two computers.  (NAT may complicate this depending on where
you've installed your bridge.)

You might also want to use hfsc queueing.  Depending on your
requirements it does borrowing much better.  (I forget the
details, see the list archives.)


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: 'block drop' used, but ICMP unreachables returned anyway...

[Karl O. Pinc]

On 10/13/2006 04:26:04 PM, Martin Gignac wrote:


The way I understand it now I guess I have two options: either use
simple ingress/egress interface + direction policies (like a
NetScreen) but learn to live with the fact that I'll get back ICMP
errors if something is blocked, or else use filters on the ingress
interface based on destination addresses, but at least the packet drop
will be "incognito". :-)


You can probably do what you want by blocking both ingress and
egress, filtering on ingress while simultainously tagging for
egrees, and then filtering egress based on tags.  (Keep state
all the while to allow for return traffic.)

That's the current "best practice" and is explained somewhere
in the pf faq.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

OT: Re: Newbie routing question

[Karl O. Pinc]

(This is really offtopic for the pf list.  You want the
openBSD misc list.)

On 09/20/2006 08:14:56 AM, charles Collin wrote:

1 for a my client's private network reachable via a Cisco router  
linked to a T1.


The IP address of the LAN interface on the Cisco router is  
172.18.254.1 and i cannot change it (i don't own it, it is my  
client's).



I set up /etc/mygate with the default gateway I.N.E.T1.
Now i would like machines on my LAN to be routed towards 172.18.254.1.


Seems to me your default gateway should be 172.18.254.1
because that's what your OpenBSD box is plugged in to.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Need some help tuning PF

[Karl O. Pinc]

On 09/12/2006 05:13:55 PM, Daniel Staal wrote:
Filtering on the other interface will work, but is likely to cause  
further headaches figuring out your rules in the future.  (It doubles  
the complexity of your rules, basically.)


You do not have to nat everything, and you *can* tag on nat, then  
filter on the tags.  Between the two, you should be able to achieve  
the level of control you need.


I always found it easiest to tag on the inbound to the firewall side
of whatever's inititating the connection.  I haven't actually
thought about why in a long time but, offhand, I can't think
of another good strategy when working with tags.  I guess I'm
assuming a "block everything" default.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Need some help tuning PF

[Karl O. Pinc]

On 09/12/2006 02:16:33 PM, [EMAIL PROTECTED] wrote:

> Am Tue, 12 Sep 2006 13:14:13 -0300
> schrieb <[EMAIL PROTECTED]>:
>
> > 19 # ALLOW $PC ACCESS HTTP SERVICE
> > 20 pass out on $ext_if from $PC to any port 80 keep state
>
> You are doing nat. nat occures before filter rules so you have to
> change the rule to the following:
>
> pass out on $ext_if from ($ext_if) to any port 80 keep state
>

Sorry but this example doesn't solve my problem.


It solves half your problem, the half that allows in the return
traffic that's a response to the traffic you send out the external
interface.


Maybe I should block the internal incoming packets to PF at $if_ne3, I
mean by deleting this rule: 'pass in quick on $int_if from
$int_if:network to any keep state' and creating a new one for every
specific internal host that I want to allow in a restricted way access
to the Internet.


One rule that uses a table to allow access to port 80 would be better.

Start with one rule that allows one pc.  Then substitute in a table.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Site-to-Site VPN with overlapping RFC1918 addresses

[Karl O. Pinc]

On 08/21/2006 02:04:02 PM, Steve Chinatti wrote:

Won't that be an issue for the firewall?  It would RDR the packet in
order to change the destination address to 192.168.x.x (for a packet
destined for the tunnel), but the firewall also has routes to the
internal network for those addresses.


I think my thoughts were not fully developed.
I'm a little hazy on the addressing you're currently using
and which device is doing what

I think the flaw in my scheme is the RDR, which will mess
with the destination IP and so make it impossible to get
the packet where it ultimately needs to go.  My first thought
was to use a "route-to", which wouldn't have such a flaw,
but I saw that NAT didn't have a route-to option so I tried
a RDR but that's wrong.  Maybe
a separate pass firewall rule with route-to will do the trick?

My understanding of route-to is that it'll get the packet delivered
to the right MAC address on an attached LAN without messing with
the packet contents.  If this is right then so long as the
external address on your firewall is globally unique (or you
make an alias you NAT to that is) then this _should_ work.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Site-to-Site VPN with overlapping RFC1918 addresses

[Karl O. Pinc]

On 08/18/2006 10:24:29 AM, Steve Chinatti wrote:

Hello PF List,

I'm hoping someone can help me out with my configuration issue.

 The problem is that there is

overlap in the private RFC1918 addresses used in both sites.  Let's
call them
SiteA and SiteB.

 I only need to connect from

SiteA->SiteB (i.e. connections will never be initiated from
SiteB->SiteA, but of course sessions initiated from SiteA will have
return traffic...).

SiteA (my site) is using a OpenBSD PF firewall with multiple
interfaces (internal, external, DMZ).  The DMZ uses a non-conflicting
address (not in the 192.168.0.0/16 range), but the internal hosts use
the 192.168.0.0/16 network.


Couldn't you NAT on your external interface and then rdr the
result to the PIX and have that route the traffic through the
tunnel?

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: shell script troubles using expr ("non-numeric argument")

[Karl O. Pinc]

On 07/27/2006 02:51:15 PM, Peter wrote:

I am writing a shell script to handle simple IP accounting and I'm
getting an error I cannot solve.  Here is the pertinent snippet:

PORT_IN=$(pfctl -sl | grep $i | grep $LABEL | cut -d ' ' -f 9)#
bytes
PORT_IN=$(echo "scale=3; $PORT_IN / 1024" | bc)   #
kilobytes
PORT_IN_SUM=$(cat $IN_DIR/$LABEL) #
current value
PORT_IN_SUM=$(expr $PORT_IN_SUM + $PORT_IN)  # add new
value
echo $PORT_IN_SUM > $IN_DIR/$LABEL   #
send
back to file



+ expr 0.000 + 0.000
expr: non-numeric argument


I've not tried to scroodle what you're trying to do,
but expr is integer-only.  That's your problem.

When faced with problems that look like this I usually
use awk with a awk script on the command line
mixed in with the regular shell scripting.
Mostly because it's not perl so there's
an upper limit to how crazy the script can get.

Regards,

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Using BGP to multihome on links of different bandwidth

[Karl O. Pinc]

On 07/25/2006 08:46:49 PM, Alex Thurlow wrote:

We currently have 2 links that are shared via BGP.  One is an OC-12,  
and the other is 100Mb ethernet.


Under just a normal BGP setup, our 100Mb line would be saturated as  
it attempted to send traffic there based on routing distance.


  My question
is, is there a way to share these 2 lines and not saturate the  
smaller one?


There's probably a way to use the "probability" parameter
in conjunction with "route-to", especially if you're doing
policy based routing.  However, that's off the top of my head.
I've not tried any such thing and am a BGP noob so can't say
what the interactions are there.  Seems to me you might need
to abandon BGP.  If so, one way to go is to partition the internet
with 2 static routes, and poke at it with a stick until
you get the bandwidth balance right.

Also, it's not clear to me how you're going to keep the
inbound traffic from saturating the link, unless you're
nat-ting or something and do the "probability" with that.

Regards,

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: controlling ext. inbound traffic on int. interface - few doubts/thoughts

[Karl O. Pinc]

On 07/17/2006 04:14:56 PM, Michal Soltys wrote:


Back to my point: with limited inbound traffic (by isp) to 1mbit, the
incoming traffic is just some traffic. If whatever comes in, assigned
to ext_bulk1 saturates a bit ext_bulk2 - total traffic will be still
1mbit, and there won't be any hmmm, strain to suddenly limit ext_bulk1
in favor of ext_bulk2 - as far as I understand, borrow options on both
subqueues will just make PF adapt to current shape of whatever in that
1 mbit comes back through fxp0 and fxp1 to internal hosts. If borrows
were not there, then it could work, assuming participating host(s)
would behave and slow down.


I can't say I know enough to fully answer your question, but, from
experience:  1) You are more likely to get what you want using
hfsc queues than cbqs -- they work with latency, not just bandwidth.
This makes a big difference in perceived response to new traffic.
2) You need to limit your altq bandwidth to less than your isp
bandwidth or new traffic that could alter traffic shaping might
not get a chance to make it through the ISP's pipe and thence
to your filter.  Try, for example, limiting your total bandwidth
to 0.9Mbps for a 1Mbps pipe.  This reserves 0.1Mbps for 'new'
traffic and gives altq a chance to try to throttle 'old'
traffic to make way for the new.  More 'spare' bandwidth means
more rapid filter adaption to new traffic, but I can't say
what a good balance is.

Regards,


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: PF+ALTQ and WFQ

[Karl O. Pinc]

On 07/14/2006 03:17:22 AM, N.Kalev wrote:

I have a simple question is anyone up to the point of integrateing pf
support of WFQ or is it planned to be done anytime soon :-) ?
I found WFQ in freebsd very helpfull for my tasks but i have to use
ipfw+dummynet+pf to make config nice working :-)))


I'm not up on WFQ but did you try hfsc?


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: ALTQ for a process running on PF box

[Karl O. Pinc]

On 07/12/2006 02:33:12 AM, Daniel Hartmeier wrote:


We recently had a lenghty thread about the disadvantages (requiring
separate hosts) of lacking inbound queues


FWIW, I've put a separate OpenBSD host in front of my firewall/router
(which has several internal nics)
just for inbound queuing in order to support prioritization of
voip traffic and it's been working well for several months now.
(The real trick was hfsc queuing in rather than cbq.  I'm
sure priority based queuing would work as well.)
So, in practice, the tcp rate limiting successfully throttles
the sender that's on the far end of the narrow pipe.

One of these days I really will do some stats to prove it
works in the hopes that somebody will implement inbound queuing
so I can get rid of the extra box.
(Unless somebody's already planning to support inbound queuing?
Hope springs eternal.  :-)

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Open BSD 3.9 Pf issue with email with attachments.

[Karl O. Pinc]

On 06/26/2006 09:17:33 AM, Ajith Kumar wrote:

"Ajith Kumar" <[EMAIL PROTECTED]> writes:

 I am able to send and receive mails . But if there is any
attachment
which
 is bigger than 64 KB, i am not able to send.

"Peter N. M. Hansteen" Writes :

>My first impulse is to look at what happens elsewhere, in no
>particular order, any content filtering or for that matter hard
>message size limits, network congestion on the way there causing
>timeouts etc.

"Ajith Kumar" <[EMAIL PROTECTED]> writes:

There is no problem in n/w congestion.If i disable pf by " pfctl -d "
I am
able to send mails
with attachments. There is no problem in mail server also.


This has a feel to it of what happens when you have a pf.conf
file that keeps state but does not use "flags S/SA", so
(if I understand correctly) the state tracking mechanisim
gets out of wack because it starts tracking in the middle
of a flow.  There was something about this on the pf list
in the last couple of months.


Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: PF issues between interfaces

[Karl O. Pinc]

On 06/22/2006 06:53:47 PM, Jascha Dub wrote:

I am in the process of seeting up a firewall for our datacenter.



The issue I am having is I can ping internal and externals from the
firewall.  But can not get out from my internal servers.  I'm sure it
is something pretty simple I am over looking.



nat on $ext_if from any to any -> ($ext_if)
binat on $ext_if from $dnsServer to any -> $dnsExternalIp	# nat  
external traffic

binat on $ext_if from $web_servers to any -> $web_serv_ext



block log all



pass out on $ext_if proto { tcp, udp } from $internal_nets to any  
keep state


The nat is done before the  "pass out" is evaulated, so they
don't come from $internal_nets any more.

You're better off tagging each rule and then using a
tag to allow datagrams out of the firewall. Offhand (may not
be really right):

pass in proto tcp from any to port ssh tag UNIVERSAL flags S/SA keep  
state
pass in on $internal_if proto tcp from any to port http tag EXTERNAL  
flags S/SA keep state
pass in on $dmz_if proto tcp from any to port ntp tag EXTERNAL flags  
S/SA keep state

...
pass out on $net_if tagged EXTERNAL keep state
pass out tagged UNIVERSAL keep state

Also, translation rules are "first matching" so I wouldn't expect
your binats to be seen.

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein