From owner-freebsd-net@freebsd.org  Sun Mar 12 11:01:07 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFA96D08A56
 for <freebsd-net@mailman.ysv.freebsd.org>;
 Sun, 12 Mar 2017 11:01:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 732CC1C70;
 Sun, 12 Mar 2017 11:01:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD))
 (envelope-from <slw@zxy.spb.ru>)
 id 1cn1FI-000MI0-Ak; Sun, 12 Mar 2017 14:01:04 +0300
Date: Sun, 12 Mar 2017 14:01:04 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: Ermal =?utf-8?B?THXDp2k=?= <eri@freebsd.org>
Cc: Hooman Fazaeli <hoomanfazaeli@gmail.com>,
 "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject: Re: ipsec with ipfw
Message-ID: <20170312110104.GI70430@zxy.spb.ru>
References: <58C46AE0.7050408@gmail.com> <20170311221619.GU15630@zxy.spb.ru>
 <CAPBZQG2QuU_oENyzV25kD=SMWiV36tRhyV-gHAPa+kRwoXyuKw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPBZQG2QuU_oENyzV25kD=SMWiV36tRhyV-gHAPa+kRwoXyuKw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Mar 2017 11:01:07 -0000

On Sat, Mar 11, 2017 at 09:53:39PM -0800, Ermal Luçi wrote:

> On Sat, Mar 11, 2017 at 2:16 PM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote:
> 
> > On Sun, Mar 12, 2017 at 12:53:44AM +0330, Hooman Fazaeli wrote:
> >
> > > Hi,
> > >
> > > As you know the ipsec/setkey provide limited syntax to define security
> > > policies: only a single subnet/host, protocol number and optional port
> > > may be used to specify traffic's source and destination.
> > >
> > > I was thinking about the idea of using ipfw as the packet selector for
> > ipsec,
> > > much like it is used with dummeynet. Something like:
> > >
> > > ipfw add 100 ipsec 2 tcp from <lan-table> to <remote-servers-table>
> > 80,443,110,139
> > >
> > > What do you think? Are you interested in such a feature?
> > > Is it worth the effort? What are the implementation challenges?
> >
> > security policies is subject of ike protocol exchange, do you plened
> > to extend this protocol too?
> >
> 
> With the introduction of if_ipsec you can implement such tricks through
> routing.

1. routing don't distribute port/protocol info

2. connected client don't have any preconfigured security policies and
got it by IKE protocol from server. how do you to implement this? for
windows/ios/android clients.