Archie Cobbs:
> 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.
While I (very roughly) understand how it could be implemented, I don't
understand how this would work with ESP transport mode. With transport
mode, the IP addresses remain unchanged, so essentially we are using
publicly routable addresses, and commonly these are on the physical
interfaces. How do we make the packets go to esp0 first instead of
directly to the physical interface (where the routing table points them
to)?
Seems to me that we need some trickery routing using shadow routes to
make this work, similar to using gif interfaces with ESP tunnel mode.
This would add another point of confusion and violate POLA. Seems to me
that an esp0 interface is really only useful for ESP tunnel mode. In that
case it should be a point-to-point interface similar to gif.
Perhaps worth mentioning: ESP transport mode over a gif tunnel is
*not* the same as ESP tunnel mode. Having a FreeBSD box with transport
mode/gif work against a non-FreeBSD machine in ESP tunnel mode will not
work.
Helge
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
