RE: VPN concentrators

["Ben Nagy" <ben () iagu net>]

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of Patrick Darden
[...]
> If you add up all the 2 cent disagreements with what I have 
> stated, you get a good buck fifty!  Some of it was from 
> people who misunderstood what was stated, but a good bit of 
> it was made by people who understand the issues, and simply 
> disagree--sometimes for obvious reasons.
>
> I think we can sum it up though (concentrating on vpn positioning):
[...]

This thread is one of the regulars, and I think that a fairly strong
idea of the usual opinions has been shown up again.

I summarise the setups a bit differently, and just look at what's before
and after the VPN gateway.

If you're mad, you'll put fiddly bits before, like extra firewalls,
blah, blah blah. There usually isn't very spirited argument with the
assertion that a firewall can't do very much at all useful to filter
traffic before it hits the VPN box. Your basic bastion router idea is
all that would ever be required, because if it can't be detected by a
simple packet filter then it's too much work to worry about it - the VPN
box will drop it, and do so with crypto acceleration.

Putting bits after is often recommended, and people have a million ideas
about where to plug those little blue cables. Connecting the inside of
the VPN box straight to the internal network makes some sense if you
completely trust all users that have authenticated to the VPN box, such
as a "normal" corporate RAS replacement. All the other mad scientist
schemes (connecting to another interface on the fw, having a new
firewall, running each packet through to the mail room so that it can be
printed out and date stamped etc etc etc) arise from varying degrees of
paranoia, which should be properly matched to the varying degrees of
distrust in the VPN users. Essentially, it can't cost; and my _personal_
favourite is nothing before and using a spare FW interface after, even
for fully trusted schemes - you can always enforce no rules to start
with, but you have the capability of adding some later. I really don't
like terminating VPN traffic in a "normal" multipurpose DMZ, though.
That's just shopping for trouble. VPN traffic should have it's own
interface/firewall/"load balanced security gateway solution".

In fact, when doing assessment or designs I internally parse down to
only three of the many drawings you summarised with:

net--vpn--internal == OK for fully trusted
net--vpn--firewall == Better for flexible policy
net--spaghetti--vpn--spaghetti-internal == Fancypants lunacy that
probably looked good on a whiteboard

> rtr is understood to be a bastion/edge router with 
> appropriate acls to stop eggregious traffic such as ddos, 
> dos, spoofs, tears, etc.
[...]
> --
> --Patrick Darden                Internetworking Manager             
> --                              706.475.3312    darden () armc org
> --                              Athens Regional Medical Center

Cheers,

--
Ben Nagy
Network Security Specialist
Mb: TBA  PGP Key ID: 0x1A86E304 

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