RE: Cisco Pix 515E Configuration

[Jason Ostrom <justiceguy () pobox com>]

On Mon, 2004-12-13 at 14:06 -0700, Joe Mazzotti wrote:
<<
The hairpinning problem is a known issue, but I was under the impression
that it was by design because it is a firewall.  I hadn't heard that 7.0
may fix this issue.  Will this be a fix for VPN traffic only?  If it was
general hairpinning fix, then wouldn't the PIX just be a router with an
advanced firewall set?  I'm just curious.
> >

I am sure that the "issue" was it being a firewall by design, which
brings up a good point.  I can think of at least one good reason to
implement this, and that is when you want to use the PIX as a central
hub in a hub-spoke VPN topology, interconnecting remote sites (similar
to what was thought to be the issue in the first post).  And if it is
implemented in 7.0, it isn't a "fix".  I would call it a new feature
instead.  And I don't think the PIX would be considered a router just
because of this.  Hopefully it would not be implemented by default, such
as the "sysopt connection" permit commands, which need to be enabled
explicitly.  The PIX still has a default deny stance overall, and even
if the traffic could hairpin back out the same interface, this is not
the same thing as allowing the traffic by default to forward from one
interface to the next (which a router would do).  It brings up an
interesting question because it made me think: at what point does a
router become a firewall and a firewall a router?  You see an increasing
amount of "new features" in each device.  It reminds me of the term
feature creep / creeping featurism, which can be applied to Infosec as
well.  Features are sometimes added that increase risk but provide more
convenience, especially in software without having proper regression
testing in place.  Do you know why these new features are introduced?  I
think the answer lies somewhere between how much a customer believes
they should buy a VPN concentrator in order to hairpin VPN traffic and
how many want a firewall to remain a pure "packet filtering" device with
no routing capability and no new features.  IN other words, the question
is answered by customer demand.

<< 
True.  And to go a step further, if the switch that the PIX drops into
is a layer 3 switch, then you need not get any more hardware.  Just let
it do the routing for you. One thing worth mentioning though, is that a
VPN in general does not support QoS.  VPN's may carry QoS tagged
packets, but you're passing encrypted packets along an arbitrary source
network (i.e. the Internet).  So you can support QoS at either end of
the connection, but not for the VPN connection itself.  This COULD
effect the voice quality with not many avenues to correct it.
> >

Agreed.  You can never assure QoS over the public network; however, I
was referring to using QoS / TOS bits on the IPSec termination points,
such as the edge VPN routers, which can provide an advantage.  As I'm
sure you know, assuming everything else is equal on two links (net
utilization) between two routers, VPN w/QoS could provide better traffic
shaping than no QoS, yielding better performance of selected
applications tunneled by IPSec, overall.



_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards