I'm personally against modifying ipfw(4) for this purpose. It gets into the
complexity of syntax and simply violates the initial simple model of the whole
ipfw packet filter itself. I agree in that freebsd systems acting as routers
need a more "efficient" or "better" engine by allowing per-interfa
В вт, 14/12/2004 в 13:54 +0100, Andre Oppermann пишет:
> Vladimir Grebenschikov wrote:
>
> > > I know this. We have a well commented firewall scripts, we store them at
> > > RCS,
> > > we do many things to make our life easier. But my practice (and my
> > > collegues)
> > > shows that per inter
Luigi Rizzo wrote:
>
> On Tue, Dec 14, 2004 at 03:23:02PM +0100, Andre Oppermann wrote:
> ...
> > > the struct ifnet. All i meant to say is that we want a unique
> > > key, possibly in a small namespace, to quickly locate the per-if
> > > private firewall info. How the key is used is not a busines
Vladimir Grebenschikov wrote:
>
> ÷ ×Ô, 14/12/2004 × 13:54 +0100, Andre Oppermann ÐÉÛÅÔ:
> > It's about HOW to implement it. I think the ways proposed so far are
> > hackish, too complex and outside of our framework which was very well
> > designed and allows this kind of feature without any of t
On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote:
> Let's take a high level view of the issue at hand and the consider
> some alternative approaches to the situation.
[snip]
I'm wrapping up in Berkeley for the holidays, but I wanted to drop my 2c
into this discussion.
What I'm real
Luigi Rizzo wrote:
>
> On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
> ...
> > > Implementationwise, the kernel side is evidently trivial as the
> > > original code already supports the idea of multiple chains. All
> > > you need is to extend the struct ifnet with a pointer to
0n Mon, Dec 13, 2004 at 09:47:00PM +0300, Gleb Smirnoff wrote:
> Andre, I know your dislikes about Cisco, and I share it too. Idea
> of maintaining separate filter lists for each interface is handy, no
> matter that it is like in Cisco. Before writing this mail I have a lot
> o
Hi,
From: Michael Lednev <[EMAIL PROTECTED]>
Subject: Re[2]: KAME mip6
Date: Mon, 13 Dec 2004 13:25:20 +0300
> Bkin> The latest KAME snap shot of FreeBSD5.3+KAME already have MIP6 code.
> Bkin> However, the code is not the same with the old KAME/MIP6. We are now
> Bkin> rewriting the code as a us
On Tuesday 14 December 2004 15:03, Luigi Rizzo wrote:
> On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
> ...
>
> > > Implementationwise, the kernel side is evidently trivial as the
> > > original code already supports the idea of multiple chains. All
> > > you need is to extend t
On Tue, Dec 14, 2004 at 06:13:07AM -0800, Bruce M Simpson wrote:
...
> What I'm really missing in IPFW is the ability to maintain one or more
> 'shadow rulesets'. These rulesets may not be the active rulesets, but
> I can manipulate them as tables, independently of the active ruleset(s),
??? What
Let's take a high level view of the issue at hand and the consider
some alternative approaches to the situation.
Current situation:
a1. There is a need to have per-interface specific firewall rules.
a2. We have multiple firewall packages which have multiple way to
specify interface specifi
On Tue, Dec 14, 2004 at 02:05:18PM +0100, Andre Oppermann wrote:
A> > A> > (Now I speak only about ipfw. But other filters can be used in same
A> > A> > manner with a very small changes.)
A> > A> >
A> > A> > We have list of rules defined in struct ip_fw_chain. At this moment
A> > A> > we have only
Gleb Smirnoff wrote:
>
> On Mon, Dec 13, 2004 at 10:50:01PM +0100, Andre Oppermann wrote:
> A> > (Now I speak only about ipfw. But other filters can be used in same
> A> > manner with a very small changes.)
> A> >
> A> > We have list of rules defined in struct ip_fw_chain. At this moment
> A> > we
Vladimir Grebenschikov wrote:
>
> ÷ ×Ô, 14/12/2004 × 11:51 +0300, Gleb Smirnoff ÐÉÛÅÔ:
>
> > I know this. We have a well commented firewall scripts, we store them at
> > RCS,
> > we do many things to make our life easier. But my practice (and my
> > collegues)
> > shows that per interface filte
Gleb Smirnoff wrote:
>
> On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
> A> > Implementationwise, the kernel side is evidently trivial as the
> A> > original code already supports the idea of multiple chains. All
> A> > you need is to extend the struct ifnet with a pointer to t
On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote:
A> > Implementationwise, the kernel side is evidently trivial as the
A> > original code already supports the idea of multiple chains. All
A> > you need is to extend the struct ifnet with a pointer to the chain,
A> > or use some other
Hello all,
I like the idea of a system without mem(4) but some system utilities depend
on it. I thought I would go and change them to use other ways to get the
information. I started with 'netstat -r' and almost completely (refcnt field
is missing) removed the need for /dev/mem (in fact there al
Luigi Rizzo wrote:
>
> On Tue, Dec 14, 2004 at 11:51:23AM +0300, Gleb Smirnoff wrote:
> ...
> > Again, this feature is not for all. This is for people who build complicated
> > routers on FreeBSD. It is not going to hurt standard host setups.
>
> Trying to summarise the discussion with a hopefull
Andre Oppermann writes:
>
> I have already the next round in the works which is optimized even more
> by merging consecutive mbuf chains together (at the moment I have packet
> segment chains which have a direct pointer to the mbuf at the end of the
> chain) and which get passed in one go t
Gleb Smirnoff wrote:
>
> Andre, Max,
>
> please don't take this hard. I'm not going to change pfil(4) API,
> since it has everything required.
Great.
> Max, you showed me that pf has some optimizations. ipfw has only skipto
> rule, it helps to reduce CPU consumption, but makes 'ipfw show'
> m
Julian Elischer wrote:
>
> Gleb Smirnoff wrote:
>
> > Dear networkers,
> >
> > I finally managed to pronounce my idea, although I'm afraid
> > of a bikeshed it is going to be burried under.
...
> I'm not sayig we should n't do what you are saying but that it is
> already possible to do very si
Andrew Gallatin wrote:
>
> Andre Oppermann writes:
> >
> > I've got some excellent review feedback from Mike Spengler and he found
> > a off-by-one queue limit tracking error.
> >
> > http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch
> >
Richard A Steenbergen wrote:
>
> On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote:
> > > I'd like to implement per-interface pfil hooks, like in Cisco
> > > world. Each interface may have 'in' list of rules, 'out' list
> > > of rules. Current global ip_{input,output}, filters may co
Andre Oppermann writes:
>
> I've got some excellent review feedback from Mike Spengler and he found
> a off-by-one queue limit tracking error.
>
> http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch
>
Here are the same tests running your new patch in co
Thanks to everyone for their suggestions which included
ng_bridge using ng_ksocket or ng_gif
OpenBSD
OpenVPN
It turns out cisco support l2tpv3 on the new routers and it works perfectly,
but is expensive, so I will give these solutions a test !
Tks
.Andrew
-Original Message-
From: [EMA
On Tue, Dec 14, 2004 at 01:56:03AM -0800, Luigi Rizzo wrote:
L> > Again, this feature is not for all. This is for people who build
complicated
L> > routers on FreeBSD. It is not going to hurt standard host setups.
L>
L> Trying to summarise the discussion with a hopefully unbiased position:
L>
L>
On Tue, Dec 14, 2004 at 11:51:23AM +0300, Gleb Smirnoff wrote:
...
> Again, this feature is not for all. This is for people who build complicated
> routers on FreeBSD. It is not going to hurt standard host setups.
Trying to summarise the discussion with a hopefully unbiased position:
As i also sa
В вт, 14/12/2004 в 11:51 +0300, Gleb Smirnoff пишет:
> I know this. We have a well commented firewall scripts, we store them at RCS,
> we do many things to make our life easier. But my practice (and my collegues)
> shows that per interface filters are easier to understand and maintain when
> numbe
On Mon, Dec 13, 2004 at 10:11:25AM -0800, Julian Elischer wrote:
J> I do this now with the current ipfw unchanged..
J> my rules always start with something like:
J>
J> add 100 skipto 1000 ip from any to any in recv fxp0
J> add 101 skipto 2000 ip from any to any out xmit fxp0
J>
J> add 110 skipto
Hi,
I am seeing a lot of ICMP Must Fragment packets with incorrect ICMP
checksums on a RELENG_4 box which holds up 40-60 PPTP (mpd/Netgraph) VPN
connections at any given time. The peer understandably ignores the ICMP
packet with a bad checksum and never fragments the offending TCP packet,
effecti
On Tue, Dec 14, 2004 at 11:53:10AM +0300, Gleb Smirnoff wrote:
> On Tue, Dec 14, 2004 at 10:05:50AM +0200, Peter Pentchev wrote:
> P> I am seeing a lot of ICMP Must Fragment packets with incorrect ICMP
> P> checksums on a RELENG_4 box which holds up 40-60 PPTP (mpd/Netgraph) VPN
> P> connections at
Andre, Max,
please don't take this hard. I'm not going to change pfil(4) API,
since it has everything required.
Max, you showed me that pf has some optimizations. ipfw has only skipto
rule, it helps to reduce CPU consumption, but makes 'ipfw show'
more complicated.
On Mon, Dec 13, 2004 at 03:4
On Mon, Dec 13, 2004 at 05:43:26PM +0100, Max Laier wrote:
...
> > When managing a complex router with many interfaces the output
> > of `ipfw show` (or ipf/pf analog) is getting long and difficult to
> > understand. It is also important that many packets are checked
> > against the rules that can
Peter,
does the problem disappear if you turn ipfilter off, and run natd on this
interface? it is not clear from your mail.
On Tue, Dec 14, 2004 at 10:05:50AM +0200, Peter Pentchev wrote:
P> I am seeing a lot of ICMP Must Fragment packets with incorrect ICMP
P> checksums on a RELENG_4 box whi
ww.nrg4u.com/freebsd/tcp_reass-20041210.patch
Please test and report good and bad news back.
I've got some excellent review feedback from Mike Spengler and he found
a off-by-one queue limit tracking error.
http://www.nrg4u.com/freebsd/tcp_reass-2004121
Gleb Smirnoff wrote:
Dear networkers,
I finally managed to pronounce my idea, although I'm afraid
of a bikeshed it is going to be burried under.
When managing a complex router with many interfaces the output
of `ipfw show` (or ipf/pf analog) is getting long and difficult to
understand. It is als
On Mon, Dec 13, 2004 at 03:49:31PM +0100, Andre Oppermann wrote:
> > I'd like to implement per-interface pfil hooks, like in Cisco
> > world. Each interface may have 'in' list of rules, 'out' list
> > of rules. Current global ip_{input,output}, filters may coexist
> > with per-interface ones, but c
On Mon, Dec 13, 2004 at 05:43:26PM +0100, Max Laier wrote:
> > I'm glad to see any constructive comments on plan.
>
> Sorry, I don't see the point. If you are going to penalize the common case
> for
> this I will object.
On the other hand, if there was a simple (and cheap) way to disable
packe
On Dec 13, 2004, at 4:06 AM, Andrea Campi wrote:
I'd like to live complications such as this for a later stage. I'd say
if you have a multihomed machine you better know how to configure it;
the primary target for my work are laptops and other clients. That is
not to say I don't care; rather, I need
On Monday 13 December 2004 13:40, Gleb Smirnoff wrote:
> Dear networkers,
>
> I finally managed to pronounce my idea, although I'm afraid
> of a bikeshed it is going to be burried under.
>
> When managing a complex router with many interfaces the output
> of `ipfw show` (or ipf/pf analog) is ge
Gleb Smirnoff wrote:
>
> Dear networkers,
>
> I finally managed to pronounce my idea, although I'm afraid
> of a bikeshed it is going to be burried under.
>
> When managing a complex router with many interfaces the output
> of `ipfw show` (or ipf/pf analog) is getting long and difficult to
>
Dear networkers,
I finally managed to pronounce my idea, although I'm afraid
of a bikeshed it is going to be burried under.
When managing a complex router with many interfaces the output
of `ipfw show` (or ipf/pf analog) is getting long and difficult to
understand. It is also important that m
On Wed, Dec 08, 2004 at 11:43:31PM -, Andrew White wrote:
A> I'm looking for suggestions to the problem below, any help appreciated !!
A>
A> I have several offices which use LAT MOP and IPX. This works over the
A> existing WAN as it is a combination of bridging and routing (routed IP ).
A>
A
Current FreeBSD problem reports
Critical problems
Serious problems
S Submitted Tracker Resp. Description
---
o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap
o [2003/10/14] kern
Hi,
All I intend to provide is a way to specify whether you want IPSEC before
or after pfil_hooks. By default it will be as it is today and work
exactly
the same.
OK, this sounds like a good step. Maybe the next step could be third
choice
like 'both before and after' for us who are perhaps
Hello dear All.
I have a very strange FreeBSD box. It was 4.6, now it runs currently 4.11 -
prerelease, cvsupped yesterday, on sunday. However the problem
persists.
The problem is that TCP connections to this BOX with SYN+ENC bits can
not be established. There's another Linux box, that can not se
Hello, B.
On 13 декабря 2004 г., 13:07:26 you wrote:
Bkin> The latest KAME snap shot of FreeBSD5.3+KAME already have MIP6 code.
Bkin> However, the code is not the same with the old KAME/MIP6. We are now
Bkin> rewriting the code as a user space program. (The old KAME/MIP6 is
Bkin> implemented in
Hi,
From: Michael Lednev <[EMAIL PROTECTED]>
Subject: KAME mip6
Date: Fri, 10 Dec 2004 07:14:59 +0300
> is there any chance, that kame mip6 stack will work with freebsd-5.3
> out of the box soon?
The KAME project is now working on Mobile IPv6 support for
FreeBSD-5.3+KAME.
The latest KAME snap s
On Sun, Dec 12, 2004 at 03:25:27PM -0800, Peter Heerboth wrote:
> I'm not a zeroconf expert per se, but I would love to see FreeBSD have
> a great zeroconf implementation. Here are some things to think about.
>
> >
> >If your first implementation happens to leave the interface with a
> >169.254
49 matches
Mail list logo
