On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote:
VANHULLEBUS Yvan wrote:
[]
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just returned for normal processing.
Bjoern A. Zeeb wrote:
On Mon, 21 Jul 2008, Sam Leffler wrote:
Hi Sam,
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments
about partial checksum recalculations.
So what has
VANHULLEBUS Yvan wrote:
On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote:
VANHULLEBUS Yvan wrote:
[]
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested the RELENG7 version of the patch, and it works well.
But I noticed a misplaced #endif at the beginning of
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must provide the
user-level code from another place.
The main difference from
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested the RELENG7 version of the patch,
[Larry, I kept you in an explicit CC, even if I guess you suscribed to
the list]
On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Hi.
[...]
My main concern at the moment is the API (pfkey stuff) to userland as
Yvan had stated in
Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must
provide the user-level code from another place.
The
VANHULLEBUS Yvan wrote:
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested
VANHULLEBUS Yvan wrote:
[Larry, I kept you in an explicit CC, even if I guess you suscribed to
the list]
On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Hi.
[...]
My main concern at the moment is the API (pfkey stuff)
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just returned for normal processing.
I noticed this too. But the
On Mon, Jul 21, 2008 at 01:27:05PM -0500, Matthew Grooms wrote:
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just
On Mon, 21 Jul 2008, Sam Leffler wrote:
Hi Sam,
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
partial checksum recalculations.
So what has kept you from reading
I noticed this too. But the only situation that I could think of where a
valid ISAKMP packet will be smaller than this is a NAT-T keep-alive.
These are handled previously in the code path so I don't think there is
an issue from a functional standpoint.
That's what I also supposed when I
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
partial checksum recalculations.
I've never heard of this term used before with regard to NAT-T ( and
neither has
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
This adds only the kernel portion of the NAT-T support; you must provide
the user-level code from another place.
Note for people who are interested:
user-level code comes from ipsec-tools, as for previous versions of
the NAT-T
Sam,
The main difference from the patches floating around are in the
ctloutput path (adding proper locking for HEAD) and decap of ESP-in-UDP
frames. Assuming folks are ok w/ these changes I'll commit to HEAD.
Once this stuff goes in we can look at getting the user-mode mods into
the
Sam,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must provide
the user-level code from another place.
The main difference from the patches floating around are in
Sam Leffler wrote:
Larry Baird wrote:
And how do I know that it works ?
Well, when it doesn't work, I do know it, quite quickly most of the
time !
I have to chime in here. I did most of the initial porting of the
NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every
line of
Larry Baird wrote:
And how do I know that it works ?
Well, when it doesn't work, I do know it, quite quickly most of the
time !
I have to chime in here. I did most of the initial porting of the
NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every
line of code during this
Kevin Oberman wrote:
Date: Sat, 28 Jun 2008 23:13:00 +0200
From: VANHULLEBUS Yvan [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote:
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
I'm planning on committing it unless someone
Date: Sun, 29 Jun 2008 13:07:03 -0700
From: Julian Elischer [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Kevin Oberman wrote:
Date: Sat, 28 Jun 2008 23:13:00 +0200
From: VANHULLEBUS Yvan [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V.
Thanks so much to folks like Bjorn and Yvan who spend the time to do
some tough jobs like dealing with IPsec and being stubborn about
committing things to security tools without very careful audit.
Seconded.
In case you missed it, IPsec is about security, not features. And, in
case you have
I've just started moving a medium IPSEC+gif VPN to one based on OpenVPN.
OpenVPN solved all my problems with IPSEC:
* does not require kernel modules or recompiles
* works over UDP by default (and optionally TCP)
+ only requires a single IP port at each end
* supports compression out of the
And how do I know that it works ?
Well, when it doesn't work, I do know it, quite quickly most of the
time !
I have to chime in here. I did most of the initial porting of the
NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every
line of code during this process. I found no
Replying to the (randomly) last posting in this thread...
Hi,
okay, as patience seems to be a problem with some people and I
do not want to say this on two fronts (public and internal)
here are my comments. Yes, they will not be what you expect
but seriously, as I said before in other
On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote:
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
I'm planning on committing it unless someone can provide a reason not
to, as I've seen it working, needed it, and have not seen any bad
byproducts.
I'd be
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
I'm planning on committing it unless someone can provide a reason not
to, as I've seen it working, needed it, and have not seen any bad
byproducts.
I'd be interested to know how you tested it. NAT-T and IPsec are
non-trivial
George V. Neville-Neil wrote:
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
I'm planning on committing it unless someone can provide a reason not
to, as I've seen it working, needed it, and have not seen any bad
byproducts.
I'd be interested to know how you tested it. NAT-T and IPsec
On Fri, 27 Jun 2008 11:06:19 -0400, George V. Neville-Neil
[EMAIL PROTECTED] wrote:
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
I'm planning on committing it unless someone can provide a reason not
to, as I've seen it working, needed it, and have not seen any bad
byproducts.
I'd
On Wed, Jun 25, 2008 at 07:13:59PM -0500, mgrooms wrote:
[...]
To my knowledge, here are the latest patch sets ...
http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff
http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff
On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer [EMAIL PROTECTED]
wr=
ote:
do you have the ability to test this?
=20
Absolutely. Is this the only thing from preventing it being merged
into=
HEAD?
No. It's a large and
mgrooms wrote:
On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer [EMAIL PROTECTED]
wr=
ote:
do you have the ability to test this?
=20
Absolutely. Is this the only thing from preventing it being merged
into=
HEAD?
No. It's a
On Thu, 26 Jun 2008 12:56:41 -0700, Julian Elischer [EMAIL PROTECTED]
wrote:
mgrooms wrote:
I'm not trying to start a flame war here, but the patch has been
floating
around since before the 5.x days. There just seems to be a dark cloud
hanging over it and I, and no doubt many others, really
On Tue, Jun 24, 2008 at 11:54 PM, Norberto Meijome [EMAIL PROTECTED] wrote:
On Tue, 24 Jun 2008 22:01:46 -0500
mgrooms [EMAIL PROTECTED] wrote:
Is anyone currently looking at the IPsec NAT-T patches? I posted a similar
question several months ago around the FAST_IPSEC + IPv6 integration time
Scott Ullrich wrote:
On Tue, Jun 24, 2008 at 11:54 PM, Norberto Meijome [EMAIL PROTECTED] wrote:
On Tue, 24 Jun 2008 22:01:46 -0500
mgrooms [EMAIL PROTECTED] wrote:
Is anyone currently looking at the IPsec NAT-T patches? I posted a similar
question several months ago around the FAST_IPSEC +
On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer [EMAIL PROTECTED] wrote:
where is the patch?
The version that we use in RELENG_7_0 is located here:
http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain
Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer [EMAIL PROTECTED] wrote:
where is the patch?
The version that we use in RELENG_7_0 is located here:
On Wed, Jun 25, 2008 at 3:33 PM, Yuri Lukin [EMAIL PROTECTED] wrote:
I believe the original author of the patch has one that should work with
current:
http://vanhu.free.fr/FreeBSD/
Even better.
Looks like http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff
might be semi up
Julian Elischer [EMAIL PROTECTED] writes:
Hi,
where is the patch?
It seems that the last patch to -current is available here :
http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff
Maybe Yvan has a more recent patch available (CCed)
--
Ce ne sont que des propositions. Je ne
On Wed, 25 Jun 2008, Julian Elischer wrote:
Hi Julian,
I don't have time to do a lot of work on it, but if you can get me a patch
that applies cleanly on -current
and that you have tested, along with testing other cases (e.g. not compiled
in)
then I can give it a look over and if it looks
On Wed, 25 Jun 2008 12:34:56 -0700, Julian Elischer wrote
Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer [EMAIL PROTECTED] wrote:
where is the patch?
The version that we use in RELENG_7_0 is located here:
Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 3:33 PM, Yuri Lukin [EMAIL PROTECTED] wrote:
I believe the original author of the patch has one that should work with
current:
http://vanhu.free.fr/FreeBSD/
Even better.
Looks like
On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer [EMAIL PROTECTED] wrote:
do you have the ability to test this?
Absolutely. Is this the only thing from preventing it being merged into HEAD?
Scott
___
freebsd-net@freebsd.org mailing list
On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer [EMAIL PROTECTED] wrote:
do you have the ability to test this?
Absolutely. Is this the only thing from preventing it being merged into
HEAD?
No. It's a large and complex
Bjoern A. Zeeb wrote:
On Wed, 25 Jun 2008, Julian Elischer wrote:
Hi Julian,
I don't have time to do a lot of work on it, but if you can get me a
patch that applies cleanly on -current
and that you have tested, along with testing other cases (e.g. not
compiled in)
then I can give it a look
On Wed, 25 Jun 2008 12:34:56 -0700, Julian Elischer [EMAIL PROTECTED]
wrote:
Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer [EMAIL PROTECTED]
wrote:
where is the patch?
The version that we use in RELENG_7_0 is located here:
Scott Ullrich wrote:
On Wed, Jun 25, 2008 at 3:53 PM, Bjoern A. Zeeb
[EMAIL PROTECTED] wrote:
if it would be that easy, it would have happened 2 years ago.
What can we as a community do to assist in making this easier and doable?
that is the question..
NAT-T is a very useful feature, and
48 matches
Mail list logo
