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

#1
QuoteYeah I've ruled out CG-NAT because I was successfully port forwarding until I switched to OPNSense. The only thing I've changed in my setup is the router so I'm pretty confident that's where the problem lies.

Sorry, but unless you spoofed the MAC address of your old router, this isn't good enough.

I know ISPs that give you CG-NAT and only hand out a real IPv4 when the user configures Port Forwarding in their customer center (router is not locally configurable, only over the ISP webpage).


Here is how you can test it in under 5min:
https://github.com/jameskimmel/opinions_about_tech_stuff/blob/main/network%20stuff/CG-NAT.md



QuoteOPNSense is acting as my router and its wan port is connected directly to my modem via an Ethernet cable.
So your modem is in bridge mode, right?
Test from above will show this.



Maybe to make this a little bit easier to troubleshoot, could you just create a new rule for port http (80) and see if certbot (I assume you use certbot?) is able to get a cert?
#2
Das ganz normale Backup unter  System -> configuration -> backups beinhaltet VPN.
Und beim restore kannst du auswählen, nur OpenVPN wiederherzustellen.

Das was du suchst, kannst du also easy damit machen.

Wobei ich nicht ganz verstehe, warum du das als Grundconfig für andere Firewall möchtest. Dann hättest du auf anderen Firewalls die gleichen Keys, was vermutlich nicht so clever ist.
#3
General Discussion / Re: Current Best Practices
May 25, 2025, 12:05:56 PM
Gotcha.

I do almost the same. All services point to my dual stack nginx.
I do SSL only on the Proxy and proxy pass http from there. Since the proxy and the service VM are the only two devices in their own VLAN, I don't see a reason why I would use SSL internally.
#4
General Discussion / Re: Current Best Practices
May 24, 2025, 12:51:43 PM
Thank you Patrick, really appreciate your answers.

Quote from: Patrick M. Hausen on May 24, 2025, 12:26:33 PMInternet --> IPv6 GUA --> Caddy --> e.g. Nextcloud via IPv4.

To play devils advocate here, why not use that static GUA IPv6 instead? Tried that with one of my services, worked great.

QuoteIt seems you are finally getting to the same conclusions as me.
I am a little bit slow :)

QuoteTo put it short: You are making it hard on yourself and try to remedy problems that you create by insisting to try "IPv6 only" without a good reason.

That is a fair point. My reason is not technical, but mostly for fun. My switch might be a little bit faster (nanoseconds) using IPv6 for the last part? Who knows? ;)

But what is cool about ditching IPv4 is that you need less stuff. Like a DHCP server. I am currently using ISC. Why not shutting it down, instead of migrating? Here is just one recent learning I got from doing that:

I was wondering why my invoice software shows an update but then times out trying to do that over the webGUI. Turns out it gets the update from Github. And Github is still IPv4 only :)
#5
General Discussion / Re: Current Best Practices
May 24, 2025, 12:06:16 PM
I also only need DNS for things I want to access. Well not even then, to be honest. I want to reach my invoices tool, I use the public FQDN, which goes to my proxy. I am just unsure if that proxy should internally use an IPv6 or a hostname to proxy_pass the traffic.

Will take a look at Avahi, at a glance this looks like mDNS. Do you access only local devices or do you have some kind of multicast repeater on OPNsense running?
#6
General Discussion / Re: Current Best Practices
May 24, 2025, 11:53:40 AM
Cheers Patrick for your answer.
I think Ubuntu (netplan) does, but not Debian.

Hmm... Not really what I wanted to hear to be honest :)

If I have to enter the IP to my DNS manually, why even bother?
Just so I can enter the hostname into the proxy_pass instead of that IP?
Sounds like the same amount of work, but now my proxy is dependent on the DNS.

What I wanted to hear is:
SLAAC just like IPv4 watches for new DHCP leases.
But just like @meyergru said;
QuoteThere seems to be no equivalent for /var/dhcpd/var/db/dhcpd6.leases.


