Blame
| de4d57 | ordex | 2025-07-18 10:05:52 | 1 | # Routing in DCO |
| 2 | ||||
| 3 | When OpenVPN is operating in multi-peer mode it requires a way to understand |
|||
| 4 | which peer outgoing packets should be forwarded to. |
|||
| 5 | ||||
| 6 | If DCO is not enabled, OpenVPN creates an internal mapping where specific destinations |
|||
| 7 | are associated with specific peers. This mapping is created following the `--iroute` and |
|||
| 8 | `--iroute-ipv6` directives configured by the user. |
|||
| 9 | ||||
| 10 | With DCO there is no access to any mapping in userspace, therefore DCO must come up with |
|||
| 11 | its own solution. |
|||
| 12 | ||||
| f84926 | ordex | 2025-07-18 10:12:26 | 13 | ## Linux |
| de4d57 | ordex | 2025-07-18 10:05:52 | 14 | |
| 15 | On Linux DCO simply relies on the system routing table to tell it which peer is responsible |
|||
| 16 | for a destination. |
|||
| 17 | ||||
| 18 | Specifically, DCO looks up the destination adress in the main system routing table and uses the |
|||
| 19 | nexthop IP to match the responsible peer. |
|||
| 20 | ||||
| 21 | Example: |
|||
| 22 | ``` |
|||
| 23 | 100.100.0.0/24 via 10.10.0.5 dev ovpn0 |
|||
| 24 | ``` |
|||
| 25 | This route entry tells DCO that any packet going to `100.100.0.0/24` should be sent to the peer having VPN IP 10.10.0.5. |
|||
| 26 | The matching between the VPN IP and the actual peer instance is performed internally to DCO. |
|||
| 27 | ||||
| 28 | One of the benefit give by this approach, is that any component external to OpenVPN may add or remove VPN routes |
|||
| 29 | without directly interacting with OpenVPN. Think about external routing daemons or other processes listening to |
|||
| 30 | link notifications. |
|||
| 31 | ||||
| 32 | ### Userspace |
|||
| 33 | ||||
| 34 | Due to the logic described above, OpenVPN in userspace has been adapted to add such routes when the user specifies any |
|||
| 35 | `--iroute` or `--iroute-ipv6`. |