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 - OmnomBánhmì

#1
Ah! So that is what backscatter is all about, clogging logs and the internet pipes. Thank you, it is clear to me now!
#2
I understand what your reply is, Maurice, but I fail to understand how that is an answer. :-) Sorry if I may seem ignorant, but I feel something is missing.

To be clear, the peer I connect to from a client ofc knows my client's public key. I have not configured an address where I'd be connecting from, or an outgoing port that I'll be using. The instance thus knows "a client may connect and for the tunnel will have this tunnel IP address", nothing more. No static configuration for the origin IP address.

In my understanding, the peer where I connect to knows not in sufficient detail anything that lets it know where to connect to, or warrant the attempt to connect to my client. Outgoing connection attempts however persist peer reboots.

I'm not worried, I may just lack the understanding of UDP or Wireguard in this respect. If it clearly is a layer 8 problem please point me to a reference document. :-)
#3
My question is about what I see in logs of my OPNsense home router, relating to UDP traffic from other routers that is rejected. The "Default deny / state violation rule" catches these.

I do connect to those same endpoints with Wireguard occasionally so its all well-known IP addresses. The Wireguard endpoints the traffic is now unexpectedly coming from are remote locations I maintain. All routers run OPNsense.

My logins to remote sites are in roadwarrior mode, i.e. my home router establishes no site to site connection with the targets. I may happen that my local clients leave their tunnels up 24/7, but more often I shut them down as clients go "powersave"-off after work. I see these log entries for days after my last connection. My impression, it seems to not matter at all if my clients are connected that moment or not, or how long ago the last tunnel went up or down.

So somewhat surprisingly, protocol, address and source port number match my client setups. The destination port seems random. The scale is roughly 4:1 on my home router, i.e. source IPv4 of the remote sites in questions addresses make for 4x the amount of any other, as seen in Firewall Log Files - Overview - Source IPs.

General setups follow the OPNsense documentation, vanilla works for me. NAT reflection for port forwards and automatic outbound NAT for Reflection is off on the targets, and enabled on my home router.

Some of this is plausible, because any of these remote origins can know this router's public IPv4 and client Wireguard port number. The logs though suggest something is trying to contact back as if a connection that way was configured. It isn't, no remote clients are set up for establishing a tunnel towards my home location. Source seems to be the remote router itself in any case, but since I have not configured anything in the remote networks to connect "back home" to me I wonder. Is it all backscatter and really not noteworthy? Sure it is all noisy in the logs.

What mechanic is that traffic coming from?

#4
After failing with a Zotac 337 nano I now use those CWWK-built, Topton branded Intel N150 2 port "Pocket NAS" mini PCs from AliExpress to replace Zotac C327 devices (~120 Euros inkl shipping). Main routers are DEC700 series, the new N150s are for failover.

These have a fan built in which runs at low speeds all the time, they stay inaudible unless you make ear contact. What I did following forum advice was replace the thermal grease in all spots, and now they run mostly below 50C now (45-47C often), a handful degrees cooler than with the default stuff. The boxes handle 1gbps line speeds with ease including IDS/IPS on internal interfaces.
#5
Italian - Italiano / Re: OPNSENSE + WIREGUARD+FRITZBOX
January 31, 2025, 10:56:19 AM
I think so, yes. Every interface (and wireguard is just another one) is firewalled. With a Fritzbox you automagically forward traffic from incoming interface (Wireguard or other VPN) towards the internal network. No choice there. In OPNsense that scenario takes one extra step.

If you add a rule in Firewall > Rules > wg0 (what ever your number is) then you can allow traffic from wireguard to the FW4LN on its LAN address. Basically the procedure is described in the site to site docs, around step 5 (if I read the Italian correctly) - just set the target address properly.
#6
FTR, I still haven't solved the actual issue, that is "how to passively detect WAN issues". Thinking about putting an SBC onto the WAN as a sole device and log what I get (which may be not much, but I have an otherwise underused Pine64 board here).

The traffic shaping tips may help, will try them soon, thank you OPNenthu!

cobbers83, any change? I still have the same thing.
#7
The logic of Wireguard is: it presents as an interface. The peer needs no knowledge of how many or where an interface is.

So the same logic applies as you already have for incoming traffic: you need a firewall rule for the scenario to direct your outgoing (outgoing from where? From the wg0 or whatever its called) towards the preferred other interface.

This presupposes that your Wireguard instance has an interface; there's ways to go without and with an explicit interface. You'll need the explicit version for what you want.
#8
The question may seem odd, so I'll explain. In order to diagnose intermittent outages with my DOCSIS internet provider I'd like to sneek peek into the WAN network. The cable modem works in bridge mode. The connection has dual stack.

From time to time there's outages, a few seconds long at a time, irregularly (every 1 to 4 hours) but consistently multiple times a day. There is no service interruption, WAN interface stays up, and all clients notice a sudden lag. If you're in an RDP session the connection stalls, breaks down and needs to be re-established. Most other things run as usual after the hiccup.

