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 - iorx

#1
Hi again!

Don't know if this is frowned upon or maybe worth much for others, but this solved it for me and may give other an idea how to get it going with WireGuard and hostname.

Some LLM vibe-coding...

This script ensures that all required services are running and that the hostname is resolvable before it triggers a WireGuard restart via pluginctl. It also includes a "pre-flight check" so it doesn't restart anything if the tunnel is already up.

It grabs what it can from the config.conf. A warning is that it assumes that a pingable IP through the tunnel is .1 from one of the .0/24 allowed networks in the peer configuration.

Add:
Put it here, and make an +x on it.

root@fwa:~ # cd /usr/local/etc/rc.syshook.d/start
root@fwa:/usr/local/etc/rc.syshook.d/start # ls
10-newwanip             25-syslog               90-carp                 90-openvpn              95-beep
20-freebsd              50-ntopng               90-cron                 90-sysctl               99-wireguard-dns-fix
root@fwa:/usr/local/etc/rc.syshook.d/start # chmod +x 99-wireguard-dns-fix

PEER_NAME: Change the to match your peer name.
REQUIRED_SERVICES: Adjust Services that should be running.

Script:
#!/bin/sh

# Header: Dynamic Wireguard Startup Sync for OPNsense 26.1
# Description: Extracts peer data from config.xml and ensures DNS stack is ready.
# Note: This script will "man-guess" that .1 is a reachable gateway address if a .0 network is found.
# Optimization: Checks if the tunnel is already up before performing any actions.
# Logging: Outputs to system log with tag "man-guess-wg" and priority "user.notice".

# --- Configuration ---
PEER_NAME="wg_peer"
REQUIRED_SERVICES="unbound dnsmasq AdGuardHome"
CONFIG_PATH="/conf/config.xml"
LOG_TAG="man-guess-wg"
MAX_RETRIES=20
SLEEP_INTERVAL=5

log_msg() {
    # Output to stdout and OPNsense System Log (General)
    echo "$1"
    logger -p user.notice -t "$LOG_TAG" "$1"
}

# 1. Extract the Endpoint (serveraddress)
CHECK_HOST=$(xmllint --xpath "string(//wireguard/client/clients/client[name='$PEER_NAME']/serveraddress)" $CONFIG_PATH 2>/dev/null)

# 2. Extract the first entry from Allowed IPs (tunneladdress)
RAW_IP=$(xmllint --xpath "string(//wireguard/client/clients/client[name='$PEER_NAME']/tunneladdress)" $CONFIG_PATH 2>/dev/null | cut -d',' -f1 | cut -d'/' -f1)

# Logic: Convert network address (ending in .0) to gateway (.1) for ping test.
# This part is a confident man-guess that .1 is the responding address.
TUNNEL_IP=$(echo "$RAW_IP" | sed 's/\.0$/.1/')

# Validation: Stop if configuration data is missing
if [ -z "$CHECK_HOST" ] || [ -z "$RAW_IP" ]; then
    log_msg "ERROR: Extraction failed for '$PEER_NAME'. Check if the name matches in config.xml."
    exit 1
fi

# --- INITIAL CHECK ---
# If the tunnel is already reachable, we exit immediately to avoid unnecessary restarts.
if ping -c 1 -t 2 "$TUNNEL_IP" > /dev/null 2>&1; then
    log_msg "STATUS: Tunnel to $TUNNEL_IP is already UP. No action taken."
    exit 0
fi

check_process() {
    pgrep -f "$1" > /dev/null
    return $?
}

log_msg "STATUS: Tunnel is DOWN. Initiating sync for peer: $PEER_NAME (Target: $CHECK_HOST)"

