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 natural way.
> 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.
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.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
