Recent posts

#1

German - Deutsch / Re: WireGuard-Tunnel ohne Inte...

Last post by Billie34 - Today at 04:17:12 AM

Besonders interessant ist, dass der WireGuard-Handshake funktioniert und der Internetzugang unmittelbar nach einem manuellen Firewall-Reload wiederhergestellt wird.

Among Us

#2

Virtual private networks / Bitcoin Blackmail Emails: How ...

Last post by nic2cu22 - Today at 02:39:25 AM

A blackmail email demanding bitcoin is a threat to assess calmly, not an instruction to pay. An old password, a frightening deadline, or technical-sounding language does not by itself prove that the sender has accessed your device. Avoid replying or opening attachments, preserve relevant evidence, and secure affected accounts through trusted channels. If there is a specific threat to physical safety or genuinely private material, seek appropriate professional or law-enforcement help promptly.

Separate the claim from the evidence
The email may claim to control your webcam, possess private videos, or know everyone in your contacts. Write down what evidence it actually provides. A statement that sounds detailed can still be an unsupported assertion. A password you used years ago can come from a previous breach rather than a current compromise.

The UK's NCSC guidance on sextortion emails explains this pattern, including threats designed to provoke payment and the use of old passwords. It advises against engaging with the sender. That guidance is especially relevant to mass emails whose apparent proof consists mainly of recycled personal information.

Do not use the sender's links to test whether the claim is real. A supposed evidence download can create a new risk. Review account security using your known app or an independently entered official address instead.

Keep an evidence copy without engaging
Preserve the original message, including the sender address, date, subject, and any demanded payment address. If your email service allows export with headers, keep that file in a safe place. Headers can assist an investigation even though the visible sender name may be misleading.

Do not reply to argue, negotiate, or ask the sender to demonstrate access. A reply confirms that someone is reading and reacting. Likewise, avoid opening unexpected attachments or scanning a payment QR code simply to see what happens.

For workplace or school accounts, follow the organization's reporting process. Forwarding potentially malicious material widely among colleagues creates unnecessary exposure. Share the evidence with the designated security team through its approved channel.

Secure accounts in a practical order
Start with the email account because it can control password resets for other services. Use a strong, unique password, enable an appropriate second factor, review recent sign-ins, and check recovery methods and forwarding rules. If you suspect the device itself is compromised, use a trusted device to secure important accounts.

Change any password mentioned in the threat if you still use it, including on other accounts where it was reused. Do not merely add one character to a known password. A password manager can help maintain distinct credentials without relying on small predictable variations.

Bit.Fan's guide to how to respond to email blackmail demanding bitcoin puts account protection and evidence preservation ahead of payment. Those steps address concrete exposure even when the sender's wider story is false.

Recognize when the situation needs more help
Not every threatening message is the same. If the sender presents genuinely private material, shows evidence of recent unauthorized access, targets someone personally, or threatens immediate harm, take the situation seriously. Preserve what is relevant and contact local authorities or a qualified security professional through a verified route.

Avoid assuming that polished grammar proves legitimacy or poor grammar proves a bluff. The quality of the evidence matters more than writing style. A mass scam can be well written, and a targeted threat can contain mistakes.

If intimate images are involved, support is available. The FBI's sextortion guidance describes reporting and victim-support options and warns that cooperation does not reliably end blackmail. A young person should involve a trusted adult promptly rather than trying to handle the pressure alone.

Payment does not establish a resolution
Sending bitcoin does not give you an enforceable guarantee that files will be deleted or further demands will stop. The sender controls the claim and can invent another reason to ask for money. A payment may also confirm willingness to respond to pressure.

If you already paid, stop further transfers and retain the transaction details, including amount, time, receiving address, and TXID if available. Contact the relevant payment service promptly and report the incident through official channels. Recovery is uncertain; nobody should promise that a blockchain transaction can simply be reversed.

Be cautious of people who contact you offering guaranteed recovery for an upfront fee. A second scam can exploit the same distress as the first. Verify support independently and never share wallet secrets with a purported investigator.

