On 18 Nov 2002, at 11:03pm, [EMAIL PROTECTED] wrote: > I can say with a fair amount of certainty that neither IPsec nor PPTP > are included in any mainline 2.4 kernel, nor does Red Hat include them.
It wasn't clear if you didn't follow the thread from the start, but we were talking about IPsec and PPTP masquerading support, not the actual PPTP or IPsec endpoint implementations. Of course, the masquerade modules don't appear to be present, either. :-) > There are at least two (VPN masq or X.509 certificates) ways to do IPsec > from behind a firewall, but both still make it difficult, if not > impossible, to have multiple nodes behind the firewall talking to the same > node on the other end (or anywhere?). All X.509 does is eliminate manual distribution of the authentication keys. In fact, AFAIK, X.509 exists outside of IPsec entirely. I cannot see how X.509 would have any impact, positive or negative, on NAT interactions. NAT and IPsec don't get along in three major ways: One is the AH protocol, which authenticates the IP header. Since NAT modifies the headers, all packets passing through NAT fail the AH check, and you can't talk at all. This can't be worked around, except by not doing AH. Fortunately, most people don't do AH anyway. The second major problem is that some NAT implementations just cannot handle IPsec at all. They ignore protocols 50 and 51 completely, or handle them improperly. The only thing you can do in this case is fix or replace your NAT implementation. For software like the Linux kernel, this is generally done with a newer version or an add-on patch. For appliances, sometimes a firmware update will do it. Look for the phrase "IPsec pass-thru"; that appears to be the most common buzzword. The third problem relates to having multiple IPsec endpoints behind a single one-to-many NAT gateway. Since IPsec is designed to hide as much information as possible from third-party observers, there is no handy state information in the packets for a NAT gateway to track. Thus, the NAT gateway has no way of determining which IPsec SPI is associated with which interior node. One approach to solving this problem is interesting: The gateway serializes IPsec SA setup, so it can get an idea of what SPIs are associated with who. Apparently, the Linux kernel IPsec masquerade module does this. I just now encountered references to this, while researching something else. This sounds like a bit of a hack, but I imagine it could work. I'm not sure how it would react if the peer's SA expires, though. Another approach is something called "NAT transversal", or "NAT-T". Basically, it encapsulates IPsec in UDP. Because UDP is nearly universally supported, this works around many goofy things found on today's Internet. Both IPsec endpoints have to support NAT-T for it to work. There may also be security implications which have not been fully considered yet. Despite these caveats, NAT-T is probably the most popular solution to this problem. Linux VPN Masquerade HOWTO: http://makeashorterlink.com/?Z2C413182 (user home page) More information on NAT-T: http://makeashorterlink.com/?H2D452182 (InfoWorld.com) http://rr.sans.org/encryption/NAT2.php NAT-T patch for FreeS/WAN: http://open-source.arkoon.net Note that I haven't personally tried everything I mention or link to here, so be sure to do your own testing and research. But you were doing that anyway, right? ;-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
