From: Dan M. <da...@su...> - 2007-08-29 20:41:35
|
On Wed, Aug 29, 2007 at 10:08:27PM +0200, Emmanuel Dreyfus wrote: > Dan McDonald <da...@su...> wrote: > > > I would VERY much like to see this explanation. Especially given some kernel > > that ipsec-tools supports (e.g. Darwin, and I'm thinking the under-beta MacOS > > 10.5) have NAT-T in transport mode support. (In fact, when we replaced > > 10.5's racoon with 10.4's, things Just Worked (TM).) > > AFAIK, racoon does not fully support NAT-T OA (Original Address) > payloads, which means that it will not be able to distinguish two peers > behind the same NAT. We thought that was the case. It properly selected the correct encapsulation mode in the Payload & Transform fields, but it did not do NAT-OA. The racoon shipped with MacOS 10.4 DID support NAT-OA. Did Apple not contribute that set of changes back to the community? IIRC racoon's under BSD license, if I'm right, we *might* be able to give you NAT-OA. We'd certainly be able to interoperability test it with the (alas, closed-source and goodly-amount OEMed) Solaris in.iked. Does the Linux kernel per se support Transport Mode with NAT? If it does, then someone can fix racoon and a lot of our interop problems (we have a transport-mode-setup remote access app in-house). Thanks! Dan |