Date: Thu, 21 Nov 2002 13:28:25 +0100 (CET) From: Helge Oldach <freebsd-stable-21nov02@oldach.net> To: hausen@punkt.de (Patrick M. Hausen) Cc: freebsd-stable-21nov02@oldach.net, hausen@punkt.de, archie@dellroad.org, guido@gvr.org, dkelly@HiWAAY.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 AND QUESTIONS Message-ID: <200211211228.gALCSPn4082102@sep.oldach.net> In-Reply-To: <200211210852.gAL8qscD076629@hugo10.ka.punkt.de> from "Patrick M. Hausen" at "Nov 21, 2002 9:52:54 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Patrick M. Hausen:
> > The core problem is that we have a single routing table only, and hence
> > we have a mix of internal and public routes. Consequently we will see
> > both internal and external packets on interfaces. Therefore I don't see
> > the need for an extra interface.
> Well, in this case - what would you suggest to differentiate
> packets that come in for the first time and packets that have been
> decrypted and come in again?
I'd say this is the wrong question... The issue really is at which
point in time the ipfw rules catch in. The FreeBSD paradigm (actually,
KAME) is that a packet is being "pushed back onto the IP stack" after
de-capsulation, which causes the ipfw rules catch the packets *twice*.
This is an interface-centric approach.
Other implemenations follow a packet-centric approach, that is: they
define a flow of operations which are applied to the packets as they
travel through the stack. Again, for example Cisco, the flow for a
packet coming into the router and leaving it through another interface:
· If IPSec then check input access list
· Decryption
· Check input access list
· Check input rate limits
· Check input accounting
· Inspect
· NAT outside to inside
· Policy routing
· Routing
· Redirect to web cache
· NAT inside to outside
· Check crypto map and mark for encryption
· Check output access list
· Inspect
· TCP intercept
Note that ipfw is roughly equivalent to "Inspect". Note also the
distinction between filtering ("input access list") and firewall
("Inspect").
Clearly the original problem that was discussed here would be a
no-brainer with this flow.
Helge
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?200211211228.gALCSPn4082102>