RE: Placement of a VPN Appliance

[Ben Nagy <ben.nagy () marconi com au>]

> -----Original Message-----
> From: Crist Clark [mailto:crist.clark () globalstar com]
> Sent: Thursday, 4 January 2001 10:51 
> To: firewall-wizards () nfr com
> Subject: [fw-wiz] Placement of a VPN Appliance
>
>
> Hypothetically:
[you could put the VPN box behind the firewall and pass the right stuff]
> The primary "pros" of this setup are,
>
>   - We still only have one machine to worry about living 
> naked on the 'Net.
>   - Easier conversion from our current setup since we do not need to 
>     change connectivity of our border.

There's not usually much of a config change at the border either way, unless
you're running crossover cables straight from your edge router to your
firewall or something. I guess you might run out of public IP addresses or
something...

> The major "cons" are,
>
>   - Once a VPN user is authenticated an in, he or she is in. However,
>     this is how the present VPN solution works, so it is status quo.

Exactly. And it's not a _good_ status quo, either. Many companies use this
kind of thing to give access to corporate partners rather than trusted
employees, and the in-parallel setup is ugly then.

>   - The VPN appliance expects to be on a border for some reason, and 
>     this configuration confuses it.

Don't let it smell fear. Point your index finger at its head and say, in a
stern voice, "Machine, lie down."

> To me, the best idea would be to put the public interface of the VPN
> on the Internet and hook the private interface directly to an unused
> interface on the firewall. However, distrust of VPN users shared 
> by most security personnel is not shared by all network administrators
> so the firewall restrictions one is allowed put on the 
> incoming VPN users 
> might be so weak as to be pointless. In that case, I would rather put
> the whole appliance behind the firewall so one less box is exposed.

I agree with you. However, even if there are no filters at all, this is the
architecture I recommend, just to allow more flexibility with trust levels
in the future. Who knows when the next project will require limited external
access to be given to a semi-trusted partner?

> My real question comes back to the vendor's assumption that the VPN
> device will be on a border. Is there some obvious reason I am missing
> why putting the "public" interface behind the firewall on the private
> net is bad?

IPSec and NAT? Simpler support from the vendor's point of view? Firewalls
that can't cope with the IPSec protocols? I dunno.

[...]
> The real security concern 
> from my point 
> of view is what happens to the data in the VPN box and what comes out 
> the private interface. If the private interface is naked on 
> your internal
> network, either configuration has the same exposure to authenticated
> external users.

This is the trust paradigm. You need to select authentication strength to
match your level of acceptable risk. There is no way around this. If you can
control what happens to the data coming out of the private interface (eg if
it's on a firewall interface) then you can limit access and choose an auth
method to match that level. If you can't limit access you need to
authenticate as strongly as your security posture requires.

> Hiding the public interface behind the firewall just
> adds an extra layer of protection should a vulnerability in the 
> VPN appliance exist.

Not usually. If there's a vulnerability in the VPN box I'll bet you lunch
that the firewall won't help. Yes, there may be some frag attack or
something, but I really doubt it. Most of the VPN tricks are more likely to
be IPSec protocol implementation screwups, and a firewall can't sanity check
those.

> So, why doesn't the vendor support that?

Depends which vendor. ;)

> I am trying to decide which setup to fight for if I can't get my wish
> to put some real filters between the authenticated users and the 
> naked internal network. Thanks for any opinions.

Go with your instinct - it sounds like you're thinking in the right
directions and your arguments seem logical to me. Never assume that vendors
know more about security than you do - always challenge stuff you think is
wrong.

> [0] Oh, and there is that complete abomination of UDP encapsulated
> IPsec we'll probably have to let through.

What makes you unhappy with IPSec-in-UDP? It seems like a cool hack, to me.
Solves the NAT problem nicely. Yes, there's a performance hit, but that's
the price you pay. I'd actually like to see an RFC / registered port for it,
to tell the truth - just for interop purposes.

> -- 
> Crist J. Clark                                Network 
> Security Engineer
> crist.clark () globalstar com                    Globalstar, L.P.

Cheers,

--
Ben Nagy
Marconi Services
Network Integration Specialist
Mb: +61 414 411 520  PGP Key ID: 0x1A86E304

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards