Securing VXLAN Traffic
This page applies to VXLAN mode. In trunk port mode the traffic never leaves the link between the Asset Gateway host and the switch, so no additional protection is required.
Why a VPN may be needed
VXLAN does not provide encryption or authentication on its own. The encapsulated frames travel over the underlay as plain UDP packets, and anyone with access to the path between the two endpoints can read them or inject their own. This is acceptable when the underlay is a trusted, physically controlled network. It is not acceptable when discovery traffic traverses an untrusted network such as a shared corporate backbone or a WAN link.
In that case, establish a VPN tunnel between the Asset Gateway host and the remote VXLAN endpoint, and verify connectivity before running a multi-VLAN discovery job. The Asset Gateway does not set up the VPN; it only uses an interface that already exists.
IPsec VPN
No change to the discovery parameters is required. Use the physical interface (for example,
enp2s0) as parentInterfaceName, because IPsec operates transparently on the same interface that
carries the unencrypted traffic.
WireGuard
Set parentInterfaceName to the WireGuard interface (for example, wg0) instead of the physical
interface, and set parentInterfaceIP to the IP address assigned to that WireGuard interface. The
VXLAN tunnel is then established over the encrypted WireGuard interface.
Note that the host firewall rule for the VXLAN UDP port should then be bound to the WireGuard interface rather than the physical one. See Host firewall requirements.
Using multiple WireGuard (Parent) interfaces
When several WireGuard (parent) interfaces exist on the Asset Gateway host, assign each of them an address in a different subnet. Overlapping subnets create ambiguous routing table entries, and the routes used for the VXLAN tunnel may then be bound to the wrong interface, which leads to incomplete or unexpected discovery results.
This is especially important because the Asset Gateway brings a parent interface up before a job and back down afterward, as described in Parent interface lifecycle. Interfaces remain under the control of the user, so any change to them before or during a discovery job can introduce overlapping routes. Keep the subnets separate to avoid this.