Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
tunsocks
User-level IP forwarding, SOCKS proxy, and HTTP proxy for VPNs that provide tun-like interface
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Sure, essentially it's a TCP and UDP server that:
- receives connections and assigns a random internal port for it
- wraps the data packets in a transport packet (TCP/UDP)
- wraps the transport in an IP packet that's routed from the internal port and to the remote WireGuard address
- wraps that with WireGuard's protocol (encryption)
- sends off the encrypted packet to the WireGuard UDP endpoint
The packet-wrapping and state machine for the connection is implemented using smoltcp in Rust, which is similar to netstack in Go
The WireGuard encapsulation and state machine is implemented with boringtun, Cloudflare's implementation of the WireGuard client in Rust.
I do have a more thorough architecture explanation in the Readme: https://github.com/aramperes/onetun#architecture
> You have to give it routing information through an out of band mechanism “AllowedIPs.” One downside is that you can’t have two peers that act as general routers on the same wireguard network
This is a common misconception, due to that this is the way wg-quick works (presumably to make it easier). On a lower level, AllowedIPs is really just "allowed IPs", and does no routing. You can have multiple active peers with overlapping AllowedIPs.
If you set up the tunnel through other means, you can make your own routes.
For example in systemd-networkd, see `RouteTable` under the `[WireguardPeer]` section of systemd.netdev(5).
(This was unfortunately broken for a brief while in systemd in Jan, but should now be fixed again: https://github.com/systemd/systemd/pull/22136. If it's not clear from the link, old and current behavior are that no routes are added unless RouteTable is explicitly set)
I'm not sure how you conclude that AllowedIPs does no routing.
> On a lower level, AllowedIPs is really just "allowed IPs", and does no routing.
This is contrary to what the official documentation says https://www.wireguard.com/#cryptokey-routing
> You can have multiple active peers with overlapping AllowedIPs.
You can, but the most specific CIDR wins route selection, which is exactly what *routing* does.
