"Recent posts
#81
General Discussion / Re: Micron exits consumer mark...
Last post by meyergru - December 08, 2025, 09:38:05 PMOr you go cheap (as I did) and switch to Intel 12th-14th gen. Those LGA1700 boards are still available and many use DDR4. New AM4 boards are unobtanium. And having had the experience of a 400€ board passing out after less than three years, I am not too keen on trying a used/refurbished one.
I never had failing RAM until now, only mainboards. I think it is getting worse with the voltage regulation now on the mainboards instead of the PSU and the obscene power draw of modern CPUs.
I never had failing RAM until now, only mainboards. I think it is getting worse with the voltage regulation now on the mainboards instead of the PSU and the obscene power draw of modern CPUs.
#82
General Discussion / Re: Micron exits consumer mark...
Last post by OPNenthu - December 08, 2025, 09:31:14 PMQuote from: coffeecup25 on December 08, 2025, 03:50:37 PMSeriously, I recently looked for 16GB DDR4 and a larger SSD to upgrade an old laptop and was surprised at how the prices had gone up.
Quote from: meyergru on December 08, 2025, 04:45:36 PMYup, sometimes, this hits earlier than one thinks... Yesterday, I found my Proxmox server getting unstable until I increased Vcore by 100mV - obviously a VRM is on its way out.
I recently got my first NAS (a DXP4800 Plus appliance that I replaced the boot drive and put TrueNAS on it) and was lucky to have found a compatible 64GB kit *just* as the prices started to climb. Had to return the first kit I tried due to Memtest errors. Close call on that one. :)
My desktop is on borrowed time. I've had the same DDR4 kit over three CPUs now. It's the end of the road for my AM4 and any failure would mean DDR5 or newer now (unobtainium). I should probably hire a priest to bless it...
#83
Q-Feeds (Threat intelligence) / Re: Looking for testers Q-Feed...
Last post by Q-Feeds - December 08, 2025, 09:28:38 PMHi vpx,
Thank you so much for letting us know, we had no clue since we're not using Outlook Classic. That said we've added an explicit width to the header in the email now, hoping it's solved for Outlook Classic. Please let us know, much appreciated.
Kind regards,
Stefan
Thank you so much for letting us know, we had no clue since we're not using Outlook Classic. That said we've added an explicit width to the header in the email now, hoping it's solved for Outlook Classic. Please let us know, much appreciated.
Kind regards,
Stefan
#84
Virtual private networks / Re: Need WireGuard Peers with ...
Last post by Monviech (Cedrik) - December 08, 2025, 09:27:45 PMYou wrote quite an essay there.
The model comma separates values automatically. Just enter a range without comma, press tab, enter the next range without comma, and so on.
The model comma separates values automatically. Just enter a range without comma, press tab, enter the next range without comma, and so on.
#85
German - Deutsch / Re: Probleme mit DNS + VLAN + ...
Last post by mfreudenberg - December 08, 2025, 09:23:05 PMPing-Tests
Ping auf die Switch-IP geht
Ping auf die OPNSense-Client-IP geht (mit pfctl -d)
Ping auf OPNSense-WAN Adresse geht (mit pfctl -d)
Ping auf Fritz!Box geht (mit pfctl -d)
Ping auf 1.1.1.1 geht scheinbar nicht
Diverse nslookup's
Der Client verwendet den OPNSense-DNS 172.17.50.253 (wird via DHCP bereitgestellt)
Ping auf die Switch-IP geht
Code Select
PING 172.17.50.254 (172.17.50.254) 56(84) Bytes an Daten.
64 Bytes von 172.17.50.254: icmp_seq=1 ttl=254 Zeit=6.30 ms
64 Bytes von 172.17.50.254: icmp_seq=2 ttl=254 Zeit=11.1 ms
64 Bytes von 172.17.50.254: icmp_seq=3 ttl=254 Zeit=6.43 ms
64 Bytes von 172.17.50.254: icmp_seq=4 ttl=254 Zeit=4.74 ms
Ping auf die OPNSense-Client-IP geht (mit pfctl -d)
Code Select
PING 172.17.50.253 (172.17.50.253) 56(84) Bytes an Daten.
64 Bytes von 172.17.50.253: icmp_seq=1 ttl=64 Zeit=2.54 ms
64 Bytes von 172.17.50.253: icmp_seq=2 ttl=64 Zeit=2.34 ms
64 Bytes von 172.17.50.253: icmp_seq=3 ttl=64 Zeit=1.91 ms
Ping auf OPNSense-WAN Adresse geht (mit pfctl -d)
Code Select
PING 192.168.127.9 (192.168.127.9) 56(84) Bytes an Daten.
64 Bytes von 192.168.127.9: icmp_seq=1 ttl=64 Zeit=35.9 ms
64 Bytes von 192.168.127.9: icmp_seq=2 ttl=64 Zeit=5.31 ms
64 Bytes von 192.168.127.9: icmp_seq=3 ttl=64 Zeit=5.87 ms
Ping auf Fritz!Box geht (mit pfctl -d)
Code Select
PING 192.168.127.1 (192.168.127.1) 56(84) Bytes an Daten.
64 Bytes von 192.168.127.1: icmp_seq=1 ttl=63 Zeit=5.41 ms
64 Bytes von 192.168.127.1: icmp_seq=2 ttl=63 Zeit=5.03 ms
64 Bytes von 192.168.127.1: icmp_seq=3 ttl=63 Zeit=5.21 ms
Ping auf 1.1.1.1 geht scheinbar nicht
Code Select
PING 1.1.1.1 (1.1.1.1) 56(84) Bytes an Daten.
^C
--- 1.1.1.1 Ping-Statistiken ---
62 Pakete übertragen, 0 empfangen, 100% packet loss, time 62493ms
Diverse nslookup's
Der Client verwendet den OPNSense-DNS 172.17.50.253 (wird via DHCP bereitgestellt)
Code Select
nslookup heise.de
;; Got SERVFAIL reply from 127.0.0.53
Server: 127.0.0.53
Address: 127.0.0.53#53
---
nslookup heise.de 172.17.50.253
;; Got SERVFAIL reply from 172.17.50.253
Server: 172.17.50.253
Address: 172.17.50.253#53
** server can't find heise.de: SERVFAIL
---
nslookup heise.de 1.1.1.1
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached
#86
25.7, 25.10 Series / Re: 25.7.9 update and WireGuar...
Last post by Monviech (Cedrik) - December 08, 2025, 09:23:02 PMEvery minor update there are voices thst say wireguard stopped working for them. It's almost predestined whenever a new update hits.
But historically it has never been the update, it was just the reboot and things with wireguard and DNS are always flakey.
Most people with wireguard issues also use adguard, coincidence?
The question is, did something change? Is there any entry in the version changelog you suspect?
But historically it has never been the update, it was just the reboot and things with wireguard and DNS are always flakey.
Most people with wireguard issues also use adguard, coincidence?
The question is, did something change? Is there any entry in the version changelog you suspect?
#87
Virtual private networks / Need WireGuard Peers with Mult...
Last post by mattlach - December 08, 2025, 09:17:28 PMHi everyone,
So it looks like the xml database frontend for OPNSense puts in place an artificial limitation that is unnecessary. WireGuard itself can accept multiple comma separated "Allowed IP" address ranges, but the web GUI frontend rejects multiple address ranges with the error message "Please specify a valid network segment or IP address."
But let me back up a little bit and explain why I need this.
Background:
I am a little bit of a privacy absolutist. I hate that my ISP is harvesting data about me based on my internet traffic. Several years ago Verizon was caught inserting so called "Super cookies" or "Zombie cookies" into every IP packet leaving their customers networks. Essentially they added a unique identifier to each customer into the IP packet on their side of the network, so users could not do anything about it.
Amid fierce criticism, they eventually walked this back, but given how tech companies have a practice of overstepping, walking things back, then waiting for the controversy to die down before trying again (possibly in a slightly different way) and hoping there isn't as much pushback the next time, I have absolutely zero trust that are not up to the same tricks again.
I want to be able to eliminate their ability to track me in any way I can.
To that end I use a trusted VPN partner to help anonymize my traffic. I know this means I have to trust the VPN partner, but in this case I do.
So, 100% of all traffic that leaves my network goes out via wg0 to my trusted WireGuard VPN.
The standard configuration here is to set "AllowedIP's" to "0.0.0.0/0" in order to allow all traffic to traverse this encapsulated link.
The Problem:
Initially I used the setup above to protect my home network, and the VPN providers app to protect my phone traffic when outside the house. It worked great for years, until suddenly it didn't. Not trusting my phone providers cloud service for any backups (again, due to privacy considerations) I have a script that syncs my phone to my own NAS on a regular time interval.
Recently, and suddenly this stopped working properly. In all likelihood this is a combination of the fact that I am double encapsulated when my phone connects to my local network via wifi, and an MTU problem where something in my upstream path recently changed causing VPN packets to be too large and run into MTU limits upstream.
So, I figured, I'll just stop using the VPN providers app on my phone, and instead set up my own Wireguard endpoint on my own network allowing my phone to connect to my own network remotely, and never be double encapsulated.
This requires an OPNSense setup with two separate WireGuard Instances. wg0 for the LAN traffic to reach the VPN provider, and wg1 as the server allowing my phone to connect to it.
The issue is that "AllowedIP's" cannot overlap. If you set AllowedIP's to 0.0.0.0/0 on wg0, this covers ALL IP addresses, so if you add any allowed IP's at all in wg1, then there is an overlap, and thus a conflict, and despite me checking the "disable routes" box on both wg0 and wg1, any time I enable wg1, traffic becomes horrendously slow and unreliable on wg0 due to the conflict, likely some sort of kernel routing issue.
If wg0 has allowed IP's as anything other than 0.0.0.0/0 it does not work. This is because the way they have their network set up, you need BOTH the endpoint of the remote WireGuard server AND the gateway on their network in the allowed IP address range, and since OPNSense has data validation that only allows one value in that field, there is no other way I can design it to cover both than to allow everything which is what you do when you set 0.0.0.0/0.
If I were writing the wireguard config file manually, I could just comma separate two strings as follows:
<endpoint IP>/32, <VPN gateway IP>/32
This allows me to set a separate AllowedIP range for wg1, that does not trample on the defined address ranges for wg0, and should work.
...but the OPNSense configuration does not allow this due to incorrect input data validation. I can still set it manually by editing /usr/local/etc/wireguard/wg0.conf, but the way OPNSense handles its config xml's, this is not persistent across reboots, and really feels like a hack. I might be able to force the issue by editing the main OPNSense xml config file manually, but I am not convinced that won't break something else, and also have persistence issues.
Another alternative to solve this would be to configure two separate peers using the identical public key, one that includes only the endpoint address in it's allowedIP's range, and another that includes only the VPN gateway in its AllowedIP address ranges. I am told this ought to work with vanilla WireGuard, but again I am foiled by input validation, as if I try to set up a second peer with the same public key, I get an error message that "public keys must be unique" and it won't let me save it.
Again, if I solve it this way, I could edit /usr/local/etc/wireguard/wg0.conf and do it manually, but it would have all the same issues associated with it (persistance/reliability) as the previous manual edit.
Here's the thing, I don't feel like my setup is that uncommon. There must be plenty of people out there who need more than one wireguard instance, and have issues creating allowedIP address ranges that don't conflict.
Questions:
1.) Am I missing something? Is there another obvious way of doing this I just am not seeing or haven't thought of?
2.) It feels like this is a rather crucial aspect of WireGuard that is just not implemented by OPNSense. Either the ability to add multiple comma separated address ranges to the "AllowedIP's" field or allowing multiple peers with the same public key should solve my problem, both of which can be done with WireGuard using manual configuration, but the OPNSense config input validation gets in the way.
I can understand why these input validation restrictions might be there, as if someone who is less knowledgeable mistakenly messes up the Allowed IP's field or creates multiple peers with the same public key it can cause all sorts of problems, but maybe these should be made available somehow under advanced settings to those of us who know a little bit more?
3.) Not sure if this is a "bug" but it might be (since I cannot use the full features of WireGuard) but at the very lest it is a feature request. How can I go about reporting it to get this resolved?
...because if I can't get this resolved, I'll have to spin up a separate VM (or maybe a container) that has its own WireGuard configuration just for the second WireGuard Instance, and that feels really dumb and wasteful.
I appreciate anyone's input.
So it looks like the xml database frontend for OPNSense puts in place an artificial limitation that is unnecessary. WireGuard itself can accept multiple comma separated "Allowed IP" address ranges, but the web GUI frontend rejects multiple address ranges with the error message "Please specify a valid network segment or IP address."
But let me back up a little bit and explain why I need this.
Background:
I am a little bit of a privacy absolutist. I hate that my ISP is harvesting data about me based on my internet traffic. Several years ago Verizon was caught inserting so called "Super cookies" or "Zombie cookies" into every IP packet leaving their customers networks. Essentially they added a unique identifier to each customer into the IP packet on their side of the network, so users could not do anything about it.
Amid fierce criticism, they eventually walked this back, but given how tech companies have a practice of overstepping, walking things back, then waiting for the controversy to die down before trying again (possibly in a slightly different way) and hoping there isn't as much pushback the next time, I have absolutely zero trust that are not up to the same tricks again.
I want to be able to eliminate their ability to track me in any way I can.
To that end I use a trusted VPN partner to help anonymize my traffic. I know this means I have to trust the VPN partner, but in this case I do.
So, 100% of all traffic that leaves my network goes out via wg0 to my trusted WireGuard VPN.
The standard configuration here is to set "AllowedIP's" to "0.0.0.0/0" in order to allow all traffic to traverse this encapsulated link.
The Problem:
Initially I used the setup above to protect my home network, and the VPN providers app to protect my phone traffic when outside the house. It worked great for years, until suddenly it didn't. Not trusting my phone providers cloud service for any backups (again, due to privacy considerations) I have a script that syncs my phone to my own NAS on a regular time interval.
Recently, and suddenly this stopped working properly. In all likelihood this is a combination of the fact that I am double encapsulated when my phone connects to my local network via wifi, and an MTU problem where something in my upstream path recently changed causing VPN packets to be too large and run into MTU limits upstream.
So, I figured, I'll just stop using the VPN providers app on my phone, and instead set up my own Wireguard endpoint on my own network allowing my phone to connect to my own network remotely, and never be double encapsulated.
This requires an OPNSense setup with two separate WireGuard Instances. wg0 for the LAN traffic to reach the VPN provider, and wg1 as the server allowing my phone to connect to it.
The issue is that "AllowedIP's" cannot overlap. If you set AllowedIP's to 0.0.0.0/0 on wg0, this covers ALL IP addresses, so if you add any allowed IP's at all in wg1, then there is an overlap, and thus a conflict, and despite me checking the "disable routes" box on both wg0 and wg1, any time I enable wg1, traffic becomes horrendously slow and unreliable on wg0 due to the conflict, likely some sort of kernel routing issue.
If wg0 has allowed IP's as anything other than 0.0.0.0/0 it does not work. This is because the way they have their network set up, you need BOTH the endpoint of the remote WireGuard server AND the gateway on their network in the allowed IP address range, and since OPNSense has data validation that only allows one value in that field, there is no other way I can design it to cover both than to allow everything which is what you do when you set 0.0.0.0/0.
If I were writing the wireguard config file manually, I could just comma separate two strings as follows:
<endpoint IP>/32, <VPN gateway IP>/32
This allows me to set a separate AllowedIP range for wg1, that does not trample on the defined address ranges for wg0, and should work.
...but the OPNSense configuration does not allow this due to incorrect input data validation. I can still set it manually by editing /usr/local/etc/wireguard/wg0.conf, but the way OPNSense handles its config xml's, this is not persistent across reboots, and really feels like a hack. I might be able to force the issue by editing the main OPNSense xml config file manually, but I am not convinced that won't break something else, and also have persistence issues.
Another alternative to solve this would be to configure two separate peers using the identical public key, one that includes only the endpoint address in it's allowedIP's range, and another that includes only the VPN gateway in its AllowedIP address ranges. I am told this ought to work with vanilla WireGuard, but again I am foiled by input validation, as if I try to set up a second peer with the same public key, I get an error message that "public keys must be unique" and it won't let me save it.
Again, if I solve it this way, I could edit /usr/local/etc/wireguard/wg0.conf and do it manually, but it would have all the same issues associated with it (persistance/reliability) as the previous manual edit.
Here's the thing, I don't feel like my setup is that uncommon. There must be plenty of people out there who need more than one wireguard instance, and have issues creating allowedIP address ranges that don't conflict.
Questions:
1.) Am I missing something? Is there another obvious way of doing this I just am not seeing or haven't thought of?
2.) It feels like this is a rather crucial aspect of WireGuard that is just not implemented by OPNSense. Either the ability to add multiple comma separated address ranges to the "AllowedIP's" field or allowing multiple peers with the same public key should solve my problem, both of which can be done with WireGuard using manual configuration, but the OPNSense config input validation gets in the way.
I can understand why these input validation restrictions might be there, as if someone who is less knowledgeable mistakenly messes up the Allowed IP's field or creates multiple peers with the same public key it can cause all sorts of problems, but maybe these should be made available somehow under advanced settings to those of us who know a little bit more?
3.) Not sure if this is a "bug" but it might be (since I cannot use the full features of WireGuard) but at the very lest it is a feature request. How can I go about reporting it to get this resolved?
...because if I can't get this resolved, I'll have to spin up a separate VM (or maybe a container) that has its own WireGuard configuration just for the second WireGuard Instance, and that feels really dumb and wasteful.
I appreciate anyone's input.
#88
General Discussion / Re: Struggling with OPNsense i...
Last post by Untoasted9563 - December 08, 2025, 09:17:27 PMHi guys, thanks for taking the time to read through it (at least in part ;) ) and answering me.
The downloading config thing is indeed a good idea and could have probably also brought me closer to the solution.
With help of chatGPT I was zeroing in to NAT. And I found a one-to-one NAT entry, which I couldnt explain. Maybe creating a gateway and setting it on the WAN caused this? Maybe a remnant from before the network switch? No idea. This entry was NATing 192.168.1.1/24 to 192.168.5.1 and was the culprit for both of my problems (creating the weird 192.168.5.254 IP and screwing up my outbound traffic from ..5.0 subnet).
Anyways, thanks again.
The downloading config thing is indeed a good idea and could have probably also brought me closer to the solution.
With help of chatGPT I was zeroing in to NAT. And I found a one-to-one NAT entry, which I couldnt explain. Maybe creating a gateway and setting it on the WAN caused this? Maybe a remnant from before the network switch? No idea. This entry was NATing 192.168.1.1/24 to 192.168.5.1 and was the culprit for both of my problems (creating the weird 192.168.5.254 IP and screwing up my outbound traffic from ..5.0 subnet).
Anyways, thanks again.
#89
25.7, 25.10 Series / Re: Resolved: Update 25.7 -> 2...
Last post by gdur - December 08, 2025, 09:01:04 PMThanks Franco for letting us know. I haven't seen this "error" since I started to use OPNsense some 6~7 years ago...
It's good to know nothing serious is there to worry about.
It's good to know nothing serious is there to worry about.
#90
25.7, 25.10 Series / Re: Afther Update meet issues
Last post by rumenblg - December 08, 2025, 08:59:20 PMThanks for the information unfortunately my firewall -> log is empty. non of the logs has any kind of errors.
Quote from: cookiemonster on December 08, 2025, 05:18:09 PMI think the issue is a bit clearer now. Hopefully someone will have a suggestion.
I'm thinking maybe new sessions get blocked and existing ones are still visible but pure guess.
Firewall > Log Files > General : might have something.
I just checked mine, a URL Table (IPs) Alias.
Last updated 2025-06-21 13:18:03 and log hasCode Select"2025-12-06T12:42:00 Error firewall alias resolve error IP_PublicDNS (error fetching alias url https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOHipv4.txt)"So I had missed that alias failing to update and I can see why.
I'm not saying you have the same problem but you need to try to narrow down _why_ it is happening.
