Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - relvy

#1
Hello,

I want to upgrade my HA cluster from 26.1.11_10 to 26.7.1.

From the docs the basic steps are clear and I run the upgrades within 26.1.x this way.


Update your secondary unit and wait until it is online again
On your primary unit go to Interfaces ‣ Virtual IPs ‣ Status and click Enter Persistent CARP Maintenance Mode
You secondary unit is now MASTER, check if all services like DHCP, VPN, NAT are working correctly
If you ensured the update was fine, update your primary unit and hit Leave Persistent CARP Maintenance Mode


But from reading the 26.7.1 release notes there are some special things not covered there:
- Migration of Outbound NAT -> Source NAT
- CPU Microcode
- PFSync compatibility due kernel upgrade

I successfully migrated from outbound NAT to Source NAT on both primary and secondary, so I expect no issue during upgrade.
IIUC my next step is to deinstall the microcode plugin on both machines and install it after the upgrade again due to bootloader changes ?
All other steps should be as the documentation says.

For a short window I will have my primary on FreeBSD 14.3 and my secondary on FreeBSD 15.1, where I must do the failover.
Is PFSync compatible or is there something I need to pay attention to ?
#2
> To also catch the case if the primary is the backup to the following:
> Say you want to access the backup using management VLAN IP, on the primary add both management IPs to an alias. I call it FW1_FW2.
>
> Then add an outbound NAT rule to the management VLAN interface, use FW1_FW2 for the destination, translation = interface address (default), save.

This is helpful for me too, but:
Restrict the source address to "Wireguard (Group) net".

Without that restriction I had the issue that a zabbix proxy was no longer reachable on the secondary opnsense. The zabbix proxy rejected connections from the zabbix server because they appeared to come from the primary opnsense.
#3
General Discussion / acme deployment to opnsense
December 28, 2025, 05:43:08 PM
Hello,

I have acme client running on my Synology NAS.
I want to deploy my certificate from the NAS *to* opnsense with the ssh deploy hook
  • .

What values do I have to set to the DEPLOY_SSH_* variables for automatic deployment?
In particular I need to know the target path, target filenenames and the remote cmd.

#4
It turned out to be a configuration error in the firewall.
I had a pass in rule on the WAN interface with a gateway set. This caused the packet to be rerouted to the gateway *before* it went into the wg interface.
The solution was to remove the gateway.

The route-to case is described here which also warns about the above:
https://docs.opnsense.org/manual/how-tos/multiwan.html#step-4-policy-based-routing

The snippet from dmesg made me think this is a kernel issue, in particular the error code 47:

> wg1: Handshake for peer 1 did not complete after 5 seconds, retrying (retry 15)
> wg1: Sending handshake initiation to peer 1
> wg1: Unable to send packet: 47

#define    EAFNOSUPPORT    47        /* Address family not supported by protocol family */
#5
> Enable debugging on wg1 gives me:
>
> wg1: Handshake for peer 1 did not complete after 5 seconds, retrying (retry 15)
> wg1: Sending handshake initiation to peer 1
> wg1: Unable to send packet: 47
>
> What does 47 mean?

I just looked into the FreeBSD wg(4) driver source code:
https://cgit.freebsd.org/src/tree/sys/dev/wg/if_wg.c?h=stable/14&id=684dd4e8c0085f4e64016a44d4cd699b2fc29681   line 1014 prints "Unable to send packet: "
https://cgit.freebsd.org/src/tree/sys/sys/errno.h?h=stable/14  in line 110  I found this:

#define    EAFNOSUPPORT    47        /* Address family not supported by protocol family */

47 means it cannot handle the address family.
This is weired to me because I use IPv4 only. IPv6 is disabled.
#6
Hello,

I am on OpnSense 25.7.6.
I got Wireguard working. Then I added CARP interfaces on LAN and WAN side. Then handshake does not complete.

I see this in the pflog0 traffic on VPN initiation:

tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), snapshot length 256 bytes
 00:00:00.000000 rule 191/0(match): pass in on igc0: (tos 0x0, ttl 56, id 50850, offset 0, flags [DF], proto UDP (17), length 176)
    a.b.c.d.29106 > 192.168.178.2.51820: UDP, length 148
 00:00:00.000028 rule 137/0(match): pass out on igc0: (tos 0x0, ttl 55, id 50850, offset 0, flags [DF], proto UDP (17), length 176)
    a.b.c.d.29106 > 192.168.178.2.51820: UDP, length 148

a.b.c.d is the public IP address of my peer. 192.168.178.2 is my CARP interface on the WAN side.
The pass in is the handshake initiation from the peer.
The pass out is the response thereof. Notice, the src and dst are reversed. That's why handshake does not complete (if it started at all).

I need help in diving deep and undoing src and dst reversal.

Snippet from netstat -rnfinet
10.251.0.0/16      link#23            U               wg1
10.251.0.1         link#7             UHS             lo0
10.251.0.2         link#23            UHS             wg1
10.251.0.3         link#23            UHS             wg1

Enable debugging on wg1 gives me:

wg1: Handshake for peer 1 did not complete after 5 seconds, retrying (retry 15)
wg1: Sending handshake initiation to peer 1
wg1: Unable to send packet: 47

What does 47 mean?