Which brings me to my next question.
Should I use DHCPv6 for these VLANs?
I again can't really find any advantages, am I missing something?

By assigning IPv6 with DHCPv6, my client gets a static IP, and this is hopefully also registered in the DNS.
But at the same time, my client gets a static IP anyway, so again, sounds like the same amount of work, but now my proxy is dependent on the DNS.

Is DHCPv6 only really useful, if you don't have a static prefix?
#7
General Discussion / Re: Current Best Practices
May 24, 2025, 10:38:30 AM
So if I understand it correctly:

A default Ubuntu gets three IPs.
First one I can't use (is not static because privacy extension).
Second one has a static suffix, plus a static prefix, because the prefix from my ISP is static.
Third one is link local. Will not work over different VLANs.


So I could use the second or third one. But then I am back to the old IPv4 way of remembering IPs instead of using DNS.
Could I use mDNS instead? This should work out of the box without any changes from my part?
Would mDNS be stable enough to be used in a reverse proxy as proxy_pass?
Probably too risky, right?
#8
General Discussion / Re: Current Best Practices
May 23, 2025, 08:22:20 AM
Quote from: EricPerl on May 21, 2025, 06:15:13 PMUnbound can only deal with dynamic leases from ISC. The setting is "Register ISC DHCP4 Leases" for that reason.
Static leases are read from the OPNsense config...

Sorry for being dense, but does that mean that in a IPv6 only VLAN, unbound has no way of knowing clients?
Does that mean that device1.home.arpa will always get an IPv4 as response?
#9
General Discussion / Re: Current Best Practices
May 21, 2025, 08:09:55 AM
Quote from: EricPerl on May 20, 2025, 08:31:17 PMAFAIK, the prerequisite for DNS registration of STATIC mappings are:

Ahh sorry, I don't mean static I mean the IPs that devices got from SLAAC.
#10
General Discussion / Re: Current Best Practices
May 20, 2025, 07:27:22 AM
That is correct, I use unbound. But even after restarting unbound and the host, there is still no DNS entry for apache2.home.arpa.


I don't know what you are asking exactly about the PKI. I don't use proxies for that. I have a key pair for every host and the public keys are saved on github, simply because many OS allow you to import them from there.


The option with the fake valid from date was to bothersome for me, so I switched from Safari to Firefox for my homelab. 
#11
General Discussion / Re: Current Best Practices
May 19, 2025, 09:09:19 PM
I have read that DNSmasq is only the new default for IPv4 (which I don't intend to use anymore) so I will stay with unbound for DNS.


Today I test migrated one of my VLANs.
This VLAN has two hosts, a Webpage and one network adapter of the NGINX reverse proxy.

This lead me to some new questions.

1. How would I access this host (ssh without the proxy) over DNS? When doing an nslookup -6 apache2.home.arpa I get a NX domain. Should unbound not have saved that? Do I have to add home.arpa to "Private Domains" under unbound advanced?

2. Even if unbound would answer me, which IP would it use to answer? Because the link local would not work for SSH, since I am in another VLAN.

3. Would it be smarter to use the GUA instead of DNS for NGINX proxy_pass? It is mostly static and not dependent on working DNS? Or why not go even one step further and use the link local IPv6? This one is even static if I change internet providers. And since my NGINX has interface in each VLAN anyway, it should be able to route that?
#12
General Discussion / Re: Current Best Practices
May 19, 2025, 08:50:03 AM
cheers guys for your answers!
I will try to run an IPv6 only network and switch from static IPs to DNS. Also switch from Kea to DNSmasq.
#13
General Discussion / Re: Current Best Practices
May 17, 2025, 07:54:15 AM
QuoteMost definitely not. Why? Because of your internal networks. This is especially true if you have an ISP who hands out dynamic GUA ranges.

I have a good ISP. Good ISPs follow RIPE recommendations. AKA I get a static /48 prefix.
Are there any other points you see against IPv6 only?

I am not sure if can NGINX reverse proxy from my IPv4 WAN to an internal IPv6. Should be possible, will have to give it a try.

QuoteI do that in much the same way. And read this on why your certificates may not be accepted by some browsers.
Looks like I have to switch from Safari to Firefox for my homelab stuff then or try if Safari accepts certs from before 2020. Thank you for that tipp!


QuoteIf you fear internal DNS poisoning... I do not.

My neither. But to be fair, I also don't fear MITM attacks on my local network. So I am not sure if I even think that https is worth it internally.


Cheers for these great inputs.


QuoteIf you're considering IPv6 with privacy extensions for outbound (as client devices may be want to do), you may run into an unresolved issue:

I think I never had any problems with IPv6 privacy extensions. But you are making a great point on why to disable IPv4. I would not notice if IPv6 is broken. I don't use google, let alone ipv6.google.com for searches :) So without IPv4 I would notice it and could start to troubleshoot.
#14
General Discussion / Current Best Practices
May 16, 2025, 02:55:05 PM
Hi guys!

Sometimes we do things a certain way, just because we did it like that in the past. I am in no way immune to it :)

