Re: [Openvpn-users] Own DNS system on company intranet?

[Mike Meyer <mwm-dated-1149632968.0d1935@xxxxxxxxx>]

In <loom.20060601T224256-459@xxxxxxxxxxxxxx>, Matt Bostock <matt@xxxxxxxxxxxxxxx> typed:
> Mike Meyer <mwm-dated-1149551335.86eba5 <at> mired.org> writes:
> > Yes, that's right. If you want to let authorized remote
> > users access your internal network, while keeping non-authorized
> > external users from getting to the same, then a VPN is the right
> > solution.
> Just to give you a more complete idea of what I'm looking to achieve, please see:
> http://openvpn.net/howto.html#policy
> I want to authenticate my staff on the internal network by assigning them a
> specific IP address each (or within an IP range), and then setting the server
> daemons to listen only to certain authorised IP ranges. Would that be vulnerable
> to IP spoofing? Would I need to make sure that different groups of staff are on
> different subnets?

Yes, I think you need to be carefull about IP spoofing here. It's not
something I've really looked into, though.

And yes, you have to make sure different groups of staff are on
different subnets. This is the kind of thing I was talking about when
I said that a VPN is the wrong tool.

Using networks for security is good for broad strokes: sensitive data
is only available on the "green" network, and most of the office is on
the "red" network, and the connections between the two is carefully
controlled: red machines and green machines never talk to each other
directly, but instead go through proxies ("purple" machines) so you
can explicitly control what services get offered, and monitor data
going from green to red for sensitive data, and so on.

On the other hand, this kind of thing isn't very good for fine control
like whether specific users can get to specific services. If someone
moves laterally, you have to reconfigure your network. That's just not
right. It ties permissions to the machines, via the subnet they are
on, which causes problems if people share or borrow machines.  You may
also have to start dealing with revoking keys, which isn't really
something that OpenVPN's key system handles well. OpenVPN does have
user/password authentication, which could help with this - but neither
I nor none of my clients do things this way, so I'm not familiar with
the details.

Most of my clients just use ssh keys for authentication. Those keys
are tied to a user/machine combination. When someone changes groups,
you delete their key from or add it to the master authorized list for
the appropriate groups, and redistribute those files.

Larger clients (with host counts in the thousands) use kerberos,
because that makes the key management even simpler, because keys are
managed centrally.

What this really boils down to is how hard changing things is. Only
you know how often things will change, and hence how important it is
to make changes easy to deal with. Most real-world situations I know
of use a combination of network and user access control mechanisms.

> > The split dns mechanism that others have mentioned will keep those
> > names from being visible to the outside world.  dnsmasq can do all of
> > this for you, either with a TLD you made up, or with your real domain
> > name and names that are only internally visible.
> dnsmasq looks like a nice solution. I'm wondering why I need a DHCP server
> though; does OpenVPN not assign each VPN client an IP for its IP pool? Or would
> I be correct in saying that the DHCP server is necessary in order to assign an
> IP from the server-side LAN? If so, which interface is assigned that IP?

Yes, OpenVPN can assign IP addresses to all the clients coming in via
a VPN. A DHCP server is used to assign IP addresses to machines on the
local network. If all your local addresses are static, then you don't
really need a DHCP server. You can arrange things so that OpenVPN
clients are assigned addresses via your LAN's DHCP server. This
eliminates one pool of dynamically assigned addresses, making managing
things a bit easier. If your DHCP server and DNS server cooperate, it
also means that clients coming in on the VPN will be addressable by
name, which may or may not matter.

> > Note that if your VPN allows the client machines to be on more than
> > one LAN (and if you think it doesn't allow that, you're probably
> > wrong), configuring the client DNS to let you look up internal names
> > on all the LANs you are on is interesting, to say the least.
> Could you elaborate on this, I'm not sure what you mean?

First thing: OpenVPN by default configures things so that the LAN the
machine is physically on is still accessible. It can be configured to
route all traffic through the remote LAN, which means the client can
no longer access the LAN it's actually on. This is done by mucking
with the routing tables. Since the user can change these after the VPN
is up, they can regain access to the local LAN pretty simply. High-end
IPSEC VPN solutions from major network vendors are vulnerable to this
as well.

So let's take a real example. At times I subcontract for a client on
site at the customers office. I'm plugged into the local lan at
customer.example. Mail for things from that client always goes to an
address at client.example, which I get from a server at
client.example's LAN via a VPN. I also connect back to my own LAN via
a VPN for various things. When I work at home, the situation is
similar, but the set of active VPN's is different.

During these times, my laptop is on three different LANs. I access
machines that aren't on the public internet on all three LANs. The
internal name servers at customer.example, client.example and
mired.org don't know about internal names on the other two networks -
and neither does any publicly available server. The question is - how
do I access machines on the remote lans by name? The answer is
non-trivial, and depends on the client platform.

	<mike
-- 
Mike Meyer <mwm@xxxxxxxxx>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users