Hi,
If you are running VMware 5.x, then you can use the em driver (Intel
Pro/1000) instead, which is far more functional than the lnc driver. To
do so:
1. Shutdown the VMware system
2. Locate the *.vmx file for your virtual machine
3. Open the *.vmx file in your favourite text
Hi,
A> >If interface, that went down, had reported its state then CARP
A> >would had noticed that and would had lowered its priority,
A> >gave up mastering, and became backup. This will be redundant.
A>
A>Is it impossible to add link state reporting to lnc driver ?
A>I think this woul
Hi,
On Tue, Dec 05, 2006 at 08:23:50AM +0200, Ari Suutari wrote:
A> Hi,
A>
A> OK, what would then be the right fix to get things working
A> under vmware ? I run a bunch of servers here and some of
A> them are redundant pairs. We have some pressure to virtualize
A> tho
Hi,
Luigi Rizzo wrote:
ok.
Seen the patch, looks good. It's always nice to see how easy it is to
add new options to ipfw2 :)
Patch has been filed as PR# 82724. I'm putting it to production
machines today.
Ari S.
___
freebsd-net@freebsd.org m
Hi,
Luigi Rizzo wrote:
Seen the patch, looks good. It's always nice to see how easy it is to
add new options to ipfw2 :)
Yes. And what is really nice was the fact that this will
solve my real-world problem also very easily (would
be great if this patch could find it's way to RELENG_5
eventuall
Hi,
Luigi Rizzo wrote:
BTW for the 'setnexthop', the port number does not really make
much sense... though it can be useful as a degenerate 'nexthop' case
to forward to a local port.
Didn't remember to comment on this. I left the port number
possibility there although it is really questionabl
Hi,
Luigi Rizzo wrote:
for the chunk at --- 2951,2987
i think it would be better to reuse the 'case TOK_FORWARD',
by changing the opcode and messages according to the actual command.
Changed.
here too i would reuse the existing code more, e.g. in ipfw_log()
put 'case O_SETNEXTHO
Hi,
The patches which implement both
"ipfw setnexthop" and "ipfw defaultroute" are at:
http://www.suutari.iki.fi/freebsd/ipfw-nexthop.patch
http://www.suutari.iki.fi/freebsd/netinet-nexthop.patch
These are against 5.4-RELEASE - if that causes
too much trouble I can try to generate them aga
Ari Suutari wrote:
ipfw setnexthop g2.g2.g2.g2 tcp from any to any defaultroute
Looking at code, maybe "defaultroute" option should be named
verdstreach ?
Ari S.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.o
Luigi Rizzo wrote:
I really believe the "setnexthop" action is the best approach.
I'll start implementing this approach today if other work permits.
I think I'll also add new rule option "defaultroute" which matches if
packet destination has no specific route in routing table. That would
make i
yes i think you should reuse the tag, just add a new opcode so that
the action is attach the mtag to the mbuf if not there yet
(maybe override its content if you believe you could match multiple rules of
this type) and then continue processing as in a 'count' action.
Differences to "ipfw fwd" se
Hi,
Luigi Rizzo wrote:
i suggest to implement a new action 'setnexthop' which stores the
next hop as an MTAG with the packet (so it is preserved if the
packet gets passed to dummynet).
I took a quick look at how ipfw forward has been implemented.
It seems to use PACKET_TAG_IPFO
Hi,
I sent this to ipfw mailing list some time ago, but
got no response. I would like to adjust ipfw behaviour
with fwd rules to make policy routing easier (ie. make
it separete from filtering rules). I would just like
some input if this makes any sense (or is possible at
all with current design)
(replying to myself again...)
Ari Suutari wrote:
Some more information to this one: This seems to be some kind of
odd routing problem. I just recreated the setup under vmware and noticed
that when the problem occurs the outgoing ESP packets are
flowing on interface that has the default route (em0
looks correct (ie. points
to tun0), but ESP packets don't seem to obey it
(until setkey -F is issued).
Ari S.
Ari Suutari wrote:
Hi,
I have upgraded a vpn server from FreeBSD 4.11 to 5.4-RELEASE.
The box as about 20 vpn connections to other FreeBSD machines,
the physical connection is via
Hi,
I have upgraded a vpn server from FreeBSD 4.11 to 5.4-RELEASE.
The box as about 20 vpn connections to other FreeBSD machines,
the physical connection is via tun0 ... tun20 devices.
Traffic flow is something like this:
my internal net ->
vpn server em1 ->
vpn server ipsec ->
Hi,
I have been trying to get WLAN working on my laptop.
The built-in card is Gemtek WL850, which is using
(as far as I understand) using conexant prism chip.
As there is no driver for this, I have been trying to
use Windows XP drivers with if_ndis.
I have managed to get if_ndis.ko built ok. When I
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
Hi,
With the changes you can chose whether you want to do firewallig before
ipsec processing or after but not both.
I am unsure if I get that right but that's what the ipsec flag in
ipfw2 is for and it is heavily used to filter ipsec encrypted traffic
and the same traffic, tagged to come from an ip
Hi,
But I may be
missing something because I can see no way in firewall rules to
distinguish between the before IPSec processing hook and the after IPSec
processing one. Could you clarify this for me please ?
There is a keyword "ipsec" in ipfw2, which matches if packet has emerged
from ipsec
Hi,
The counters for queue 1 keeps increasing when I do a ftp out even for
non-ACK packets but the other counters for queue 2-4 doesn't move at
all so it seems like everything is going out one queue instead of what
the rules actually say. I have one pipe configured as 480Kbit/sec
which is what rul
Hi,
But that gives us 2 blocks of identical code to maintain. To me that
doesn't
seem The Right Way(tm), but I haven't yet thought of a way that is better.
My pseudo-code was more trying to point out the needed functionality.
I wouldn't say either that just copying and pasting the similar bl
Hi,
I've been pondering the same issue and am currently running 5.3-R modified
in the
way you've described. (diff at http://jodocus.org/ipsec-pfil.diff I'm not
an
experienced kernel-hacker, so use at own risk)
Great, I'll have to try this.
For IPSEC this also means that the resulting ESP and A
ERGIF is set.
Now, ip_output is quite central part in ip stack. I would be happy if
someone
who knows that part better than me could implement this (I can sure test
it easily).
Ari S.
Cheers,
Vince
On Sat, 30 Oct 2004 09:27:50 +0300, Ari Suutari <[EMAIL PROTECTED]>
wrote:
Hi,
I n
Hi,
I noticed that processing order of ipsec and ipfw (pfil_hook) is not
correct for outgoing packets. Currently, ipsec processing is done first,
which makes packets to go through without firewall inspection.
This might be a security problem for someone, but at least it
breaks stateful rule handli
Hi,
On Monday 04 August 2003 17:41, [EMAIL PROTECTED] wrote:
> tcp_outgoing_address 10.24.194.163
> but since the default gateway is to the telco interface, the request is
> sent to the telco.
Maybe something like
ipfw add fwd ggg.ggg.ggg.ggg tcp from 10.24.194.163 to any
Hi,
> * Ari Suutari:
>
> > Here are two small patches (done on 5.1-RELEASE, but should be ok
> > for -current also) which add new "ipsec" flag to ipfw2.
>
> i did not receive any attachments. will this functionality be
> included into freebsd-5 in the fut
Hi,
Here are two small patches (done on 5.1-RELEASE, but should
be ok for -current also) which add new "ipsec" flag to ipfw2.
Rules with this flag match only packets that have
ipsec history (ie. came from ipsec processing). Rules with
"not ipsec" match only non-ipsec packets. Without
the new keywo
Hi,
I have developed two enhancements for racoon.
First one is simple support for 'keepalive' statement
in racoon configuration file, which causes racoon
to keep link up with remote end even when there is
no traffic. It also does this when racoon is started,
which is very nice since it also cause
Hi,
Great to see natd maintained. As original author, I kind of miss
the long command line options (ie. something like
--daemon in addition to -d).
The new code seems to use always a select-recvfrom combination
to get the data. Someone complained to me about the old natd performance
when that wa
Hi,
On Monday 11 February 2002 16:15, Mike Silbersack wrote:
> On Mon, 11 Feb 2002, Alfred Perlstein wrote:
>
> > another way would be to loop doing recvfrom's until EAGAIN is returned,
> > I suspect this may give at least a 2 fold increase in performance and
> > is trivial to accomplish.
>
>
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
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
> dummyet) on emerging packets. These packets should then have a different
> inter
> >
> > Doesn't sound good that IP header with private IP address
> > gets sent to internet. - after all, the 195.168.3.210 host on internet
knows
> > nothing about 10.10.1.2...
> >
> We have discussed this before with Brian and Charles, and have come
> up to an agreement that FIREWALL should bloc
Hi,
Doesn't sound good that IP header with private IP address
gets sent to internet. - after all, the 195.168.3.210 host on internet knows
nothing about 10.10.1.2...
Ari S.
- Original Message -
From: "Bohuslav Plucinsky" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROT
t - ITSD Open Systems Group" <[EMAIL PROTECTED]>
To: "Ari Suutari" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: 16. joulukuuta 2000 13:24
Subject: Re: IPFW & IPsec tunnel mode
> In message <001301c0601e$34cab880$[EMAIL PROTE
36 matches
Mail list logo
