From owner-freebsd-stable Fri Oct 26 8:38:43 2001 Delivered-To: freebsd-stable@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id 852BB37B410 for ; Fri, 26 Oct 2001 08:38:13 -0700 (PDT) Received: from netcom1.netcom.com (user-2inis78.dialup.mindspring.com [165.121.112.232]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA31145; Fri, 26 Oct 2001 11:38:07 -0400 (EDT) Received: by netcom1.netcom.com (Postfix, from userid 1000) id 34F4513456; Fri, 26 Oct 2001 08:37:37 -0700 (PDT) From: Mike Harding To: vita@fio.cz Cc: stable@freebsd.org In-reply-to: Subject: Re: IPFW/IPSEC/NAT interaction issues with 4.4, Bug ??? References: Message-Id: <20011026153737.34F4513456@netcom1.netcom.com> Date: Fri, 26 Oct 2001 08:37:37 -0700 (PDT) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think unfortunately that there isn't a good approach to integrated NAT/IPSEC/IPF(W) because the IPSEC isn't really integrated with the firewall/nat. You could, however, do a mutant version of NATD that worked on the inside interface fairly easily I think... NATing the traffic on the inside interface. We have to solve the same problem ourselves, I would be interested in a working and documented way to get NAT, IPSEC and IPF(W) all playing together nicely. In the short term it is probably easier to add a separate NAT box/router. The ideal scenario would be Internet -> NAT(1) -> IPF(1) -> ipsec -> NAT(2) -> IPF(2) -> inside and inside -> IPF(1)-> NAT(1) -> ipsec -> IPF(2) -> NAT(2) -> Internet but I think that NAT(2), IPF(2) doesn't exist (packet is just accepted, skipping NAT) for input, and IPF(1), NAT(1) don't exist for output.. I think that the actual output goes inside -> ipsec -> IPF -> NAT -> Internet so you can't NAT before ipsec. Note that this is a just a quick look - I haven't heavily analyzed the stack to make sure that this is 100. My proposal was to use 'virtual' interfaces to allow multiple NAT/IPF passes, where you reinject the ipsec output somewhere else, but somebody from KAME really disliked this. - Mike H. X-Envelope-From: vita@fio.cz X-Priority: 3 (Normal) Date: Fri, 26 Oct 2001 12:48:38 +0200 (CEST) Organization: FIO holding From: vita@fio.cz X-SpamBouncer: 1.4 (8/24/01) X-SBClass: OK On 26-Oct-2001 Mike Harding wrote: > > This is a feature - if you don't do this, you can't tell decapsulated > traffic from raw traffic. That was the old config. If you have a > router, you can filter on the inside interface. I suggested inserting > the traffic on a fake interface so you could do more interesting > things like NAT, better filtering, etc, but some KAME folk seemed to > get very upset about this, although I couldn't follow the reasoning... > > - Mike H. Do you mean that "because firewall can't tell decapsulated traffic from raw traffic, firewall is skipped for decapsulated packets" ? Yes, I can filter on the inside interface, but what about NAT? natd must run on the outside interface. I see only one solution for my configuration - skip nat divert for packets outgoing from 10/8 net and they should be esp ecapsulated and configure the opposite host to process packets going back with a 10.x.x.x destination address some way. But if I want to communnicate by esp with a host which I can't configure I'm lost because it will not like my packets from 10/8 net. vita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message