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

#1
This doesn't directly answer your question, but I've been running the below script for years and it has yet to fail me:


#!/usr/bin/env bash

IP="$(curl -s http://ipv4.icanhazip.com)"

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID_GOES_HERE/dns_records/$RECORD_ID_GOES_HERE" -H "Authorization: Bearer $API_KEY_GOES_HERE" -H "Content-Type: application/json" --data '{"type":"A","name":"$DOMAIN_GOES_HERE","content":"'"$IP"'","proxied":false}' 1>/dev/null
#2
Likely best to use one of the many scripts available on the Internet for this. For example, https://steven-chau.github.io/2016-03-30-howto-detect-notify-ip-change/
#3
Quote from: foxint on April 16, 2024, 02:55:44 PM
(...)
My modem broke and I thought (since it used to work) I would connect the OPN-PC. It did not.
(...)

You mentioned 'NBN' previously.

If your NBN modem broke, you lost all Internet until NBN replace it, with or without OPNsense.

If your ISP-provided router broke, OPNsense can replace it.

As per @cookiemonster's suggestion, if it's the router, you should take some pictures of your equipment to provide more clarity.
#4
General Discussion / Re: Go to my local nas server
April 16, 2024, 09:35:43 PM
Quote from: tiermutter on April 16, 2024, 07:23:07 PM
Please remember what @meyergru mentioned:
This is not a safe way and the NAS GUI is reachable for anyone (this includes hackers / bonets). This is probably a Synology NAS I am not really firm with, so I don't know how much attacks are running to those devices... Having a QNAP NAS your data will be lost within a few months or weeks, depending on how intense attacks are run.

To add to the above, which is 100% correct (and based on your port it sounds like it's a Synology device), you might want to use something user-friendly like Tailscale (see https://tailscale.com/kb/1131/synology) to connect to your NAS from outside your network.

This allows you to access everything, without opening it up to the world.


Also, instead of NAT reflection, you can override the DNS for that host with 'Services: Unbound DNS: Overrides : Host Overrides'.
#5
Thanks, appreciate the additional context.

With RRD/Netflow disabled and RAM disk for tmp/logs, I'm at about 2GB/day, which given my NVMe's 500TBW rating I am happy with.
#6
Quote from: franco on April 15, 2024, 09:32:06 AM
First of all for your question to make sense you need to say if you mean on UFS or ZFS...


Cheers,
Franco

ZFS :)
#7
Quote from: 5kft on April 07, 2024, 04:57:59 PM
Indeed, when I switched from pfSense to OPNsense I was surprised by the huge amount of disk writes that OPNsense makes.  My gateway was averaging ~3.5GB writes/day, which I found to be rather excessive.  I did a bit of digging and with a few small changes I reduced the daily writes significantly (it's averaging 50MB/day now with no loss in functionality or stability). (...)

And I thought I was doing well with my 2GB/day! I'll have to look into this more to see what else I can reasonably disable. I'd prefer to stick to OOTB settings vs 'hacks', but might have to go down that path by the looks of it...

Quote from: 5kft on April 07, 2024, 04:57:59 PM
(...) There are a number of contributors to writes, one of the largest of which is the RRD data for the Reporting + Health dashboard in the OPNsense control panel.  This is actually straightforward to address - you can simply add an entry in your fstab for "/var/db/rrd" as a tmpfs volume (I use a 64MB volume size for this, also a reboot will be necessary to enable this).  Then go  to System + Settings + Miscellaneous in the OPNsense control panel, then in the "Periodic Backups" section, and change the "Periodic RRD Backup" to "Power off" for maximum write savings (or pick a backup time period you would like). (...)

I actually have 'Periodic RRD Backup' set to 'Disabled'. I believe the system did this automatically when I turned off 'Round-Robin-Database' in 'Reporting: Settings'.

I just noticed that I might have discovered a bug related to this setting too, as my 'Health' dashboard is showing a blank page. Seems to be related to https://github.com/opnsense/core/issues/3141.

Console shows

systemhealth:1462 Uncaught TypeError: Cannot read properties of undefined (reading '0')
    at systemhealth:1462:67
    at Object.complete (opnsense.js?v=4567372b83d8bd1e:298:21)
    at c (jquery-3.5.1.min.js?v=4567372b83d8bd1e:2:28294)
    at Object.fireWith (jquery-3.5.1.min.js?v=4567372b83d8bd1e:2:29039)
    at l (jquery-3.5.1.min.js?v=4567372b83d8bd1e:2:79928)
    at XMLHttpRequest.<anonymous> (jquery-3.5.1.min.js?v=4567372b83d8bd1e:2:82254)
#8
Probably best to start reading the official documentation, or various Internet tutorials before going any further.

OPNsense is 'deny by default', so unless you explicitly set allow rules for your newly created LAN2/LAN3 interfaces, nothing will get out.
#9
Quote from: SerErris on April 04, 2024, 12:27:04 AM
(...)
I do not see the source in the outgoing rule as it is NAT protocol.
(...) Because of NAT the original sender would not make sense as the destination server would not know how to reach my client behind the firewall.
(...)

Apologies, missed that on the first read.

Does enabling 'Log packets matched by automatic outbound NAT rules' under 'Firewall: Settings: Advanced' possibly help with that?

#10
Good to hear.

You might want to redact your personal (public) IP from these logs/screenshots, unless yours is dynamic and changes in the next few hours anyway.
#11
I recently checked my SMART data after a fresh install, and noticed that 'data written' was at ~200GB/week. This was with 'Reporting: Unbound DNS', 'Reporting: NetFlow', and 'System: Settings: Logging' enabled.

After disabling Netflow and Unbound logging, and moving tmp/log to RAM, I managed to decrease 'data written' to ~2GB/day. While this is a significant decrease vs what it was previously, I still feel like that is relatively high given everything should be in RAM now.

Could someone provide some insight here? I searched online, but aside from multiple users raising the high disk writes, no further detail was available. Would be great to understand why it's still 2GB/day, even though tmp/log are in RAM. Especially given that available storage space is not decreasing by anywhere near that number.

A quick look at iotop did not show any obvious culprits.
#12
Not sure how you set up your firewall rules / what you expect to see, but this looks like standard 'clients going through the WAN interface'.

I haven't checked all of your IPs that are shown in the screenshot, but some, and they look 'normal'.

172.253.115.100 -> Google
167.235.201.139 > pool.ntp.org
162.125.6.20 -> Dropbox
184.86.251.146 -> Akamai
#14
Quote from: zan on March 26, 2024, 05:56:10 AM
Shouldn't ntpd only connecting upstreams during polling time?
I've forgotten how ntpd behaved, been using chrony for the past ten years or so.

I have switched to chrony, and everything is working as expected now. I can see every client in my LAN with 'chronyc clients', even the ones that were not explicitly set to do so.

Thanks for that pointer!

Would you happen to know if I still need to set a cron job for OPNsense to update its time via chrony, or if the plugin takes care of that now? I've run into the same situation as this post here https://old.reddit.com/r/OPNsenseFirewall/comments/18hcnlk/chrony_nts_wont_syncronize_the_localhost_firewall/
#15
I may have found the error.


Up until now, my assumption was that the NTP redirect should stop at the gateway, as that is where the OPNsense NTP server is bound to.

However, using ntptrace on a host that had the OPNsense NTP server specifically set (i.e. no redirect), it goes from localhost to the gateway, to the 'Active Peer' visible under 'Services: Network Time: Status' in OPNsense.


I had thought it would stop at the OPNsense gateway and consider this the 'server', not connect to the 'Active Peer' on the Internet.

Clearly that was a misunderstanding on my part.