Re: IPSEC documentation

Hello from all, good morning. I wrote a little article speaking about VPN in FreeBSD, called "VPN Solutions integrating Linux, FreeBSD and Windows": http://www.linuxrapido.org/modules.php?name=Sections&op=viewarticle&artid=95 Well, I can't saw the start from this thread, but I have some things to

Re: IPSEC documentation

On Fri, Jan 20, 2006 at 09:53:33PM +, Brian Candler wrote: > > On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > > If we would also have NAT-T support, FreeBSD would be the best choice > > > of VPN concentrator. > > I just saw this patch posted on the ipsec-tools-devel list: >

Re: IPSEC documentation

> On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > If we would also have NAT-T support, FreeBSD would be the best choice > > of VPN concentrator. I just saw this patch posted on the ipsec-tools-devel list: http://ipsec-tools.sf.net/freebsd6-natt.diff It's for FreeBSD 6 but also

Re: [fbsd] Re: IPSEC documentation

Jeremie Le Hen (jeremie) writes: > > I personally find the gif(4)/transport mode setup neater than the > single tunnel mode - though I am not aware of initial constrains > when IPSec RFCs were written - especially because one can look after the > traffic going through the VPN link in a very natura

Re: [fbsd] Re: [fbsd] Re: IPSEC documentation

Hi Phil, > > I personally find the gif(4)/transport mode setup neater than the > > single tunnel mode - though I am not aware of initial constrains > > when IPSec RFCs were written - especially because one can look after the > > traffic going through the VPN link in a very natural way. I forgot t

Re: [fbsd] Re: IPSEC documentation

Hi, Brian, Eric, > I still think that gif + IPSEC tunnel mode (as currently documented) is not > a good approach, especially if it's the *only* mode of operation to be > documented and hence implicitly recommended as the 'right' way to do it. AFAIK, using both gif(4) and IPSec tunnel mode is actu

Re: IPSEC documentation

Brian Candler wrote: > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > This is a really str

Re: IPSEC documentation

On Fri, Dec 30, 2005 at 12:17:08PM +, Brian Candler wrote: [simultaneous negociations] > You could have a crypto accelerator card even in a low-end CPU. Yep, but it doesn't help so much, for the same reasons. Crypto accelerator for IPSec traffic is really more important ! > My concern is wit

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 01:38:15PM +0100, VANHULLEBUS Yvan wrote: > > "Known issues: > > - Non-threaded implementation. Simultaneous key negotiation performance > > should be improved." > > > > I think that would limit its usefulness as a scalable concentrator, if the > > comment is still valid

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 01:35:21PM +0100, VANHULLEBUS Yvan wrote: > > As it happens this FreeBSD box is also acting as a NAT gateway using pf > > (myhost is on a private IP) and actually its external IP is also private - > > it sits behind a second NAT firewall. So maybe that's where the problem >

Re: IPSEC documentation