Anyway, I don't want to end up like people I see often, that don't use IPv6 or even suggest turning it off, just because I am stuck in the nineties with some ways of thinking.

And sometimes you think afterwards "how the hell did I do it in that bad way and wasted so much time on it" (me taking way too long before switching to public key auth).

So here are my questions:

1. IPv6 only
Is it time to go IPv6 only already? Like why bother with DHCPv4 and stuff? Just because of some sites? Why not just use NAT64 for these instead?
Currently it seems to me that enabling IPv4 is still the more foolproof. On the other hand, if you disable IPv4, some IPv6 misconfigs are easier to detect.
Like I was wondering why my Pihole was so slow. Turns out it first timed out for IPv6 (because of some misconfig) and then falls back to IPv4. That would not have happened without IPv4, then it would just not have worked.

2. DNS instead of static IPs
Currently I am still using static IPv4 for stuff like accessing Pihole VM over SSH.
Instead of just switching that to IPv6, I was wondering if this is obsolete anyway. Why not just use DNS instead?

3. Certs
For everything public I am using Certbot. But for internal stuff, I am using self-signed certs (intermediate CA). Simply because there is no Certbot for stuff like a Supermicro IPMI.
I choose certs to be valid for 10y. Some browsers like Safari, complain about the cert not being up to standard because of that long lifetime. Is there any other way of doing it the right way? I am hesitant on using DNS certs, since I fear the one compromise would compromise the whole setup instead of just one subdomain.


4. .internal instead of .arpa
I was under the impression that best practice is to use something like home.arpa.
Docs suggest that I should rather use something like home.internal

5. HSTS and .internal
Docs also recommend to use something like lan.internal.mydomain.com
But what if mydomain.com is preloaded for HSTS?
My guess would be that internal isn't excluded from HSTS?
But of course you could argue that everything should be encrypted, even local connections.
My NGINX reverse proxy uses http for some internal hosts.


6. Do you use DNSSEC for local recursive unbound?
I fail to say much security gains for my local recursive DNS unbound being recursive. Anyone using DNSSEC that points to their local unbound? 
#15
Hardware and Performance / Re: SDD fast wear ?
April 29, 2025, 12:06:08 PM
Quote from: Lebowski89 on April 28, 2025, 03:29:31 PMSmells like ZFS. I wouldn't run ZFS-related things on any low-write consumer SSD.


"Just turn off ZFS" is the new "Just turn off IPv6". It is mostly misguided.

If you don't have a misconfigures pool that suffers from write amplification (which mostly applies to RAIDZ, which nobody should use for OPNsense anyway), ZFS has double the writes. But that is only for sync writes, not for asynchronous writes.

Even cheap, modern consumer SSDs (that aren't QLC) offer a very high TBW endurance that you will never ever be able to reach with OPNsense defaults.

As a reference, even a cheap 970 EVO 500GB offers 300TBW. After 2,5 years, I got 18TB on my OPNsense.
If the workload keeps the same, I am looking at roughly 40y before I reach the TBW.