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 actually pointless, at least if they use the same outer IP address couple. The routing table is indeed overriden by the IPSec tunnel mode. I tested this in the past and I saw that no packet went through the gif(4) interface. While using tunnel mode, the kernel handles "transparently" a tunnel on which you basically have no further control (impossible to attach a bpf(4) interface, no PFIL_HOOK). 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. Note that it is possible to filter _incoming_ traffic from a VPN running IPSec tunnel mode because the PACKET_TAG_IPSEC_IN_DONE flag is set on the mbuf. You cannot however filter outgoing traffic nor you can know from which tunnel the packet came from when you have multiple tunnels. 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. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
