1. personally, i have found that using OpenBSD's isakmpd to implement IPSEC
on FreeBSD 4.4-R works very well.
clients that work include SoftNet's SoftPK, OpenSSH, and PGPNet - i find
that PGPnet to be well implemented.
As a bonus - you'll get a good level of interoperability with other
serv
On a slightly side note, I'd much prefer to see FreeBSD with IPSEC
pseudo-interfaces a la OpenBSD/linux.
I'd much prefer to work with say, enc0, or ipsec1, than mess around with
guf half-tunnels makes complex routing much easier
Just a thought - perhaps a netgraph ipsec node is the w
i've not kept up to date with racoon since late last year -
is it now possible to use racoon with PGPnet roaming clients and use the
"acquire virtual identity" option? I think the protocol is called isamkp-cfg
or ike-cfg.
regards
tariq
intY has automatically scanned this email with Sophos
i too am currently looking into natd - it seems to eat more cpu as the
number of connections it handles goes uip - not just the throughput.
- i'm not an expert but truss, strace and grof show that most of the time
is spent in sendto() ...
... i find this odd becuase recvfrom seems not to
can anyone point me to the kernel source where packets are taken from the
DIVERT socket (natd puts them there) -
i'm finding that sendto() is taking most of the CPU - so i want to have a
look at maybe taking two or three packets from the DIVERT buffer per kernel
loop.
(i'm not an expert at this
attached are some gprof stats - it seems that sendto() is taking most of the
time... does this mean that nothing can be done about it?
what affects the speed of sendto() returning... i have the following boosted
kernel params:
net.local.stream.sendspace: 8192
net.local.stream.recvspace: 8192
ne
i tried altering the code to do teh following:
1. when select returns saying the file descriptor is readable:
2. process 2 packets at a time (recvfrom woould just fail if there were
none left)
3. try this with 3 and 5 packets at a time
Surprisingly (for me) I noticed
thanks for the suggestions, ideas and info everyone...
i'll start by looking more closely at the source code and looking at what
kqueue and kevents actually are (!) before i dive in and change natd.
(for all those who suggested ipf/ipnat - yes i know, but unfortunately natd
if part of a bigg
MAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Matthew Emmerton
Sent: 07 February 2002 21:29
To: Tariq Rashid; [EMAIL PROTECTED]
Subject: Re: squeeze more performance out of natd?
> i've spent a good number of hours RTFMs, trying to make the best of a bad
> situtaion: userlan
i've spent a good number of hours RTFMs, trying to make the best of a bad
situtaion: userland natd instead of kernel-space nat.
the only practical advice i found was to increase the maxusers kernel
option - we're already at 1024 (with plenty of ram to support it). other
advice was to have a st
quick one: can anyone recommend any ADSL _internal_ cards that work well
with FreeBSD 4.4 or will with 4.5?
tariq
intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of th
i know there's been some debate on this... but what is the current thinking
in the light of any possible changes to KAME?
the problem is that classic one: two ipsec hosts negotiate keys.. one's a
server, one's a client... establish SAs and all is well. now, if one ike
daemon is gracefully pulled
oops - sounds liek MPPE encryption is a subprotocol of the compression
protocol... hence the confusion!
t
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tariq Rashid
Sent: 14 January 2002 13:54
To: [EMAIL PROTECTED]
Subject: mpd-netgraph PPTP and MS
an anyone point me to some sample mpd-netgraph (3.3) configurations for
Microsoft PPTP clients...
using encyption... for all win98 up to win2k?
i'm using (with pptp0 up to pptp4, say)...
pptp0:
new -i ng0 pptp0 pptp0
set iface disable on-demand
this is a question about the correct way to handle MTUs and fragmentation
when using IPSEC on FreeBSD4.4R
I'm routing via a local gif0 tunnel which has aliases added to it for
multiple destinations... and the KAME ipsec code grabs the packets just
after they enter the gif0 device. In fact the ip
as recognised in the ports bug report, the isakmpd port for freebsd soaks
up 99% CPU even when no connections have been established - even when in
completely passive-connection mode.
i'm not an expert coder but i think the select() in the main loop (isakmpd.c
main()) is doing this.
is there a
apologies - natd was running on the interfaces which causes the effects.
well - i didn't know that natd didn't respond to ip address changes...
t
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tariq Rashid
Sent: 28 November 2001 14:18
his post is about an IP address not being reflected "on the wire":
Two freebsd 4.4-release boxes are connected over ethernet via a hub (using
nics at 10Mbs).
The hub is simple in that it doesn't do anything fancy like arp proxying or
caching
[ A ] --- --- [ B ]
18 matches
Mail list logo
