RE: linux-ipsec: IPSec & NAT

> ...Since my Windows box

This is the one place where you can actually usefully do NAT on IPSEC packets: where it's done only as a routing aid, on an ESP-only IPSEC connection. (AH will authenticate the addresses in the outer header as well, so you can't mess with them in that situation unless you unmess them before they hit AH at the other end.)

> Now, the problems with IPSec. The IP masquerading module only supports TCP

Correct. IPSEC encrypts/authenticates IP packets, and port numbers do not exist at the IP level. Any port numbers which might be found in inner headers -- for example, a TCP header -- are hidden inside the region which is encrypted/authenticated by IPSEC.

> ...apparently the remote access switch wouldn't respond to ISAKMP/Oakley

I forget whether this is a requirement... and the IKE documents are obscure enough that I'm not going to go wading through them right now to find out! In any case it's a sensible precaution.

> Anyway, it works. I looked at some debugging info, and although they

Note that "authentication" does not imply "AH" -- ESP does authentication too, and normally the sensible thing to do is to use ESP's auth and forget about AH entirely. (This untidy situation is a complex historical accident; it resulted partly from the discovery that ESP is vulnerable to certain kinds of attacks unless its packets are authenticated.)

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

> Now, the limitations. Because there is no "masqueraded port" used, there is

No. That's potentially sensitive information which is deliberately hidden. (There is some interest in having an *optional* way to label packets with unencrypted copies of such information, because IPSEC otherwise defeats a good many arguably-useful tricks done by things like routers, but it's not part of the protocols at this time.)

You've put your finger on the big limitation of a trick like this.

> I'd naturally be happy to share my hacked ip_masq.c code with anyone who's

Careful here. The US government has interpreted "enabling technology", e.g. sockets into which encryption code can be plugged, as being subject to the same sort of controls as encryption code. Masquerading mods for encryption probably qualify, unless, perhaps, they are general-purpose enough to have other uses as well.

                                                          Henry Spencer
                                                       henry@spsystems.net
                                                     (henry@zoo.toronto.edu)