> Well, OK, there are *also* issues with key management. But the most
> significant aspect is whether the encapsulation/decapsulation code
> understands it, and that part is in the kernel. To confuse things
> further, there are *two* IPsec implementations to choose from in FreeBSD,
> the one that can use hardware crypto and the one that supports IPv6 (you
> can't have both), and they're not always in sync with respect to bugs and
Shows how much I know about FreeBSD. :) I assumed the KAME stuff was all
that was to be had (which I further assume is the IPv6 code). Since
m0n0wall supports the hifn stuff, I take it the HW crypto branch is whats
> Exactly. But you didn't specify (earlier) that the m0n0wall was supposed
> to be an endpoint.
No I sure didn't, I apologize.
> That's not an RFC, it's a draft. :-) As I said, pretty new.
One would think the word draft (used twice!) would clue me in. I'm an ass.
Oops. Does the fact that some vendors are adhering to this count in my
favor at all? No? I'll shut up.
> How do the "no issues" NAT implementations handle it? With an IKE proxy
> manipulating the NAT tables to key to the proper SPIs? Or with manual
> configuration for specific cases?
Now that I think about it, the devices that have presented no problem to
me all include their own IPSec implementations, so an ALG/proxy is likely
the reason. Nothing was touched in their configs at all, it Just Worked.
Makes sense, now that I take a moment to think about it.
> You could presumably run a NAT-T-aware endpoint *behind* a m0n0wall, but
> if you needed to use m0n0wall's IPsec as well, one or the other would need
> to run on a nonstandard IKE port (unless the cases could be distinguished
> by remote IP).
Yeah but that'd take a considerable amount of effort, for what would
really be very little gain. At present, this is more of an annoyance than
anything else. For giggles I think I'll just hack up the racoon config and
see if it sets itself on fire.
Thanks for the response, and for setting me straight.