Had one incorrect CIDR included. Solved

@kdmiller61 For one web server, a NAT port forward. For multiple, a oroxy as noted.

They should use them when they try to pull a new lease. So if the client is rebooted it should pull the new static lease.

@Jarhead said in Travel Netgate Box:

Although FreeBSD 14 has started to support wifi6,

It supports some wifi6 hardware but not at 802.11ax speeds. And as far as I know none of it supports hostap mode so they are client only.

OMG!! Just checked the date stamps! That came through about 5 minutes after I submitted the original request. Now the stupidity and blunder rests upon me. I will have to add +.@netgate.com to my whitelist.
Thanks for gentle reminder.

-d

Check in sysctl dev.igc.0 for example

well spoke too soon...... may be a hardware issue.

Got around this morning to contacting support about the change in NDI from the "repair".

Essentially told to pound sand with the Plus upgrade.. So I guess grandfathering in the Plus for homelab is not a thing anymore. :(

That's too bad.

@kdmiller61 said in Hosting websites from Germany:

my internet provider will charge a huge amount of money for a static IP like I had in the states

So you checked on that already? Or your assuming?

Is your IP actually changing? I have a dynamic IP, and its only changed once in years. And that was when the isp merged with another isp and redid all their address space.

Normally the way dhcp is suppose to work, is as long as you are renewing the IP it shouldn't change.. Only when you have not renewed and the lease expires could the lease be given to someone else.

@stephenw10 I still have more questions. I access pfSense through a browser that is on my network. To secure the connection between my browser on my PC and pfSense's webGUI I need to configure a certificate issued by my CA inside pfSense? My browser still has (Error code: SEC_ERROR_UNKNOWN_ISSUER) when I access pfSense's webGUI. This is not a globally recognized CA this is a private CA running within my local network.

https://smallstep.com/certificates/

My current understanding of setting up certificate authentication is as follows:

Certificate Authority generates the root certificate Root certificate or Root fingerprint needs to be upload and installed on each individual server that trusts the CA Each server then needs to be issued a certificate from the CA. Each service within the server needs to be configured to use that certificate issued by the CA. After this if you have the root fingerprint or root certificate installed on your client you will trust all certificates issued by the CA.

I'm still looking for specific advice on configuration.

What is the difference between a root certificate and a root fingerprint? Can I paste my CA's root fingerprint directly into the 'certificate data' field? Then just upload a certificate that my CA issues into pfSense.

How should I handle Certificate Signing Requests in pfSense? After generating a CSR in pfSense, what is the correct process to get it signed by my private CA and correctly installed?

Is having a certificate signed equivalent to being issued a certificate by the CA?

@stephenw10
yes that's true, we try to buy one to donate (don´t need support), but we need an NDI.

That's why the idea comes up to offer the "TAC Donation Only" or maybe an "pfsense CE Donation" item in the shop...

Edit: Or can we have a donation NDI?

Probably hitting this if that's an authenticated upstream proxy:
https://redmine.pfsense.org/issues/15094

Steve

Ah, OK. 2.8 snapshots are not public right now so you can't update that.

@NollipfSense I think you're correct as per https://kea.readthedocs.io/en/kea-1.6.2/arm/dhcp4-srv.html

Thanks!

Yes you can do that: https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html

@stephenw10 @SteveITS

Thanks both.

I think the curiosity of what gets moved is satisfied. The empty / small directories in the following, have not been considered.

Consider the following from the dashboard where
/var is reported as 53M on tmpfs
/var/cache/pkg is reported as 161M on zfs
/var/db/pkg is reported as 5.2M on ifs

Screen Shot 2023-12-23 at 9.35.03 AM.png

then consider this.

[2.7.2-RELEASE][bob]/var: du -sh /var/* 0B /var/at 161M /var/cache (on zfs Dashboard /var/cache/pkg 161) 0B /var/crash 0B /var/cron 41M /var/db (on tmpfs) 8.0K /var/dhcpd 0B /var/empty 33K /var/etc 8.3M /var/log (on tmpfs) 94K /var/run 0B /var/spool 0B /var/tmp 326M /var/unbound (on zfs based on size of var located on tmpfs but not accounted for on dashboard)

total on tmpfs 41 + 8.3 = 49.3 (daahboard shows 53 on tmpfs) - not concerned about this, could just be the way the tmpfs does "It's not preallocated anymore." I don't see any hidden files/directories Also easy enough to test.. I could just drop a large file each and see where it is counted.
curious is "It's not preallocated anymore." a one way street? or if a bunch of stuff gets added and removed does the tmpfs allocation shrink. of course also easy enough to test.

The dashboard doesn't account for the 326M under /var/unbound. This should likely be another of the entries similar to /var/cache/pkg and /var/db/pkg both of which remain on zfs.

Not the end of the world, just things don't add up and therefore is somewhat misleading.

also values before and after are zfs compression vs. tmpfs not 💡

The interface stats are generally since the interface last went down where as the traffic totals could be for whatever internal you selected.

I would normally both In and Out to be higher or lower though. I'm not sure what scenario would show in lower but out higher.

Steve

None that I'm aware of currently.

@stephenw10 Pretty Please fix it upstream :)

Nice!