[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] [RFC] 2.0-beta10 enhancement: redefine the way "ifconfig-pool" works

  • Subject: Re: [Openvpn-users] [RFC] 2.0-beta10 enhancement: redefine the way "ifconfig-pool" works
  • From: "Kevin P. Fleming" <kpfleming@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 07 Aug 2004 11:02:24 -0700

James Yonan wrote:

Well I think there's an important security principle at stake here.  Namely
that security software should, when configuration variations exist which are
more or less permissive, default to the less permissive state unless
explicitly configured otherwise by the admin.  This is the principle behind
(for example) having firewalls configured by default to block all incoming
connections, until the admin configures them otherwise.

1000% agreed. I do the same thing here, all new systems that are on public IPs default to DROP for INPUT and FORWARD firewall tables until I've decided what to open up (on Linux, obviously).

Enabling client-to-client mode is more permissive than disabling it.  This is
why OpenVPN requires an explicit config file option to enable it and an
explicit route push to set up the return routes.

I didn't see client-to-client as being more or less permissive, only an optimization. It's only more permissive if the server admin has set up forwarding filters between clients and then turns client-to-client on (which bypasses those filters). Unless the admin has set up forwarding filters, client-to-client is not any more permissive than client-to-server. If the admin _has_ set up forwarding filters and then turns on client-to-client anyway, they get to keep all the pieces (and the docs warn them not to do that pretty explicitly).

There is also the issue where you want to push a wider route to the client
than is defined by the ifconfig pool range.  For example, you might want
something like this:

push "route"

OK, I can see your point here. I was working from the point of view of not breaking up /24s into smaller subnets and using them this way, but I can see where if you need to do that then "automatic" route pushing could be a problem.

The other risk of always pushing the ifconfig-pool route to the client even if
it's not needed is that it can break the client's network stack if the pool
subnet conflicts with another subnet on the client.  I personally experienced
this once at a WiFi cafe which was using the same 192.168.x.x subnet
internally as my VPN.  Everything worked fine because my VPN subnet was very
small, so it took priority in the routing table.  But suppose that the server
pushed a large, unnecessary route to my client that (say) was more specific
than the local WiFi subnet (giving it priority), but that also blocked a
critical address such as the WiFi default gateway?

Right. This would be a major snafu, although it can be somewhat worked around by adding a host route to the default gateway in the client's routing table (which I believe OpenVPN already knows how to do, although I've never needed it so I haven't paid much attention).

And to ensure this is always the case, OpenVPN does not push any routes unless
explicitly asked to by either push route or push redirect-gateway.


True, client-to-client is an optimization of sorts, however the example in the
 release notes is essentially clients-only-see-server because it pushes a host
route to the clients refering to the server's local tun endpoint, not the
whole ifconfig-pool subnet:

# Push route to client to bind it to our local
# virtual endpoint.
push "route"

In this example, if client-to-client is in effect, then the clients still won't be able to talk to each other directly because they won't have any route available for that traffic.

I will reword my suggestion then to ask that my example be documented as the "simple" way to set up server mode with ifconfig-pool and multiple clients. There are obviously many more advanced configurations, but for people just starting out if they don't push the routes as I suggested they will run into the same problems that I did and wonder why their network stack is dropping incoming packets (since there is no return route). As you mention above, this sort of configuration is only possible if the subnet being used for ifconfig-pool is not likely to be in use on the local network at the client's end, but I suspect that is not the most common arrangement.

Openvpn-users mailing list