Hi all,
I’m seeing what looks like a WireGuard implementation bug on a Comet Pro when it’s used as a site‑to‑site client to an OPNsense WireGuard server. The same basic configuration works fine with “normal” WireGuard clients (Windows), and it also worked in a lab setup where the Comet was directly in the LAN behind OPNsense. It breaks only when the Comet is placed behind a remote FritzBox/DSL connection.
I’ll describe the setup and symptoms; sensitive details are replaced with placeholders.
Devices and firmware
· Device: GL.iNet Comet Pro (KVM)
· Firmware: V1.9.1 release1 (factory image, no custom WG packages installed)
· Server: OPNsense (WireGuard plugin)
· Upstream router at OPNsense site: FritzBox (IPv4, forwards UDP/51820)
· Remote router at Comet site: FritzBox (IPv4, standard NAT)
Target topology
OPNsense site (home)
· LAN: 10.0.3.0/24
· WireGuard tunnel network: 10.99.3.0/24
· OPNsense WireGuard interface address: 10.99.3.1/24
· Peer “CometPro”: 10.99.3.5/32
· WAN reachable as opnsense.myhome.net:51820 (FritzBox forwards UDP/51820 to OPNsense)
Comet site (remote)
· FritzBox LAN: 192.168.1.0/24
· Comet LAN IP: 192.168.1.189
· Comet WireGuard tunnel IP: 10.99.3.5/32 on wg0
Goal: from OPNsense LAN (10.0.3.x) reach 10.99.3.5 (Comet) and its services; from Comet reach 10.99.3.1 and 10.0.3.0/24.
WireGuard configuration
On Comet Pro
/etc/wireguard/wg0.conf:
[Interface]
PrivateKey = <COMET_PRIVATE_KEY>
# NOTE: if I add Address=10.99.3.5/32 the Comet prints:
# Line unrecognized: `Address=10.99.3.5/32'
# Configuration parsing error
# so this firmware does NOT seem to support the wg-quick "Address" key.
[Peer]
PublicKey = <OPNSENSE_PUBLIC_KEY>
Endpoint = opnsense.myhome.net:51820
AllowedIPs = 10.0.3.0/24,10.99.3.0/24
PersistentKeepalive = 25
Autostart script (invoked via /etc/kvmd/user/scripts/S50wireguard from S99custom):
#!/bin/sh
case "$1" in
start)
sleep 10
ip link add wg0 type wireguard 2>/dev/null || true
wg setconf wg0 /etc/wireguard/wg0.conf
ip addr add 10.99.3.5/32 dev wg0 2>/dev/null || true
ip link set wg0 up
;;
stop)
ip link set wg0 down 2>/dev/null || true
ip link delete wg0 2>/dev/null || true
;;
restart)
$0 stop
sleep 2
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
;;
esac
exit 0
Routing on the Comet:
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.189
192.168.1.1 dev eth0 scope link
So there is no default route via wg0; only the tunnel IP 10.99.3.5/32 is bound to wg0 via ip addr add.
Example wg show wg0 when the issue occurs:
interface: wg0
public key: <COMET_PUBLIC_KEY>
private key: (hidden)
listening port: 42406
peer: <OPNSENSE_PUBLIC_KEY>
endpoint: <OPNSENSE_WAN_IP>:51820
allowed ips: 10.0.3.0/24, 10.99.3.0/24
latest handshake: 24 seconds ago
transfer: 6.32 KiB received, 1.21 KiB sent
persistent keepalive: every 25 seconds
· Date/time on the Comet is correct.
· Using either opnsense.myhome.net or the raw IPv4 for Endpoint makes no difference.
On OPNsense
· Local instance (server):
o Listen port: 51820
o Tunnel address: 10.99.3.1/24
o Public key (server): <OPNSENSE_PUBLIC_KEY>
· Peer “CometPro”:
o Public key: <COMET_PUBLIC_KEY>
o Allowed IPs: 10.99.3.5/32
o Attached to the same WireGuard instance as a working Windows client
Firewall (simplified):
· WireGuard interface (assigned):
o Rule: allow any from WireGuard net to LAN net.
· LAN interface:
o Rule: allow any from LAN net to WireGuard net.
A Windows WireGuard client in the same 192.168.1.0/24 network as the Comet, with its own key and an address like 10.99.3.10/32, works perfectly with this OPNsense instance over the same FritzBox/DSL path.
Behavior in the LAN test setup (works)
In my initial test, the Comet was placed directly in the LAN behind OPNsense (no separate WAN/FritzBox in between). I used the same WireGuard configuration structure (adjusted endpoint accordingly).
In that setup:
· Handshake was established.
· Pings and HTTPS from 10.0.3.x to 10.99.3.5 worked.
· The Comet could reach 10.99.3.1 and hosts in 10.0.3.0/24.
· wg show on both sides showed increasing tx/rx counters when sending traffic.
So the general configuration is proven to work in a “same‑site” scenario.
Behavior in the final WAN setup (FritzBox/DSL in between)
After moving the Comet to its final location behind the remote FritzBox/DSL:
· From the Comet:
o ping opnsense.myhome.net works (general internet connectivity ok).
o wg show wg0 shows a valid, recent handshake and a few KiB of rx/tx.
o When I run ping 10.99.3.1 from the Comet:
§ No replies (100% packet loss).
§ The tx/rx counters in wg show do not increase beyond those initial few KiB.
· On OPNsense:
o WireGuard status shows a valid handshake for the Comet peer.
o When I try from a LAN host (10.0.3.11) to reach 10.99.3.5 (ping or HTTPS):
§ Firewall Live View (filtered on source/destination 10.99.3.5) shows:
§ Interface WireGuard, direction Out, proto TCP/ICMP, src 10.0.3.11, dst 10.99.3.5, action pass.
§ Interface LAN, direction In, same traffic, action pass.
§ So OPNsense is sending packets towards 10.99.3.5 via the WG interface, and they are not blocked.
· On the WAN side of OPNsense (pppoe interface), a packet capture:
tcpdump -ni <PPPOE_INTERFACE> udp port 51820
<REMOTE_FritzBOX_WAN_IP>.36922 > <OPNSENSE_WAN_IP>.51820: UDP, length 148
<OPNSENSE_WAN_IP>.51820 > <REMOTE_FritzBOX_WAN_IP>.57198: UDP, length 148
(repeating in both directions)
So:
· Handshake and keepalive packets clearly reach both ends.
· Data traffic from the OPNsense side to 10.99.3.5 is constructed and sent into the tunnel and out on the WAN.
· But wg show wg0 on the Comet does not show increasing rx bytes when that traffic is sent, and the Comet never sees those packets at the IP layer.
Again: a standard Windows WireGuard client, sitting in the same 192.168.1.0/24 network as the Comet, with its own key and /32 in 10.99.3.0/24, works fine with the same OPNsense instance over the same FritzBox/DSL connection.
Suspected issue
Given that:
· Handshake and a small amount of traffic are seen on both ends.
· Data packets for 10.99.3.5 are definitely being sent by OPNsense, passed by firewall, and leave on the WAN.
· The Comet’s wg show does not show additional rx bytes for those packets.
· A Windows WireGuard client with the same server, same port, same AllowedIPs pattern works perfectly from the same remote LAN.
it looks like the Comet Pro’s WireGuard implementation may not be correctly processing all tunnel data for its assigned IP (10.99.3.5) when:
· The IP is configured via ip addr add on wg0 (because the firmware rejects Address= in the config), and
· The client is behind a remote NAT/WAN rather than in the same LAN as the OPNsense.
In other words: control traffic (handshake, keepalive) works, but “regular” tunnelled traffic addressed to 10.99.3.5 does not reach the Comet’s wg0 in this WAN scenario, whereas it does in the LAN scenario.
Questions
1. Is this a known limitation or bug with WireGuard on the Comet Pro (especially around using wg setconf + manual ip addr add instead of the Address= directive)?
2. Is there a recommended way to configure WireGuard on the Comet Pro for site‑to‑site usage with an external server (like OPNsense) without relying on the built‑in GUI, so that it behaves like a standard Linux WireGuard client over WAN?
3. Is there additional logging I can enable on the Comet to see why packets destined for 10.99.3.5 do not show up as rx bytes on wg0, even though they clearly leave the OPNsense and traverse the WAN?
If you need more information (sanitized OPNsense screenshots, full configs with keys/IPs replaced, more packet captures), I can provide it.
Thanks in advance for any hints or for confirming whether this looks like a firmware issue or if I’m missing a Comet‑specific configuration detail.