for i in $(seq 1 $MAX_RETRIES); do
    SERVICES_READY=true
   
    # Verify that all DNS-related services are running
    for SERVICE in $REQUIRED_SERVICES; do
        if ! check_process "$SERVICE"; then
            SERVICES_READY=false
            break
        fi
    done
   
    if [ "$SERVICES_READY" = true ]; then
        # Check if the dynamic hostname can be resolved yet
        if host "$CHECK_HOST" > /dev/null 2>&1; then
            log_msg "DNS OK: $CHECK_HOST resolved. Restarting Wireguard via pluginctl."

            # Official OPNsense 26.1 method for plugin service management
            /usr/local/sbin/pluginctl -s wireguard restart
           
            # Allow time for handshake and routing table updates
            sleep 15
           
            if ping -c 1 -t 3 "$TUNNEL_IP" > /dev/null 2>&1; then
                log_msg "SUCCESS: Connectivity to $TUNNEL_IP confirmed."
                exit 0
            fi
        fi
    fi
   
    # Log status every 5th attempt to keep the system log clean
    if [ $((i % 5)) -eq 0 ]; then
        log_msg "WAIT: Attempt $i/$MAX_RETRIES - Dependencies or DNS not ready."
    fi
   
    sleep $SLEEP_INTERVAL
done

log_msg "FATAL: Timeout reached. Connectivity could not be verified for $PEER_NAME."
exit 1
#2
Hi on my self and others!

Still got this problem it looks like. I resorted to IP-adress, but it would be really nice if it is possible to get it working with a peer hostname instead.
Any way to resolve this?
Make WireGuard wait for DNS-service and maybe be a bit more stubborn on resolving the the name? Make it wait for a while before starting?

from the log:
/usr/local/opnsense/scripts/wireguard/wg-service-control.php: The command </usr/bin/wg syncconf 'wg1' '/usr/local/etc/wireguard/wg1.conf'> returned exit code 1 and the output was "Name does not resolve: `my-very-nice-dyn-hostname:55120' Configuration parsing error"


Brgs,
#3
Awesome!

And such responsiveness here, KUDOS!

I had a go at the source to check what I could find, but with limited knowledge I gave in... Had a small idea to contribute with more than just "the Apply button is moving, please fix" 😁

Keep up the amazing work!
#4
Hi everyone,

To start with, OPNsense is awesome! After years of procrastination, I finally migrated from pfSense to a fully "pimped" OPNsense setup. From DNS redirects, DoH blocking, multi-site WireGuard, 6 VLANs, working forward and reverse lookups. It has been a blast to configure!

What I noticed. It's a "luxury problem":
The Apply button! Hitting a moving target is... 😁
Currently, when the notification banner appears to remind you to apply changes, it causes a layout shift. This means the Apply button moves just as you are about to click it. I think this may improve the experience while, as I've done, work intensively in the UI.

And, some times I had unapplied settings. Maybe a notification at the top that there are lingerings stuff that needs an Apply?

FI: Mainly using Firefox, but same-same behavior in Edge.

Brgs!

#5
Sorry for the noise. Found posts on the subject. Will be removed later down the road...

Brgs,
#6
Hi!

Just curious, can the old menu be removed for legacy rules "Rules" when everything is in "Rules [new]"?

Brgs,
#7
FWIW: I mocked around a bit with removing, changing and adding static mappings. Worked as intended.
#8
Hi!

And great that you had logs on it. Because... I was not telling everything here, I did the upgrade from _10.

Now I tried again, bumped to latest 25.7.11 first. Restart. Went to 26.1_4 with the console option.

No problems this time.

The only "oddity" I "may" experience was a bit longer delay in getting an IP-address (Windows on wifi is a not a stable platform when loosing gw, dns and internet for a moment... it disconnect and starts hunting for other networks...)

