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