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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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

Jeremie Le Hen-2
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: [hidden email] in order to
get an answer about performances when there are a huge number of IPSec

> 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 >
[hidden email] mailing list
To unsubscribe, send any mail to "[hidden email]"