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 ret
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
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.
> 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
> 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 n
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
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,
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 onl
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)
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 th
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 m
[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
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 th
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 the
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
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
> th
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 pa
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
For those who may be interested,I ported Sam's changes to FreeBSD7,
the patch is here:
http://people.freebsd.org/~vanhu
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 ar
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 co
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 proce
> 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 secur
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 bo
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 n
> 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
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: 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 s
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.
> >
>
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 contexts:
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
>> byproduc
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 a
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 protocol
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 oth
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 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.
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
> http://vanhu.free.fr/FreeBSD/patch-natt-fr
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
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:
>>
>
http://cvs.pf
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 o
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 compl
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
http://lis
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 http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19
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:
> >
http://cvs.pfsense.org/cgi-bin
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?
Scott
___
freebsd-net@freebsd.org mailin
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 ok
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 n
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 sem
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:
http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-
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 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 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 integra
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
> frame. Maybe now that things have settled a bit, this work can be reviewe
All,
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
frame. Maybe now that things have settled a bit, this work can be reviewed
and possibly committed?
Thanks,
-Matthew
53 matches
Mail list logo
