IPSEC documentation

[Jan Mikael Melen]

Hi,

This now goes a little bit off topic from original subject of IPsec 
documentation, but we have made an implementation of the BEET (A Bound End to 
End Tunneling) mode IPsec on FreeBSD 5 and 6 
(http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-04.txt). 
The implementation is part of our HIP (Host Identity Protocol) code and can 
be downloaded from the http://www.hip4inter.net/ through the download page. 
It might be interesting to include atleast the BEET mode code to the standard 
FreeBSD kernel at some point of time. We have made also modified the input 
handling of ESP to correspond the ESP-v3 where the SA is searched only based 
on the SPI value.

   Regards,
     Jan

On Thursday 29 December 2005 14:35, VANHULLEBUS Yvan wrote:
> On Thu, Dec 29, 2005 at 12:14:00PM +0000, Brian Candler wrote:
> > On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote:
>
> [....]
>
> > > ports/net/sl2tps
> >
> > I was rather surprised that I just got IPSEC tunnel mode working between
> > Windows XP and FreeBSD; and then afterwards I also got transport mode +
> > L2TP working using the Windows client and sl2tps. Zounds!
>
> Very interesting, I'll try that ASAP !
>
> > There is a bug (arguably) in the ipsec-tools port, in that all useful
> > messages are logged at level 'daemon.info', but the default syslog.conf
> > discards these messages. Once that's fixed, debugging suddenly becomes a
> > whole lot easier :-) I've submitted a PR.
>
> Got the mail about the PR, but I curently can't see the PR itself (PR
> database busy). I'll handle it as soon as I'll get the real PR.
>
>
> [....]
>
> > Once up, I can happily ping through the L2TP tunnel and run short telnet
> > sessions but I can't view large web pages, which looks like an MTU issue.
>
> Yep, that is the most probable reason !
>
> > As it happens this FreeBSD box is also acting as a NAT gateway using pf
> > (myhost is on a private IP) and actually its external IP is also private
> > - it sits behind a second NAT firewall. So maybe that's where the problem
> > originates, although I really can't understand where the value of 1380
> > comes from.
>
> 1500 - (pppoe encapsulation ?) - ESP header - L2TP encapsulation....
>
> And perhaps another extra UDP encapsulation may be considered, but I
> guess you probably don't have NAT-T support.
>
>
> Yvan.