Please consider adding a way to dynamically add iroutes while the server is running & client is connected, and without forcing the client to reconnect. Or, better yet, please consider adding the option to disable internal routing, and instead allow the server to rely soley on the kernel's routing table (IOW, allow any&all traffic that's been sent to the tun interface to go through to the specified destination address). Would something like this be feasible?
Currently, it's a pain trying to get the server/tunnel to allow arbitrary traffic that's destined for the client's private subnet. If an iroute doesn't exist for the given route, OpenVPN will drop the packets / not allow them through the tunnel. The only work-around we've found is to create a 'DEFAULT' ccd file and add an all-inclusive 'global' route:
contents of /etc/openvpn/ccd/DEFAULT
Code: Select all
iroute 0.0.0.0 0.0.0.0
A simple use case is when you have a client(s) in 'router' mode with an unknown subnet(s) behind it that need(s) to be accessed from the server-side, all done via standard routing (i.e., without resorting to NAT, port forwarding, or some other means). It simplifies configuration to allow the routing & access control to be managed at the kernel level (via iptables & the routing table), without having to mess with OpenVPN's internal routes (iroutes). In this case, it would be great to be able to disable all internal routing and simply forward packets through the tunnel based on the destination address. Or, at the very least, allow for a means to dynamically add an iroute while the server is running, so that they can be built on-the-fly via a programmatic means (eg., use a client-connect script to get the client's network info & then send a message to openVPN server to add a new iroute).
In our case, we deploy openvpn clients on small linux-driven devices (Raspberry PI) in our customer SOHO's (for tech support & remote dial-in purposes). We need the rPI's to dial home to a central OpenVPN server, and then expose the client's private lan via the tunnel so that our techs can dial in & handle various management tasks. In effect, the rPi client becomes a router, yet with a private address space that's variable.