"Recent posts
#91
General Discussion / Re: Is public-dns.info still a...
Last post by Kets_One - December 01, 2025, 08:49:07 PMThis is indeed a maintained source of DoH servers i use as well.
You also could add this rule to apply to TCP traffic on these ports only, since DoH uses TCP.
You also could add this rule to apply to TCP traffic on these ports only, since DoH uses TCP.
#92
25.7, 25.10 Series / Re: Traffic from unassigned su...
Last post by Kets_One - December 01, 2025, 08:25:00 PMThanks for the suggestion.
However, I don't have managed switches installed. All other networking equipment I have monitored for years without such behaviour.
Strangely nslookup of 94.16.122.152 resolves s7.vonderste.in.
Not known as a part of the ntp.pool, maybe just an NTP client.
Indeed this doesnt explain the source ip.
Update:
Just now a new request was made from 192.168.90.100:123 to a different destination ip: 217.144.138.234, which appears to be an NTP server: ntp2.wup-de.hosts.301-moved.de. Again i am unable to locate the source ip / host on my LAN. Maybe some WireShark is in order...
However, I don't have managed switches installed. All other networking equipment I have monitored for years without such behaviour.
Strangely nslookup of 94.16.122.152 resolves s7.vonderste.in.
Not known as a part of the ntp.pool, maybe just an NTP client.
Indeed this doesnt explain the source ip.
Update:
Just now a new request was made from 192.168.90.100:123 to a different destination ip: 217.144.138.234, which appears to be an NTP server: ntp2.wup-de.hosts.301-moved.de. Again i am unable to locate the source ip / host on my LAN. Maybe some WireShark is in order...
#93
General Discussion / Re: Is public-dns.info still a...
Last post by meyergru - December 01, 2025, 08:24:51 PMSo, now I got a current list: https://github.com/dibdot/DoH-IP-blocklists
You can use it like so to block DoH requests going outside:
1. Create two "URL table in JSON format (IP)" type aliases with a refresh time of ~ one day and ".[]" as the JSON path expression:
DoH_IPv4 with content "https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv4.json"
DoH_IPv6 with content "https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv6.json"
plus a "Ports" type alias - because some DoH services are offered on alternate ports as well:
DoH_Ports with content "53 80 443 453 853 8053".
2. Create one inbound block floating rule for IPv4 on your LAN interfaces using DoH_IPv4 and one for IPv6 using DoH_IPv6, both with the target port alias DoH_Ports and for TCP/UDP. These rules should apply to whatever interface(s) you want to block DoH on.
You can check effectiveness by using DoH in your browser, which should fail after a timeout.
You can use it like so to block DoH requests going outside:
1. Create two "URL table in JSON format (IP)" type aliases with a refresh time of ~ one day and ".[]" as the JSON path expression:
DoH_IPv4 with content "https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv4.json"
DoH_IPv6 with content "https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv6.json"
plus a "Ports" type alias - because some DoH services are offered on alternate ports as well:
DoH_Ports with content "53 80 443 453 853 8053".
2. Create one inbound block floating rule for IPv4 on your LAN interfaces using DoH_IPv4 and one for IPv6 using DoH_IPv6, both with the target port alias DoH_Ports and for TCP/UDP. These rules should apply to whatever interface(s) you want to block DoH on.
You can check effectiveness by using DoH in your browser, which should fail after a timeout.
#94
Hardware and Performance / Re: Any tips or gotchas with S...
Last post by pfry - December 01, 2025, 08:24:44 PMQuote from: Greg_E on December 01, 2025, 03:12:02 PM[...]I may need to buy a few more 2.5g transceivers[...]
I'd dig into the reviews/fora for experiences with individual products. Good luck.
#95
Hardware and Performance / Re: Suggestion for Bufferbloat...
Last post by pfry - December 01, 2025, 08:18:47 PMIs a downstream shaper (particularly a single queue) likely to have the effect you want? I used downstream shapers in the past, but my purpose was to control offered load by adding latency, using multiple queues on a CBQ shaper. I didn't bother after my link passed 10Mb; it did help at 6-10Mb.
I'd think a simple fair queue with no shaper would be the best option for you. I don't know the best way to accomplish that - perhaps open the pipe beyond 520Mb/s (toward single-station LAN speed). I haven't looked at the fq-codel implementation in... a while. The one I recall used a flow hash, and you could set the number of bits (up to 16, I believe). It looks like the ipfw implementation has that limit (65536). I'd think more can't hurt - fewer (potential) collisions. I wouldn't expect any negatives, but you never can tell. PIE just sounds like a RED implementation - I can't see that it'd have much if any effect, as I wouldn't expect your queue depths/times to reach discard levels.
Of course, you could have upstream issues, at any point in the path.
I'd think a simple fair queue with no shaper would be the best option for you. I don't know the best way to accomplish that - perhaps open the pipe beyond 520Mb/s (toward single-station LAN speed). I haven't looked at the fq-codel implementation in... a while. The one I recall used a flow hash, and you could set the number of bits (up to 16, I believe). It looks like the ipfw implementation has that limit (65536). I'd think more can't hurt - fewer (potential) collisions. I wouldn't expect any negatives, but you never can tell. PIE just sounds like a RED implementation - I can't see that it'd have much if any effect, as I wouldn't expect your queue depths/times to reach discard levels.
Of course, you could have upstream issues, at any point in the path.
#96
Zenarmor (Sensei) / Re: Something broke
Last post by ldanna1945 - December 01, 2025, 08:07:44 PMYou are all A great help. Yes I had ZA and IPS on same interfaces. I changed to ZA on Lan and IPS on WAN. All started and looks good.
Thanks for the help.
Larry
Thanks for the help.
Larry
#97
General Discussion / Re: referer protection
Last post by Zugschlus - December 01, 2025, 08:04:14 PMQuote from: Maurice on December 01, 2025, 03:14:08 PMQuote from: Zugschlus on December 01, 2025, 10:48:04 AMSome of the older Forum Threads suggest that I should enter the name of the wiki as another alternate hostname in OPNsense. That CAN'T be correct advice, can it?
Would it make sense to have separate fields for DNS rebinding hostnames and HTTP_REFERER hostnames? Maybe.
Absolutely. Entering a hostname that positively belongs to a different host as an "alternate" hostname makes my toes curl, and not in pleasure.
Alternatively, write something like "also enter hostnames that are allowed to link to your OPNsense Web interface here" in the info text.
Greetings
Marc
#98
25.1, 25.4 Series / Re: ISC DHCPv4 assigned a new ...
Last post by frozen - December 01, 2025, 07:58:58 PMQuote from: Monviech (Cedrik) on December 01, 2025, 07:57:45 PMhttps://docs.opnsense.org/manual/dhcp.html#reservations
A classic one. Easy to fix.
Thank you!!
#99
25.1, 25.4 Series / Re: ISC DHCPv4 assigned a new ...
Last post by frozen - December 01, 2025, 07:58:41 PMI just found this topic: https://forum.opnsense.org/index.php?topic=35080.0
Where a power user said the ranges can't overlap - and apparently I had that IP indeed within range, which I just narrowed down
Thanks! I will give it a try!
Where a power user said the ranges can't overlap - and apparently I had that IP indeed within range, which I just narrowed down
Thanks! I will give it a try!
#100
