The particular case that we're dealing with is when a client exposes a local-to-it subnet that we want to be able to connect to from elsewhere in the OpenVPN network. (Let's say that we're on 10.1.0.x and that the network exposed by the client is 10.22.0.x.) Well, exactly how must the traffic get from here to there? There are two considerations:
- As is always the case with TCP/IP, the local operating system must know to route that IP-address range (10.22.0.x) to the local OpenVPN server "as a gateway." That's what the "route (no 'i')" directive does. So far, this is "basic TCP/IP routing."
- But now OpenVPN needs an additional piece of information that does not exactly correspond to "routing," and yet is very similar. It must know: "which currently-connected client must I send this traffic to, for final delivery to its destination?" This is a piece of information that is peculiar to OpenVPN – the operating system knows nothing of it.
As you see, both the route and the iroute directives are needed, because they serve different purposes. route causes an operating system TCP/IP route to be created, sending the traffic into OpenVPN in the first place, without which (of course) OpenVPN would never see it at all. Then, iroute, occurring in a particular CCD-file corresponding to a presently-connected client, tells OpenVPN where to send the traffic for its next "hop." The two notions are complementary – they work together – but they are different. It's directly analogous to "routing within the 10.8.0.x internal OpenVPN virtual-network," but it doesn't involve the operating system.
Hope this helps!™