If this were on a LAN connection on any Linux box I'd use ss, sar and arp next to Wireshark and such to build some knowledge about who's connecting and who is there (on the ISP end) in the first place. Since I'm on OPNsense this will not work, right?

Since calling the ISP leads to suggestions "please restart your router" and no observable improvement, what do you suggest I do instead to track down issues? Any ideas?
#9
Na dann erst mal weiter beobachten. FWIW, hier auf einem älteren Zotac mit N3450 und Realteks sind sowohl realtek-re-kmod als auch os-realtek-re installiert.

kldstat sagt der if_re.ko ist geladen. (Hier im FreeBSD-Forum steht welcher welcher ist https://forums.freebsd.org/threads/if_re-for-rtl8125-module-loads-no-device-output.89372/ )

Schönes Wochenende!
#10
Realtek ist etwas haarig, das mag sein. Aber nicht per se. Ich betreibe eine reichliche handvoll MiniPC mit Realteks im Einsatz, und da läuft alles rund - die arbeiten als failover und selten unter Volllast, doch durchaus mit Dualstack und mit verschiedenen Bandbreiten bis 1gbps. An der Umstellung sollte es nicht geniun liegen.

Am Log sehe ich auf den ersten Blick keine Ursache. Wird das Gerät wärmer als vorher?
#11
This is a little hard to diagnose. :) Try testing with these methods and post/report the responses you get, for each of your subdomains:

$ curl -v https://prod.youraddre.ss -o /tmp/test

This will give you metadata about the connection, and redirects will show. You may look for subjectAltName, Host and location values (and others).

Web-based tests do not show as much detail, however https://deref.link/ and https://wheregoes.com/ may help too.

#12
Ohne einen Auszug aus den Systemlogs wird man auch nicht schlau draus, wir auch nicht. Poste doch mal daraus die letzten paar Zeilen vor dem Ausfall bzw. bevor der aufgehört hat überhaupt etwas zu loggen. Sonst bleibt deine Frage unbeantwortbar. :)
#13
For people searching for a low price fanless box to run OPNsense on, I can comment on what maybe not to buy. YMMV, but my idea was to buy another Zotac Zbox, since I run a large handful of these in older hardware iterations (CI327 nano) with N3450 for branch offices as failover since ca. 2018. So it seemed a safe bet.

TL;DR Experiments failed with the CI337 nano.

For context, the N3450s all work nicely with lines up to symmetric 1 gbps speeds, most offices have lower bandwidths though. However they all max out at around 640mbps. Unsure why that is, however I didn't care too much since these boxes are companion failover to DEC740 devices that do handle everything we throw at it without hiccup. So failover barely happened in a handful of years and if it did the CI327 nano was good enough for the specific purpose.

There's Realtek chips in the CI327 nano as well as the newer CI337 nano. So I thought let's get one of those and test on a DOCSIS gigabit. Mixed results here overall, line speed when it works, but no stable connection. Either I get 1 hour of uptime or maybe even 4 or so, but then inevitably b0rkage happens:


  • data throughput drops to zero
  • OPNsense UI is a no show
  • pings to the CI337 might still work though
  • ssh login might work, but more often the box does not respond on any TCP port
  • its HDMI output goes blank, i.e. I can't see any on-screen messages - if I see any it often repeats emulated netmap adapter rel_vlan entries with either destroyed, created, activated messages. After that repeated I see dropped packages
  • a keyboard needs to be connected for a ctrl-alt-delete reset
  • box is up again after rebooting, log entries are unremarkable

Looking for answers I found what everyone else may find: the useful posts with caveats here in the forum (heat dissipation, comments re Realtek chips, Intel firmware and microcode, power supply issues), and also comments on amazon re BIOS/UEFI updates. Well, none of what I tried fixed the issue: switch power supply and makeshift usb fan cooling. About 4 hours of uptime was the maximum I got.

So I'm returning this CI337 nano unit to the vendor. What I do like about Zotac is their size and sturdy build. The general reliability of the older model though... whatever, time to move on.

Next up, I'll go for N100 again with Intel i226-v this time. Protectli boxes seem a good next step at the next price level. For our branch offices SFP+ would sure be nice to have for upgrading the failover game, should I make the time for CWWK attempts there's boxes with that too.

I'll keep reading in the forum, thank you meyerguru and everyone who is active here with answers. This post is my 2ct. :)
#14
So with a handful of branch offices, on each site's OPNsense router we have a locked down user role that enables local staff to check things like failover status, WAN details and such. Read only for configuration, few menu items, and with "reboot" enabled among very few action options.

Now the Effective Privileges don't seem to exclude, or I haven't found or understood it, a way to lock down this user, dashboard-wise. So, ocassionally I find widgets changed or content added. Trying not to be paranoid, but if users can upload their own animated GIF file to the Pictures widget.. cat memes or not, I won't think that is a good idea and plan to change this setup. So I'll no longer holding it wrong.

If you have a similar model, enabling local staff to interact with OPNsense, how do you do a (mostly read-only) status page?
#15
Thank you all for the detailed replies! I'll check with page in / page out activity, however I do suspect I let myself be fooled by being more familiar with Linux, so may not rush towards upgrading.