Question regarding SDN WireGuard External Peers in PVE 9.2

izzylab

New Member
Jul 30, 2025
1
0
1
I am currently working with the new WireGuard SDN integration in Proxmox VE 9.2. While I have successfully established an internal mesh between cluster nodes, I have some technical questions regarding the "Fabric" functionality, specifically concerning External Peers, to ensure a correct implementation.

  1. Understanding the "External Peer" configuration: What is the precise role of an "External Peer" within the fabric logic? Based on my current observations, defining an external peer does not generate a specific WireGuard interface configuration at the OS level (e.g., under /etc/wireguard/), nor does it seem possible to assign an IP address to the interface itself. Is it correct that automatic interface creation is currently not intended for external connections, or is this a feature planned for a future update?
  2. Endpoint definition: Within the fabric peer settings, the field "Host that peers connect to" is required. When I enter the node's own IP address, it seems to be intended primarily for internal communication between PVE nodes. How should this field be correctly configured when I want to connect an external client (e.g., a smartphone or a standalone server) that needs to connect to the Proxmox node?
  3. Routing/AllowIPs: Are the subnets defined under "Allowed IPs" automatically added to the PVE host's routing tables? So far, I have not been able to verify the corresponding routing behavior for external peers. Is there a recommended approach for properly routing external peers within the SDN fabric?
 
I want to connect an external client (e.g., a smartphone or a standalone server) that needs to connect to the Proxmox node?
I think there may be a conceptual distinction here. The WireGuard SDN fabric does not appear to be the same thing as a general-purpose remote-access VPN for phones or standalone clients.
One important distinction is that the SDN fabric is mainly used as an underlay transport for overlay network protocols, for example VXLAN.
So even if an external client such as a smartphone or a standalone server can establish a WireGuard connection to the Proxmox node, that alone does not necessarily mean it can communicate with VMs or CTs attached to a VNet on top of the SDN overlay.

Depending on the actual SDN design, the external client would also need to be part of the relevant overlay/routing model. For example, if the VNet is carried over VXLAN, simply reaching the WireGuard fabric endpoint would not automatically make the external client a member of that VNet.

Reaching the fabric underlay is not the same as being connected to the overlay VNet.

This also seems consistent with the documentation, which describes WireGuard as a VPN between Proxmox VE nodes and/or external nodes, but also says that it does not provide dynamic routing by itself and can be used together with OSPF/BGP to provide an encrypted transport, for example to carry EVPN or VXLAN traffic.
 
Last edited:
  • Like
Reactions: Johannes S
Understanding the "External Peer" configuration: What is the precise role of an "External Peer" within the fabric logic? Based on my current observations, defining an external peer does not generate a specific WireGuard interface configuration at the OS level (e.g., under /etc/wireguard/), nor does it seem possible to assign an IP address to the interface itself. Is it correct that automatic interface creation is currently not intended for external connections, or is this a feature planned for a future update?
External Nodes are simply peer definitions that you can then assign as peer to an interface on a Proxmox VE node. So if you want to connect from a Proxmox VE node to an external peer you'd create the external peer definition and then select it in the interface configuration. The interface needs to be created for the Proxmox VE node.

Endpoint definition: Within the fabric peer settings, the field "Host that peers connect to" is required. When I enter the node's own IP address, it seems to be intended primarily for internal communication between PVE nodes. How should this field be correctly configured when I want to connect an external client (e.g., a smartphone or a standalone server) that needs to connect to the Proxmox node?
The external peer needs to have its own configuration on how to connect to the Proxmox VE node, the client needs to know which IP to use to connect, not the Proxmox VE node.

Routing/AllowIPs: Are the subnets defined under "Allowed IPs" automatically added to the PVE host's routing tables? So far, I have not been able to verify the corresponding routing behavior for external peers. Is there a recommended approach for properly routing external peers within the SDN fabric?
Yes they are, you can check via the ip route command after applying the configuration. It does not add a route via a specific IP though, only a link scope route for that subnet, e.g.

Code:
203.0.113.0/28 dev wg0 scope link

If you wanted to route via a specific IP, then that route would have to be created manually as well, e.g.:

Code:
ip route add 203.0.113.0/28 via 198.51.100.10

As the previous poster mentioned, it might make sense to run OSPF / BGP for more complicated setups. Alternatively, you can manually add static routes via creating a respective section in the interfaces config:

Code:
iface wg1 inet static
  post-up ip route [..]

In both cases it makes sense to enable skipping the automatic route generation completely.
 
  • Like
Reactions: Johannes S