Return to the facts after reporting
Once evidence is preserved and the appropriate report made, block the sender and follow your provider's guidance for removing the message. Continue watching for concrete account alerts rather than repeatedly rereading the threat. If the incident is affecting your wellbeing, involve somebody you trust.

The goal is to replace the sender's urgency with a sequence you control: preserve, verify, secure, and report. None of those steps requires believing every claim in the email, and none requires paying simply because a bitcoin address and a countdown appear in the message.

#3

General Discussion / Newbie Tries AGH + Unbound

Last post by goofyman23 - Today at 01:50:31 AM

Not too long ago, I got OPNSense setup and was able to replace my aging ASUS router. I've been happy overall, but overwhelmed at times. I've got AdGuard Home running for filtering/blocklists but recently enabled Unbound for another layer of privacy.

I knew going in that DNS lookups would be slow, but after ~48 hours, I think the performance is slower than what it should be. This is where I'm looking for input and advice. Perhaps I'm impatient and need to wait it out more to see if it normalizes.

AGH is reporting average processing times of ~200-300ms and ~500-700ms for upstream processing.
Unbound Statistics I think look good considering the amount of cold caches (see attached). But, at the same time I see recursive lookups of 2000-4000ms in Reports > Unbound.


AGH forwards everything to Unbound for DNS and Unbound is the only upstream server.
About the only things I changed within Unbound are:
Enabled Prefetch DNS Key Support, Hide Identity/Version, and  enabled DNSSEC Support
DHCP is done via DNSMasq and not AGH.

#4

Tutorials and FAQs / Re: [HowTo] OPNsense Boot Load...

Last post by nero355 - Today at 12:32:53 AM

However, what is the reason OPNsense itself doesn't update the bootloader when performing a firmware upgrade?

Because FreeBSD doesn't so OPNsense doesn't too :)

IIRC the reason was something like "Too many variables involved that increase the chance for a unootable system afterwards if things go wrong" or so...

I will look it up and add the explanation in a future update! ;)

#5

26.7, 26.10 Series / Re: [Solved by reboot] 26.7 Up...

Last post by danmac - Today at 12:04:40 AM

So -a has a history for us: https://github.com/opnsense/update/issues/90

Blimey lol :/ thanks for the link, I also skimmed 7825

So the danger is that fetch -a can retry forever getting nowhere. Also I see some confusion regarding the -T flag, as we discussed earlier I thought it was connect timeout only ... (?)

I can understand the difficulty of devising a solution that makes everybody happy, with their own little networks broken in their own little ways ;)

If it's on the roadmap to switch to curl anyway, it occurs to me I'm in danger of wasting your time with this ... although as previously noted, curl failed in just the same way, at least for me. curl does seem to have more levers to influence the retry logic though, eg. --retry, --retry-max-time, --connect-timeout, --max-time, etc

I also don't quite get what's happening here:

Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz                        88% of  31 MB  691 kBps    05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz                                31 MB  634 kBps    06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done

It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok?  Why doesn't it work the first time? This isn't a client-side riddle IMO.

Yeah it just resumes the remaining portion of the transfer after it hits the unceremonious yet highly predictable SSL EOF - I end up with everything fully downloaded and verified.

I still can't help but suspect these woes are (P)MTU / MSS related. Firmware updates seem to be a particular pain-point with 5G, and the guy in issue 90 had some wacky VPN + proxy setup. (on that note I wonder if the fetch -T timeout is satisfied by the connection to the proxy rather than actually contacting the mirror) May also explain why some say changing mirrors helps. I never had this problem on the exact same firewall via VDSL (1500 MTU, ethernet @ 1508 MTU to a Draytek modem in bridge mode, OPNsense handling PPPoE) it's only an issue now I'm on 5G. (1380 MTU)

I had the AI waifu check my MTU configs (at least in theory) last night, bit of a long story, funny to see its "thinking" loops similar to my wetware when I'm handling MTU calculations haha :/ "hmmm ... wait ... let me recompute cleanly ..." xD

Maybe in amongst these ramblings (sorry) will be a clue or two for someone down the line. I'm still new to 5G and it was installed in haste/anger on an 8+ year old somewhat complicated install so I should probably return with a fresh install and wireshark, et al. I'll even stop ignoring the new firewall rules page ;)

