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

[Jeremie Le Hen]

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 to add that though both setup basically achieve the same
purpose, they are not compatible and one have to use IPSec tunnel
mode in order to get non-BSD systems work.

> > As Brian pointed out, FreeBSD indeed lacks the enc(4) interface which
> > lives in OpenBSD.  enc(4) is a kind of hook into the tunnel mode
> > providing a natural interface to it.
> 
> 	Linux (FreeS/WAN) has a similar concept with the ipsec interface
> 	type.  IMHO, both modes are useful.  On a very large VPN concentrator
> 	with many tunnels being created and destroyed all the time, and
> 	possible several hundred connections at any given time, the interface
> 	table become big.  Usually with so many tunnels, typical for roaming
> 	clients, I'll filter on the source IP (the remote end) at the
> 	moment of leaving the interface.

Yes indeed, you are right.  I dare to Cc: misc at openbsd.org in order to
get an answer about performances when there are a huge number of IPSec
tunnels.

> 	One could argue that the gif/transport is cleaner in that it doesn't
> 	invent yet another interface type, but racoon/ipsec-tools isn't aware
> 	of it.  The ideal would be to have the possibility of dynamically
> 	creating tun(4) devices representing the tunnel endpoints, if required,
> 	when phase2 has been established.


Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >