Date: Thu, 21 Nov 2002 14:29:53 -0500 From: "Cambria, Mike" <mcambria@avaya.com> To: 'Archie Cobbs' <archie@dellroad.org>, Guido van Rooij <guido@gvr.org> Cc: David Kelly <dkelly@hiwaay.net>, "Patrick M. Hausen" <hausen@punkt.de>, Helge Oldach <freebsd-stable-21nov02@oldach.net>, sullrich@CRE8.COM, greg.panula@dolaninformation.com, FreeBSD-stable@FreeBSD.ORG Subject: RE: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION A ND QUESTIONS Message-ID: <3A6D367EA1EFD4118C9B00A0C9DD99D7E4EF52@rerun.avayactc.com>
next in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: Archie Cobbs [mailto:archie@dellroad.org]
> Guido van Rooij wrote:
> > > An esp0 or ipsec0 device would provide the handle ipfw needs.
> >
> > That is excatly what I wanted to say earlier.
> >
> > But beware: this is only true in tunnel mode.
> >
> > In transport mode, the KAME stack calls the subprotocol handler
> > directly and, unless you set up your ipsec such that the decrypted
> > packets actually are tunneled packets using a gif
> interface, you will
> > never be able to catch the packets with a packet filter!
>
> This should be easy to fix though. Just have esp_input() requeue
> the packets on ipintrq instead of calling
> (*inetsw[ip_protox[nxt]].pr_input)
> directly. Of course, resetting m->m_pkthdr.rcvif to an appropriate
> value ("esp0" or whatever) would have to be done first.
>
> This shouldn't change the functionality in any way, except that the
> unencrypted packet will now pass through BPF and ipfw again.
>
> Note: fixing the ipfw and IPSec interaction is great, but another
> important benefit of fixing all this stuff is being able to use
> tcpdump on esp0 and gif0 to see packets at all of the various stages
> of encryption/decryption and encapsulation/de-encapsuation. We should
> make full BPF support another goal of our redesign.
Would it be possible to also make esp0 look like a real interface too?
One of the reasons to use gif (i.e. IPIP tunnels) with IPsec transport
mode in lief of just using IPsec tunnel mode is to let IP routing see the
tunnel as an interface for routing purposes.
If esp0 could become a point to point link with the endpoints of the
being the "source-dest" used in "spdadd ..... ipsec
esp/tunnel/source-dest/require;"
a (the?) need to do IPsec transport on IPIP tunnels would go away.
MikeC
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A6D367EA1EFD4118C9B00A0C9DD99D7E4EF52>