I've attached the upgrade logs here.
Snippet:
...
Processing candidates (217 candidates): .......... done
Checking integrity... done (1 conflicting)
- os-isc-dhcp-1.0_3 [OPNsense] conflicts with opnsense-25.7.11_9 [installed] on /usr/local/etc/dhcpd.opnsense.d/README
Checking integrity... done (0 conflicting)
...
Installed packages to be UPGRADED:
dhcp6c: 20250513 -> 20260122 [OPNsense]
hostwatch: 1.0.6 -> 1.0.11 [OPNsense]
opnsense: 25.7.11_9 -> 26.1_4 [OPNsense]
opnsense-lang: 25.7.4 -> 26.1 [OPNsense]
opnsense-update: 25.7.11 -> 26.1 [OPNsense]
os-ddclient: 1.28 -> 1.29 [OPNsense]
os-isc-dhcp: 0.1 -> 1.0_3 [OPNsense]
os-net-snmp: 1.6 -> 1.6_1 [OPNsense]
...
Configuring cron...done.
Configuring system logging...done.
[211/212] Reinstalling isc-dhcp44-server-4.4.3P1_2...
===> Creating groups
Using existing group 'dhcpd'
===> Creating users
Using existing user 'dhcpd'
[211/212] Extracting isc-dhcp44-server-4.4.3P1_2: .......... done
[212/212] Upgrading os-isc-dhcp from 0.1 to 1.0_3...
[212/212] Extracting os-isc-dhcp-1.0_3: .......... done
Stopping configd...done
Starting configd.
Reloading plugin configuration
Flushing all caches...done.
Configuring system logging...done.
#9
Hi!

I'm seeing the same issue when upgrading to 26.1_4.

I can try to grab the upgrade log, but that means I'll have to run the upgrade again. For now I restored my VM so everything works again.

This is what I did, upgrading from the latest 25.x:

  • Performed console upgrade to 26.1_4
  • After the upgrade no clients received IP addresses
  • The ics-dhcp service was missing from the GUI under Services
  • Regular clients didn't get an address, and static mappings were not handed out
  • Restarted
  • Uninstalled and reinstalled the plugin, GUI shows
  • Restarted again
  • Regular clients finally got addresses, but static mappings still didn't work
  • Reverted the VM because the family wasn't happy — devices with static assignments couldn't connect

#10
Hi!

https://forum.opnsense.org/index.php?topic=48278.0

Posted it in the above thread under VPN. Correct, or should it be in here 25.7 release?
#11
Hi all awesome people!

I've got this since 25.7. Now on 25.7.1.
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/usr/bin/wg syncconf 'wg1' '/usr/local/etc/wireguard/wg1.conf'' returned exit code '1', the output was 'Name does not resolve: `mywg.domainIhave.yy:55820' Configuration parsing error'

mywg.domainIhave.yy resolves as it should. But using it as peer in wg, wg fails with the above.
Replacing mywg.domainIhave.yy with the IP-address resolves the problem and wg starts as it should after reboot.

This used to work without any problem before the upgrade, that is 25.1.
Any changes made how wg is starting or waiting for stuff?

Brgs,
#12
Hi again!

Updated to latest. Looks as it should now. No more logging for the rule which has logging disabled.
This fixed in this version?

OPNsense 25.1.5_5-amd64
FreeBSD 14.2-RELEASE-p2

I couldn't extract related info from the change log... probably a limitation associated with me and not the change log 😮😁

brgs,
#13
Quote from: troplin on March 31, 2025, 07:45:18 PMAnother interesting detail: it looks there are always multiple log entries with the same source port when this happens.
So either a single packet generates multiple log entries or it's the other way round: two packets with the same source port arriving at the same time are causing the issue.

In either case, this screams ,,race condition" if you ask me...
Does this mean that it could be this specific device which is the cause/problem? As I only see this block logging from this particular device?
It's a small box, en external controller, for the solar system I got. It makes "intelligent" decisions how to use the energy from the panels and a large battery. They call it "Hartbeat", and the appliance looks very much like a "rasp in a box".
You cannot view this attachment.
#14
Quote from: franco on March 31, 2025, 05:45:04 PMCould be the same as https://forum.opnsense.org/index.php?topic=45801.0 but I haven't checked the details.

I read through that. Looks very much as it could be related to what I have here. Await when the "fix" is in a release or a patch is available.

I'll put my feedback here then. Pausing my own troubleshooting.

And.
Quote from: patient0And in that case it was about IP options...
I tried it out. IP options and change source to Any. Still got block in logs.

Live and prosper 🖖
#15
Many thanks to everyone putting time, brain and keypushing into this!

And sorry for the noise.

Brgs,