[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
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: "James Yonan" <jim@xxxxxxxxx>
  • Date: Sat, 7 Aug 2004 14:30:14 -0000

"Kevin P. Fleming" <kpfleming@xxxxxxxxxxxxxxxxxxxx> said:

> 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.

While I understand your motivation to simplify the ifconfig-pool semantics, I
think there are problems with the approach of making ifconfig-pool assume too
many things about what you want to do.  For one, many users don't want clients
to be able to see each other; only the server.  Such users certainly will not
want to push "route 10.80.1.0 255.255.255.0" by default to clients.

I do agree with you that the release notes should be more clear about the
distinctions between a client-to-client config and a clients-only-see-server
config.

James


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