On Monday, Jul 14, 2003, at 17:47 US/Pacific, Damien Miller wrote:
Aaron Suen wrote:
Currently, there are two major ways to handle fragmented IP datagrams
in pf:
"fragment reassembly," and "those other ones." I say "those other
ones"
because fragment reassembly is [seems to be] the recommended
I'm relatively new to altq and have a (probably simple) question. I would like to
perform the following:
Multiple groups with different base rates; say the level 1 group will allow you a base
rate of 128k and 5Mb of queuing. The first 5Mb you download would be at 3Mb, after
that the speed woul
>> the default route is to if2. as you see, the point is
>> to symmetrically route inbound dns traffic via if1.
>>
>> but strage things happens: i see incoming packet on if1,
>> state creation, outgoing packet on if3, dns reply incoming
>> on if3, and... nothing else, no outgoing packet neither on
On Tue, Jul 15, 2003 at 07:34:38PM +0300, Alexey E. Suslikov wrote:
> i am seriously confused. should i try GENERIC for completely clean
> tests?
You're possibly the first person to try reply-to with translating states
on vlan interfaces. pf attaches an mbuf tag after doing the state match
and re
On Tue, Jul 15, 2003 at 09:44:32AM -0500, Nicholas D . Buraglio wrote:
> Multiple groups with different base rates; say the level 1 group will allow you a
> base rate of 128k and 5Mb of queuing. The first 5Mb you download would be at 3Mb,
> after that the speed would drop to 128k. Here is the
On Mon, Jul 14, 2003 at 12:37:26PM -0700, Aaron Suen wrote:
> I'm sure there are things I haven't thought through clearly enough when
> considering this topic, but it sounds like it will work to me. And, though the
> payoff for a "typical" computer network is not spectacular, there are potential
Hi,
I have a firewall, and I feel pfctl -ss is taking too long to execute.
I'm wondering if it is his normal behaviour, or if there is something
wrong with my setup, or even I'm too loaded.
I measured the time it takes:
[EMAIL PROTECTED] fmbraga]$ sudo time pfctl -ss | wc -l
29.15 real
On Tue, Jul 15, 2003 at 02:49:34PM -0300, Fernando Braga wrote:
> Can anybody share the time pfctl -ss takes on their machines along with
> how many states it runs ?
---end quoted text---
pfctl -ss|wc -l : 87
time pfctl -ss : 0.07s user 0.17s system 39% cpu 0.612 total
Hoping to be of servi
Fernando Braga wrote:
Hi,
I have a firewall, and I feel pfctl -ss is taking too long to execute.
I'm wondering if it is his normal behaviour, or if there is something
wrong with my setup, or even I'm too loaded.
I measured the time it takes:
[EMAIL PROTECTED] fmbraga]$ sudo time pfctl -ss | wc -
> The other question that came to my mind was, what do you do about overlapping
> or duplicate fragments? I thought about this a little more and realized that
> what you're doing is very similar to one of fragment crop or fragment
> drop-ovl, but you haven't specified which. Once you choose a def
Hello pf,
I've go a firewall/nat machine for my company. We'd been asigned a
/32 so we asked for a /29. But our ISP was so stupid that instead of
routing the /29 to our /32 they are taking back the /32 and the new
default gateway is within the /29 (bastards!). But that's not the
point. I have to
Hi everyone,
I've been testing the following with OpenBSD 3.1 and tomorrow I will do an
upgrade to 3.3 if I can't find a solution. The problem is that it will be
night work because it a company firewall.
Anyway, I'm trying to do a route-to together with NAT. The default route
is on rl0 but I have
> Does anyone know if this is an issue with 3.1 or have a misunderstood
> something? Will a route-to ignore nat rules?
You remember that NAT rules are ALWAYS evaluated before filter rules, right?
Quote from
http://www.openbsd.org/cgi-bin/man.cgi?query=nat.conf&apropos=0&sektion=0&manpath=OpenBS
On Tue, Jul 15, 2003 at 09:09:51PM +0200, Niclas Sodergard wrote:
> Does anyone know if this is an issue with 3.1 or have a misunderstood
> something? Will a route-to ignore nat rules?
Try
nat on rl1 from 1.2.3.4 to any -> rl2
pass out on rl1 route-to (rl2 $gw_rl2) from rl2 to any keep state
> This is another option that's probably better left to sysadmins. Basically,
> "wormhole" reassembles enough fragments to make filtration decisions reliably.
> After than, it effectively falls back on EITHER crop or drop, which should be
> up to the firewall's admin to choose (since it's equally
> OpenBSD has a random TCP timestamp header so an attacker is going to have
> a difficult time predicting when the 10s timeout was first inserted into
> the wheel. Remember PF prunes the whole tree of expired states every
> timeout interval, we don't insert a timeout into the wheel for every
> sta
> I figure, the state timeout system simply removes states that have existed with
> no additional traffic after a certain, knowable amount of time (for instance,
> if TCP.first is 10 seconds, then 10 seconds after that SYN arrives, the state
> is removed). My assumption was that the attacker was c
Thats what I was thinking, but my customer requested this for an apartment complex
application so I figured I'd ask the experts. He was thinking of this because he
claims he saw a product that does this, but it's very expensive. I think I can use
ALTq to do something satisfactory, just not wha
> Say we start PF at second 0. We will prune the state tree every ten
> seconds (10s, 20s, 30s).
> Say we get a packet at time 5s and want to time it out ten seconds later
> at time 15s. But it doesn't. PF will finally prune the table at time
> 20s, notice it has expired, and then delete the sta
> > Currently, AltQ does not keep any per-host statistics/counters. All it
> > can read and update is per-queue values. And even if you'd create one
> > queue per host, it wouldn't care about the amount of past traffic, all
> > it cares about is rates.
I've noticed, however, that ntop (ports/packa
Hello Bryan,
Years of Waldorf Schule for this :-)
All are cross over connections (I'm cheap)
+++--+ +---+
| CISCO || OpenBSD 3.3 | | Linux + qmail |
| router ++FW_NAT+---+ mai
On Tue, 15 Jul 2003 14:52:45 -0700, Aaron Suen wrote:
> One rather odd scenario I concocted was the possibility of an attacker sniffing
> at a point VERY close (i.e. same LAN switch) as somebody using an SSH client.
> Since it's SSH, he can't listen in verbatim, but many SSH clients disable
> Nagl
Hello,
Forgive me in advance if I miss something crucial. And sorry if this is too
long winded.
I have since 3.2-release been having trouble maintaining a VPN client
connection (cisco client/cisco concentrator) when connected from my windoze
laptop through my OpenBSD firewall at home to work. M
23 matches
Mail list logo
