Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jul 2012 08:14:56 +0200
From:      Luigi Rizzo <>
To:        Julian Elischer <>
Subject:   Re: PREVIEW - netmap-enabled ipfw
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, Jul 25, 2012 at 10:34:39PM -0700, Julian Elischer wrote:
> On 7/25/12 11:41 AM, Luigi Rizzo wrote:
> >First and foremost: this is just a preview, only usable for testing now,
> >but very very close to working.
> >
> >
> >
> >[...]
> >	connected to
> >	00100 30628621 1408916566 count ip from any to any dst-ip
> >	00100        0          0 count ip from any to any dst-ip
> >	00100        0          0 count ip from any to any dst-ip
> >	65535 30628621 1408916566 allow ip from any to any
> how do you handle rules that require to be able to see routes and 
> socket owners?

I don't, at least not at this level. Let me elaborate.

This project is meant to be used at very high packet rates, and in
a router/switch environment.  Think of it as a first-level defense
against attacks, or a fast NAT device, wich deals with the bulk of
the traffic and forwards the rest to the output interface or to the
host stack.  At the next hop (e.g. in the host stack), you can still
have another firewall instance that does the more complex lookups
such as socket owners, routes and whatnot.

The next step would be to export forwarding information to userspace
so you can lookup routes from there too. In principle it should
not be that hard to listen for updates on the routing socket and
rebuild a forwarding table to be looked up.

One could devise a similar strategy for sockets, providing an
interface for applications to query existing sockets (we have
a sysctl now, i believe) and be notified of creations/destructions
of sockets (similar to routing updates; i don't know if this
is supported, though) and this will make socket info available
to userspace too.


Want to link to this message? Use this URL: <>