The difference between OpenVPN internal routing and system routing lies in the fact that system routing strictly follows the longest prefix match principle鈥攐nce a route is found, the data packet is forwarded out through the corresponding network interface. OpenVPN’s internal routing also ultimately decides whether to forward a packet and where to forward it, but this “whether to forward” and “where to forward” is significantly different from system routing. Whether OpenVPN forwards a data packet is based on its internal routing table and has nothing to do with the system routing table. So where does it forward? Actually, it forwards to two places. Based on the result of its internal route lookup, if the destination address is not that of another OpenVPN client or a network host behind such clients, it forwards to its own virtual network interface. If the destination address belongs to another OpenVPN client or a network behind it, then, with client-to-client (C2C) enabled, it forwards directly to the corresponding OpenVPN socket, encapsulating it with OpenVPN protocol using that socket instance’s security parameters before forwarding. Isn’t C2C quite similar to the Linux kernel’s ip_forward parameter?
Note that in the preceding explanation, I have consistently used the term “destination address” rather than “destination IP address.” This is because OpenVPN’s internal routing is not solely IP routing. In tap mode, its internal routing is actually link-layer routing. In this case, the OpenVPN server is not a router but a switch鈥攕pecifically, a switch capable of “dynamically learning MAC addresses.” Therefore, in tap mode, OpenVPN’s internal routing essentially mirrors a switch’s link-layer routing, and its routing table resembles a switch’s MAC address table.
The responsibilities of OpenVPN internal routing are:
1. Deciding whether to forward incoming payload data packets that have already been stripped of their OpenVPN encapsulation. In other words, determining if the payload packet’s originator falls within the OpenVPN policy scope;
2. Handling communication between different OpenVPN clients and between hosts on network segments attached behind these clients. This means routing data packets between these hosts; note that the “routing” referred to here is not IP routing in the protocol stack, but routing within OpenVPN itself.
OpenVPN can be expanded into a massive network through its internal routing, directly traversing insecure network zones such as the public Internet or metropolitan area networks, making this expanded vast network truly virtual and private. This is OpenVPN’s most powerful feature in terms of network topology support. Other powerful aspects of OpenVPN have been discussed extensively in previous articles, such as its integration with SSL, PKI, and so on. At the interface with the host’s network protocol stack, OpenVPN uses a virtual network adapter鈥攁lso a topic that has been thoroughly covered. Therefore, this series of articles focuses on OpenVPN’s powerful routing capabilities. If you can thoroughly understand this, I believe you will grasp the rest, making reading and customizing the source code no longer a difficult task. Hence, this series will not redundantly analyze the source code.
So, what exactly does the network expanded by OpenVPN look like? It depends on whether you use tap mode or tun mode:
In tap mode, the VPN nodes (multiple clients and one server) form an Ethernet network, with the VPN server acting as an Ethernet switch. Since Ethernet operates under the IP protocol stack, all VPN nodes in tap mode, along with nodes bridged behind them, form a large Ethernet network rather than an IP network. OpenVPN’s internal routing operates on MAC addresses; for any source IP, OpenVPN’s internal routing allows direct passage. After being written to the virtual network interface, the system routing makes the final decision. Therefore, in tap mode, if you need IP connectivity between networks behind various VPN nodes, you must either implement NAT mapping鈥擭ATing the network behind a VPN node to that VPN node鈥攐r supplement it with system IP routing. These configurations are complex and difficult to maintain. See the diagram below:
