From owner-freebsd-net Wed Aug 9 10:36:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from web313.mail.yahoo.com (web313.mail.yahoo.com [216.115.105.78]) by hub.freebsd.org (Postfix) with SMTP id B9FFB37BB53 for ; Wed, 9 Aug 2000 10:36:21 -0700 (PDT) (envelope-from virtual_olympus@yahoo.com) Message-ID: <20000809173613.15761.qmail@web313.mail.yahoo.com> Received: from [216.163.6.29] by web313.mail.yahoo.com; Wed, 09 Aug 2000 10:36:13 PDT Date: Wed, 9 Aug 2000 10:36:13 -0700 (PDT) From: Benjamin Gavin Subject: Re: NATD and non-UDP/TCP packets To: freebsd-net@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, --- Garrett Wollman wrote: > < said: > > > Hmmmm... I may be going braindead (P.S. What's an SA?), but will > this > > Security Association. IPSEC cryptographic parameters are indexed on > both endpoints using the tuple , so if you > change either address you have irretrievably corrupted the packet. > (The fact that IPSEC can't be NAT'ed is considered by many people to > be a Good Thing.) I was wondering if this was the case. It looks like this will cause a major problem :(. It looks like their are some conflicting interests in my current setup (i.e. Wanting to be able to access a tunnel from behind a NATing firewall, and not wanting to terminate the tunnel on the firewall itself.) > > > be possible on the same firewall box?? How will the routing work, > ...... > > know if it will apply to this problem :( ). > > I can't parse this. > Hmm, that doesn't make much sense does it :). I mean this: 1. I've setup server to server tunnels to connect 2 networks before, this works great and accomplishes one of the goals of my setup => secure communications between the two networks. 2. Server-to-Server tunnels is not a viable solution for my current problem. Because there may be many customers which want to use tunnelling for remote access, and since customer network numbers may (and cuurently do) collide, I need a solution which allows the clients (on our network) to initiate the connection (to the remote endpoint) through our NATing firewall. => This doesn't seem to be possible using IPSEC tunnels (i.e. Cisco's SafeNET VPN). It appears that these two constraints are mutually exclusive. I can't NAT IPSEC tunnels, and I can't allow generic server-to-server tunnelling. I just wanted to verify that this is the case, so I didn't spend hours going down a dead end. > > It may be appropriate to include (which I missed in my original > message) > > that I am running FreeBSD 3.5-STABLE (mentioned earlier), and that I > > am > > You'll need the KAME kit for FreeBSD 3.5 in order to terminate an > IPSEC tunnel there. Thanks, I'll take a look at this. Ben Gavin __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message