Hi, This now goes a little bit off topic from original subject of IPsec documentation, but we have made an implementation of the BEET (A Bound End to End Tunneling) mode IPsec on FreeBSD 5 and 6 (http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-04.txt). The implementation is pa

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 12:25:49PM +, Brian Candler wrote: > On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > > If we would also have NAT-T support, FreeBSD would be the best choice > > of VPN concentrator. > > /usr/ports/security/ipsec-tools/pkg-descr says: > > "Known issues:

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 12:14:00PM +, Brian Candler wrote: > On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: [] > > ports/net/sl2tps > > I was rather surprised that I just got IPSEC tunnel mode working between > Windows XP and FreeBSD; and then afterwards I also got transport

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. /usr/ports/security/ipsec-tools/pkg-descr says: "Known issues: - Non-threaded implementation. Simultaneous key negotiation performance s

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: > > Did someone tried such a setup ? > > I plan to do so. > > Just have to find ios images that support l2tp and ipsec for my 1601R > or 2611 and bigger flash modules (I've been given them two weeks ago, > hardware upgrade is the easy p

Re: IPSEC documentation

On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > Hi. > > VANHULLEBUS Yvan wrote: > >>- L2TP + IPSEC transport mode (= Windows road warrier) > >Did someone tried such a setup ? > >is there a L2TPD daemon running on FreeBSD which could be used for > >that ? > I'm successfully using se

Re: IPSEC documentation

"Clark Gaylord" <[EMAIL PROTECTED]> writes: > Yeah, what is the story with that anyway? Is anyone working on it? Is > there hope? Iirc, Yvan made a patch (don't remember the target branch, sorry), but it seems that NAT-T might be patent encumbered (*). Anyway, Net & Open included NAT-T in their

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: Hi, > security/vpnc works fine for me as a client for talking to a Cisco VPN > concentrator. I think that's IPSEC tunnel mode + PSK + XAUTH (which can also > assign an IP address and insert routes into your forwarding table) Ok, you just need a vpn3000 o

Re: IPSEC documentation

On Thu, 29 Dec 2005 09:50:47 +0300, "Alexey Popov" <[EMAIL PROTECTED]> said: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. Yeah, what is the story with that anyway? Is anyone working on it? Is there hope? --ckg -- Clark Gaylord Blacksburg, VA US

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: Hi, > OK, I'll buy gif + IPSEC transport mode as an option. Seems there's a rfc about this kind of setup : http://rfc.net/rfc3884.html -- Juste un truc, ca te ferait mal au cerveau de lire les messages auxquels tu reponds ? -+-RMD in :

Re: IPSEC documentation

Hi. VANHULLEBUS Yvan wrote: - L2TP + IPSEC transport mode (= Windows road warrier) Did someone tried such a setup ? is there a L2TPD daemon running on FreeBSD which could be used for that ? I'm successfully using security/racoon and net/sl2tps with Windows XP/2003 L2TP clients. I've tried pre-

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 05:43:39PM +0100, VANHULLEBUS Yvan wrote: > > Also excellent would be "bump in the wire" bridging, where the gateway > > negotiates transport-mode security on behalf of clients without their being > > aware of it, but as far as I know only OpenBSD supports that. > > What is

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 05:15:39PM +0100, Eric Masson wrote: > Brian Candler <[EMAIL PROTECTED]> writes: > > > OK, I'll buy gif + IPSEC transport mode as an option. [Although in that > > case, perhaps what you want is an external IPSEC tunnel mode implementation > > which attaches to a 'tun' devic

Re: IPSEC documentation

Brian Candler wrote: On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: gif/gre tunnels and ipsec transport mode are quite convenient when associated with dynamic routing protocols. OK, I'll buy gif + IPSEC transport mode as an option. [Although in that case, perhaps what yo

Re: IPSEC documentation

VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes: Hi Yvan, > Did someone tried such a setup ? I plan to do so. Just have to find ios images that support l2tp and ipsec for my 1601R or 2611 and bigger flash modules (I've been given them two weeks ago, hardware upgrade is the easy part, for software,

Re: IPSEC documentation

Hi all. Coming a bit late in the discussion, but I guess I can provide some infos On Wed, Dec 28, 2005 at 03:31:06PM +, Brian Candler wrote: [] > I would like to rewrite this document (or see it rewritten) to include: > > - Gateways with IPSEC tunnel mode and static keys Well, this

Re: IPSEC documentation

On Wed, 28 Dec 2005 10:08:54 -0500, "Matt Emmerton" <[EMAIL PROTECTED]> said: > (which is already encrypted via HTTPS, but you can't be too safe!) Yes and no. There are substantial support and performance costs every time you encrypt. You can figure that encryption will cost you about 1/3 of you

Re: IPSEC documentation

On Wed, 28 Dec 2005 16:04:04 +0100, "Phil Regnauld" <[EMAIL PROTECTED]> said: > Yes, here using tunnel is indeed odd, it would make more sense > of using IPIP or just GRE in transport mode. I have often used GRE+IPsecTransport -- this allows routing protocols, link state (if you have G

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: > OK, I'll buy gif + IPSEC transport mode as an option. [Although in that > case, perhaps what you want is an external IPSEC tunnel mode implementation > which attaches to a 'tun' device. That's yet another category which I hadn't > even considered] Any u

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote: > > This is a really strange approach which is almost guaranteed not to > > interoperate with other IPSEC gateways. > > It's probably for FreeBSD <-> FreeBSD setups, where it might make sense > to have an interface endpoint

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: > gif/gre tunnels and ipsec transport mode are quite convenient when > associated with dynamic routing protocols. OK, I'll buy gif + IPSEC transport mode as an option. [Although in that case, perhaps what you want is an external IPSEC tu

Re: IPSEC documentation

On Wed, Dec 28, 2005 at 10:08:54AM -0500, Matt Emmerton wrote: > While correct, note the scenario for which the configuration is describing: > > 14.10.3 The Scenario: Two networks, connected to the Internet, to behave as > one. > > This is something I do all the time to connect retail outlets to

Re: IPSEC documentation

Brian Candler <[EMAIL PROTECTED]> writes: Hi, > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode

Re: IPSEC documentation

> The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > > This is a really strange approach which is

Re: IPSEC documentation

Brian Candler (B.Candler) writes: > The IPSEC documentation at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is > pretty weird. It suggests that you encapsulate your packets in IP-IP (gif) > encapsulation and THEN encapsulate that again using IPSEC tunnel mode. > This is a