Please respect the Debian Mailing List Code of Conduct, available from http://www.debian.org/MailingLists/#codeofconduct, which states, in part: "When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied." Not only am I not explicitly requesting to be copied, I am explicitly requesting NOT to be copied. Hopefully that's clear enough. On Fri, Dec 17, 2004 at 03:59:36PM -0800, Mike Mestnik wrote: > --- Matthew Palmer <mpalmer@debian.org> wrote: > > [No Cc as per list policy, please] > > > > On Fri, Dec 17, 2004 at 03:51:40PM -0800, Mike Mestnik wrote: > > > --- Matthew Palmer <mpalmer@debian.org> wrote: > > > > 1) IPSec. Large, clunky, and complex, but the "gold standard" for > > VPN > > > > systems. Common implementations for Linux currently require the > > > > endpoint to > > > > be on the periphery of the protected subnet, not inside it (and it > > shits > > > > me > > > > to tears). Windows support available but a little fiddly. > > > > > > > http://www.sandelman.ottawa.on.ca/ipsec/1998/06/msg00122.html > > > Private addresses > > > on the Intranet can be handled by using NAT (network address and > > > port translation) or dynamically assigning the remote host an > > > internal address (as described in the ISAKMP configuration draft). > > > > In what way does NAT-T relate to what I was talking about? > > > <IP for remote computer using Ipsec> SNAT to <Any IP, including one on the > internel network> Doesn't solve the problem. The issue is that the IPsec implementation is incapable of being configured to do the routing that needs to happen to make the packets flow correctly -- primarily due to being a very bodged implementation. Getting the packets destined for the remote end to the local endpoint is a solved problem -- it's configuring the IPsec endpoint to DTRT that's the issue I was referring to. - Matt
Attachment:
signature.asc
Description: Digital signature