Here an update. While Julian is looking for an netgraph solution,
I looked into Luigi's bridging code. And found something, I believe:
> net.link.ether.bridge_cfg: vr0:0,ed1:0
> net.link.ether.bridge: 1
> vr0: flags=8943 mtu 1500
> inet 192.168.43.1 netmask 0xff00 broadcast 192.168.4
2 points...
1/ apparent;y this should not be needed for bjo:rn's problem.. I'll have
to check more..
2/ it would be a little more complicated than to just use the one2many
(though you may be able to do it if you just used 'broadcast' mode,
but the ethernet card needs to be set into promiscuous mo
the 'all' mode on one2many maybe?
Doc
At 14:58 15-1-2002 -0800, you wrote:
>ok..
>I'll see if I can come up with a way to hook multiple netgraph nodes to an
>ethernet node...
>(but since my daughter was born yesterday I'm a little deistracted at the
>moment :-)
>
>julian
>
>
>On Tue, 15
On Tue, Jan 15, 2002 at 02:58:04PM -0800, Julian Elischer wrote:
> ok..
> I'll see if I can come up with a way to hook multiple netgraph nodes to an
> ethernet node...
Thank you. I don't know if it does matter, but neither ed1 nor vr0 is
involved in pppoe, so the example in /usr/share/examples/ne
Brian, would it be possible to specify to ppp, an arbitrary node/hook on
which to attach the pppoe node?
(instead of, say, xl0:
I'd want to hook to etf0:pppoehook
(which may have been set up beforehand by a script)
(maybe a 'hookname' variable that is "orphan" by default..)
may also allow other
ok..
I'll see if I can come up with a way to hook multiple netgraph nodes to an
ethernet node...
(but since my daughter was born yesterday I'm a little deistracted at the
moment :-)
julian
On Tue, 15 Jan 2002, Bjoern Fischer wrote:
> Hello Julian,
>
> > What happens if you use netgraph bridgi
Hello Julian,
> What happens if you use netgraph bridging?
> (/usr/share/examples/netgraph)
I knew that you would advertise this ;-)
Ok, since I'm already using netgraph for pppoe on the same machine,
I tried netgraph bridging at first. But with netgraph bridging it
was even worse: Not even the
What happens if you use netgraph bridging?
(/usr/share/examples/netgraph)
On Tue, 15 Jan 2002, Bjoern Fischer wrote:
> Hello,
>
> on a NIS and NFS serving machine I bridged two ethernet NICs:
>
> net.link.ether.bridge_cfg: vr0:0,ed1:0
> net.link.ether.bridge: 1
> net.link.ether.bridge_ipfw: 0
Hello,
on a NIS and NFS serving machine I bridged two ethernet NICs:
net.link.ether.bridge_cfg: vr0:0,ed1:0
net.link.ether.bridge: 1
net.link.ether.bridge_ipfw: 0
net.link.ether.bridge_ipfw_drop: 0
net.link.ether.bridge_ipfw_collisions: 0
vr0: flags=8943 mtu 1500
inet6 fe80::250:baff:fe
On Tue, Jan 15, 2002 at 01:34:29PM +0100, Alex Le Heux wrote:
> >
> > But doesn't ipsec stack already take care of this ? I think (hope)
> > that is doesn't process the packet if it is coming from wrong tunnel
> > because the packet does not match the policy.
>
> I'm not sure if it a
On Tue, Jan 15, 2002 at 02:22:17PM +0200, Ari Suutari wrote:
> Hi,
>
> On Tuesday 15 January 2002 14:18, Alex Le Heux wrote:
> >
> > > Maybe one could remove this, add 'ipsec' flag to ipfw
> > > (which would use the above ipsec_gethist to match it)
> > > so the syntax would be something
Hi,
On Tuesday 15 January 2002 14:18, Alex Le Heux wrote:
>
> > Maybe one could remove this, add 'ipsec' flag to ipfw
> > (which would use the above ipsec_gethist to match it)
> > so the syntax would be something like this:
> >
> > ipfw add pass tcp from a to b ipsec setup # m
On Tue, Jan 15, 2002 at 09:42:37AM +0200, Ari Suutari wrote:
> Hi,
>
> On Monday 14 January 2002 19:55, Rene de Vries wrote:
> > Kshitij,
> > A good solution, from my point of view, would be, instead of passing
> > evering thing from an ipsec tunnel, using ip-filter (&co, but without
> > dummye
Hi All
I came across this problem a few months ago, and its mpact is actually
greater than expected. I have ttached a patch below which I have been
running on our production firewalls for 3 months now with no issues to speak
of. The patch includes a sysctl to turn off the reinjection action.
T
Hi All,
What I think is that we shouldn't send all packets to IPSec. This reduces
the performance of the box as IPSec algorithms are really compute intensive.
Only configured tunnels to a few locations can be IPSeced. This ensures
that the normal traffic which is mostly TCP traffic can be as f
15 matches
Mail list logo