One of the most-confusing aspects of OpenVPN configuration for me to "grok" was the subject of CCD-files and "i"route. Now that I've finally wrapped my cranium around it, let me try to explain it better than the docs do. [i](Comments and corrections requested.)[/i] The [u]particular[/u] case that we're dealing with is when a [i]client[/i] 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 [b]10.1.0.x[/b] and that the network exposed by the client is [b]10.22.0.x[/b].) Well, [i]exactly how[/i] must the traffic get from here to there? There are [u]two[/u] considerations: [list=1] [*] As is always the case with TCP/IP, the local operating system must know to [b]route[/b] 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 [u]not[/u] exactly correspond to "routing," and yet is very similar. It must know: [b][i]"which[/i] currently-connected client must I send this traffic to, for final delivery to its destination?"[/b] This is a piece of information that is peculiar to OpenVPN – the operating system knows nothing of it.[/list] OpenVPN's designers shrewdly thought of having [i]client-name-specific[/i] configuration files in a designated directory (CCD), where details specific to a particular client could be kept. And, they invented the [b][u]i[/u]route[/b] command – which only makes sense in, and therefore is only allowed in – a CCD file. This is the directive that tells OpenVPN that the client exposes a local-to-it subnet, and OpenVPN knows "which client it is" by virtue of "which CCD-file contained the directive!" Simple, and flexible. Even elegant. You don't have to muck-around with the main config file when you add a new client that has a subnet associated with it! [i](Which happens a [u]lot[/u].)[/i] As you see, [u]both[/u] the [b]route[/b] and the [b]iroute[/b] directives are needed, because they serve different purposes. [b]route[/b] causes an [i]operating system[/i] 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, [b][u]i[/u]route[/b], 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 [b]10.8.0.x[/b] internal OpenVPN virtual-network," but it doesn't involve the operating system. Hope this helps!™

Found this in a search, refreshing my memory on how this works. Thanks. One additional detail building on above; IF your VPN clients are routers themselves AND you want to allow LAN devices under them to communicate to LAN devices under other VPN clients you need two additional things in the server config; [list=1] [*]Allow OpenVPN to permit this traffic with the statement; [u]client-to-client[/u] [*]Have OpenVPN push routes to connecting clients routing tables so those network routers know how to route traffic to those other LANs. Using the client LAN subnet from the above example you would need to add; [u]push "route 10.22.0.0 255.255.255.0"[/u] which assumes that network was a /24 subnet.[/list]

HowTo: my attempt to explain CCDs and "iroute"

MikeRobinson

One of the most-confusing aspects of OpenVPN configuration for me to "grok" was the subject of CCD-files and "i"route. Now that I've finally wrapped my cranium around it, let me try to explain it better than the docs do. (Comments and corrections requested.)

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.

OpenVPN's designers shrewdly thought of having client-name-specific configuration files in a designated directory (CCD), where details specific to a particular client could be kept. And, they invented the iroute command – which only makes sense in, and therefore is only allowed in – a CCD file. This is the directive that tells OpenVPN that the client exposes a local-to-it subnet, and OpenVPN knows "which client it is" by virtue of "which CCD-file contained the directive!" Simple, and flexible. Even elegant. You don't have to muck-around with the main config file when you add a new client that has a subnet associated with it! (Which happens a lot.)

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!™

TinCanTech

Reads well and is correct, thanks.

* promoting to Tutorials *

maxburn

Found this in a search, refreshing my memory on how this works. Thanks.

One additional detail building on above; IF your VPN clients are routers themselves AND you want to allow LAN devices under them to communicate to LAN devices under other VPN clients you need two additional things in the server config;

Allow OpenVPN to permit this traffic with the statement; client-to-client
Have OpenVPN push routes to connecting clients routing tables so those network routers know how to route traffic to those other LANs. Using the client LAN subnet from the above example you would need to add; push "route 10.22.0.0 255.255.255.0" which assumes that network was a /24 subnet.

TinCanTech

You do not need --client-to-client.

--client-to-client allows inter-client traffic to pass through the server without having to loop through the kernel.

This is a useful performance enhancement but it means inter-client traffic is not filtered at all by the server.

Sometimes, it is preferable to only allow specific traffic to flow between clients, eg. HTTP, and not others, eg. FTP.
To filter, the server must not use --client-to-client and must apply rules to its firewall.