VXLAN not auto turn up when reboot/start opnsense

[fabio1999ita]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug i have a wireguard tunnel between 2 opnsense and i need to use vxlan for get a layer 2 tunnel, everythings work perfect except if i make a reboot of opnsense, in both opnsense vxlan not turn up automatically, so i need every reboot to reapply the vxlan config for turn it on, from the gui i can see the vxlan as red after reboot like in screenshot

in this video you can see the problem

https://github.com/user-attachments/assets/f4907270-f460-460c-b7c5-9a89e879a239

log show this

overview with vxlan as red overview with vxlan after i reapply its config

vxlan config

bridge config

i'm hosting opnsense in vmware esxi, the only plugin installed is the one for vmware tools

OPNsense 24.7.3_1-amd64 FreeBSD 14.1-RELEASE-p3 OpenSSL 3.0.14 AMD Ryzen 9 5900HX with Radeon

workaround

[AdSchellevis]

enabled the vxlan interface in Interfaces -> vxlan? when not enabled, it won't try to hook to the bridge

[fabio1999ita]

The vxlan interface is enabled, you can see in the video that I post

Il Dom 1 Set 2024, 14:42 Ad Schellevis @.***> ha scritto:

enabled the vxlan interface in Interfaces -> vxlan? when not enabled, it won't try to hook to the bridge

— Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/7833#issuecomment-2323324145, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGOAFYFT62LJTLK5QIUZLNDZUMDUFAVCNFSM6AAAAABNOWSPI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRTGMZDIMJUGU . You are receiving this because you authored the thread.Message ID: @.***>

[AdSchellevis]

haven't looked at the video, just briefly checked on my end if it attached after boot with a vxlan using a wireguard address, which it did.

[Monviech]

The best way to ensure stable VXLAN/GRE etc... is to attach them to local loopback interfaces (Interfaces: Other Types: Loopback). Loopback interfaces will be always there on boot time and the VXLAN/GRE will attach to them very reliably as children (VXLAN "Source address" set to the IP of the Loopback interface).

The loopback interfaces need a routable IP address, so not 127.0.0.0/8 range but something in the 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 range.

These interfaces can then be routed through a VPN tunnel, either by policy based IPsec or Wireguard. For these VPNs, both sides would route the /32 address of these loopback interfaces. E.g. for IPsec it would for example be 172.16.100.2/32 <==> 172.16.100.3/32. In Wireguard this can be done with "Allowed IPs".

A very different approach would be to use OpenVPN in TAP mode combined with a bridge. For that, no VXLAN would be needed to get Layer2 over VPN.

As side for @AdSchellevis: I thought I have made a forum post in the past, but there I attached GRE to a IPsec VTI interface, and not to a loopback interface.

[fabio1999ita]

but how can possible that opnsense is not able to configure a virtual interface on boot for first opnsense should create the virtual interface (the vxlan) then configure it, not the reverse

[AdSchellevis]

because your virtual interface depends on an address that might not be there? loopbacks are commonly used in these types of situations.

[fabio1999ita]

for now i apply a workaround cloning file 95-beep to 96-restartservices in /usr/local/etc/rc.syshook.d/start/ with inside

#!/bin/sh

echo "Restart all services: " > /dev/console
configctl service reload all