o7 thx, appreciate your time Franco :)

#6

26.7, 26.10 Series / Re: Upgrade to 26.7.8 broke Ga...

Last post by oc - November 03, 2026, 10:13:15 PM

I upgraded from 26.7.7 to 26.7.8_1 and then 26.7.8_2 and experienced no issues (and I have a pretty diversified gateways setup, policy based routing, etc.) - thanks OPNsense team!

#7

26.7, 26.10 Series / Re: WAN_DHCP6 learns OPNsense ...

Last post by franco - November 03, 2026, 09:02:01 PM

Network loop between WAN and LAN?

#8

26.7, 26.10 Series / WAN_DHCP6 learns OPNsense LAN ...

Last post by noclue68 - November 03, 2026, 08:32:46 PM

Hello,

I'm facing a very strange IPv6 issue and after extensive troubleshooting I cannot explain the behaviour anymore.

Topology:

Internet
  |
FRITZ!Box
  |
OPNsense WAN
  |
OPNsense LAN
  |
GS308E Switch
  |
Clients

Environment:

- OPNsense running as VM on Proxmox
- WAN and LAN are on separate virtual NICs
- WAN and LAN are connected to separate Proxmox bridges
- FRITZ!Box configured with Exposed Host
- DHCPv6-PD enabled

OPNsense NICs:

LAN:
MAC BC:24:11:89:92:3C

WAN:
MAC BC:24:11:E3:15:CE

FRITZ!Box:

MAC B4:FC:7D:50:16:A5

Problem:

System > Gateways shows:

WAN_DHCP6 (active)

Gateway:
fe80::be24:11ff:fe89:923c

However, fe80::be24:11ff:fe89:923c belongs to the LAN interface of OPNsense itself.

NDP confirms:

OPNsense LAN:
fe80::be24:11ff:fe89:923c
MAC bc:24:11:89:92:3c

FRITZ!Box:
fe80::b6fc:7dff:fe50:16a5
MAC b4:fc:7d:50:16:a5

The FRITZ!Box is visible and reachable via NDP, but OPNsense still installs its own LAN link-local address as the active WAN_DHCP6 gateway.

Additional log message:

RA with a lower CurHopLimit sent from
fe80::be24:11ff:fe89:923c
(current = 255, received = 64)
Ignored.

Already tested:

- Fresh OPNsense installation
- GS308E factory reset
- Same behaviour after reinstall
- WAN and LAN are separated
- FRITZ!Box link-local address visible in NDP
- Issue reproducible

Expected gateway:

fe80::b6fc:7dff:fe50:16a5

Actual gateway:

fe80::be24:11ff:fe89:923c

Has anyone seen OPNsense learning its own LAN link-local address as WAN_DHCP6 gateway before?

I would appreciate any ideas regarding DHCPv6-PD, Router Advertisements or gateway discovery in this setup.

Thanks.

#9

Tutorials and FAQs / Re: [HowTo] OPNsense Boot Load...

Last post by Lucid1010 - November 03, 2026, 08:04:47 PM

https://forum.opnsense.org/index.php?topic=51959.0
https://forum.opnsense.org/index.php?topic=29304.0
https://forum.opnsense.org/index.php?topic=48145.0
https://www.reddit.com/r/opnsense/comments/1v7qqhn/26111_267x_upgrade/

Here are some links and bookmarks I kept from earlier.

Code Select Expand

sha256 /boot/loader.efi /boot/efi/efi/boot/bootx64.efi /boot/efi/efi/freebsd/loader.efi

Code Select Expand

efibootmgr -v

Code Select Expand

strings /boot/efi/efi/freebsd/loader.efi | grep "EFI loader"
Those commands look like they will be helpful as well.
However, what is the reason OPNsense itself doesn't update the bootloader when performing a firmware upgrade?

#10

Development and Code Review / Re: netflector available as pl...

Last post by UnicronHD - November 03, 2026, 07:48:03 PM

Thanks everyone! I'm surprised it has released already. I was expecting to wait until 27.x :).