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

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


  • Subject: [Openvpn-users] [RFC] 2.0-beta10 enhancement: redefine the way "ifconfig-pool" works
  • From: "Kevin P. Fleming" <kpfleming@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 06 Aug 2004 21:57:05 -0700

Here's my network configuration:



10.40.1.0/24                                      10.40.3.0/24
------------| System A |-- Internet --| System B |------------
                               |
                               +------| System C |------------
                                                  10.40.5.0/24

System A is running OpenVPN in "mode server" mode, B and C are clients.

Currently, System A has this in its configuration file:

ifconfig 10.80.1.1 10.80.1.2
ifconfig-pool 10.80.1.4 10.80.1.255
route 10.40.0.0 255.255.0.0
route 10.80.1.0 255.255.255.0
push "route 10.40.0.0 255.255.0.0"
push "route 10.80.1.0 255.255.255.0"
client-config-dir clients
client-to-client

In clients/{file-for-system-B}, there is:

iroute 10.40.3.0 255.255.255.0

In clients/{file-for-system-C}, there is:

iroute 10.40.5.0 255.255.255.0

This is all working as documented. However, note that I had to push a route out to the clients that covers the ifconfig-pool range, because otherwise they would not know how to respond to traffic that originates from other clients (not from beyond the clients, from on the client systems themselves). In addition, I also have to push a route out to the clients that covers system A's ifconfig addresses, for the same reason. I spent quite a bit of time trying to figure out why I could not contact systems on the 10.40.3.0 network from system A, until I realized that the source address of those packets was 10.80.1.1 (as it should be, as that is the local endpoint of system A's tunnel), and system B had no clue how to get packets back to that address (because the only route added to system B's routing table by default only has the two IP addresses of system B's tunnel).

In my case, a single route covers both needs, but there no particular reason why the ifconfig and ifconfig-pool addresses have to be similar. If someone chooses to make them wildly different they'll just be increasing their own confusion :-)

Suggestion:

This could be greatly simplified if the following change was made: ifconfig-pool should not accept a starting/ending address, but instead an address and netmask pair. In addition, it should automatically provide "route" and "push route" commands that cover the specified range, and the server should automatically grab the first /30 from the specified range for its own ifconfig (meaning that specifying both ifconfig-pool and ifconfig at the server would be an error). Example:

ifconfig-pool 10.80.1.0 255.255.255.0

would be equivalent to:

ifconfig 10.80.1.1 10.80.1.2
ifconfig-pool 10.80.1.4 10.80.1.255
route 10.80.1.0 255.255.255.0
push "route 10.80.1.0 255.255.255.0"

The OpenVPN documentation already tells you (in an example) that you have to provide a route command to route the ifconfig-pool space into the server; what it does not say is that you really need to do the same thing for the clients. Given that, is there any particular reason to not just have it happen automatically?

I know this is a non-backwards-compatible change, but since 2.0 is still in beta mode it'd be reasonable to make a change like this if it really makes the product easier to configure and use.

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