RE: VPN and NAT

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

OK, that's all pretty ugly.

First of all, when you say "real" IP addresses, I assume that you mean
"someone else's", which creates the problem that you might need to reach
internal addresses as well as the legitimate owner of those addresses.

I am visualising your network as a more complicated version of this:

[in]--(nat)[outgoing DMZ]--(fw / nat again etc)[Internet]

If that's so, then the one thing I _wouldn't_ like to do is add lots of
statics at the border between the in and outgoing DMZ networks to make
internal hosts reachable, because that increases the complexity, and means
that you may have to guarantee that all of these statics are now blocked at
the firewall to prevent Internet people seeing them. It would create a
potential race / correspondance problem between two configs which is almost
always bad. In addition, 0wn3ed DMZ hosts now have a hole they can poke at.

Options:

Terminate the VPN such that users are assigned IPs in the internal (as in
"real / someone else's") range. Things will then work just fine unless they
need to talk to the actual owners of those addresses. Since you don't say
that you're doing full "INAT" or Illegal NAT then maybe this isn't currently
a big problem. You could add filtering to this step, depending on if you can
get some kind of firewall inline between the VPN termination and the
internal net. In a word, this makes the VPN users internal.

Terminate the VPN users in a separate DMZ with separate addressing which is
logically inside and parallel to the normal inside network. Put a firewall
between the in and vpn nets and another between the vpn and outgoing DMZ
nets. The only real difference is that you can NAT the in network to make
hosts available to the VPN users, while VPN users can still reach the actual
owners of those IPs. It also means that these mappings are only ever visible
to people that have authenticated on the VPN.

In either option, always make sure that VPN users are assigned into an IP
range which isn't shared with any other kind of device - this is important
for log and audit.

There are lots of other variants of the above, using added firewalls etc. I
prefer the second option, but it's much more work if you need to make lots
of internal hosts available via static NAT mappings.

bonne chance...

ben

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of Georges Dupont
> Sent: Wednesday, June 04, 2003 10:12 AM
> To: firewall-wizards () icsalabs com
>
> Hello,
>
> One of our customers is planning to allow roaming users to access its
> internal systems, through a VPN (and SmartCard/Radius auth). This will
> mean that the endpoints (laptops and home systems) security must be
> properly controlled, but it's not my current question.
> The customer's network is already segmented, IP filtering and 
> proxies at
> several levels, different DMZ and such.
> The customer is heavily using NAT, since its internal network uses
> 'real' IP addresses. The exchanges between inside and DMZ/outgoing
> proxies gets NATed.
> Currently, NAT is only "used" for outgoing connexions. 
> Nothing from the
> outside goes directly anywhere inside. This could change with the VPN,
> where incoming connexions will reach internal systems.
> So, my questions relates to how to properly setup this incoming stuff.
> Filtering is planned, but should we set up proxies in some VPN-related
> DMZ ? If the need is to reach a few internal systems, we will 
> statically
> NAT their addresses. This does not ensure security, only reachability.
> What measures should be taken to secure those connexions ?
> I must also say there are voices, inside, telling "NAT is be enough do
> not bother uswith anything else". I do not agree at all, but I need
> arguments.
>
> Tia,
> -- Georges
>
> _____________________________________________________________________
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie 
> instantanée de France
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () honor icsalabs com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

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