> > 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.