Messages

121

21.7 Legacy Series / Re: DNS leaks, even after DNS catch-all port forward

« on: September 16, 2021, 09:44:51 pm »

I actually don't use Chrome (can't stand Google's stuff). However, based on this thread I think you can manually change Chrome's DNS here.
https://support.google.com/chrome/thread/115313308/how-to-change-chrome-secure-dns-settigs?hl=en

122

21.7 Legacy Series / Re: DNS leaks, even after DNS catch-all port forward

« on: September 16, 2021, 05:53:46 pm »

Which browser are you using? Chrome may be bypassing your settings and using Google's DNS servers regardless of what you have specified on the network.

I'd try with either FireFox or Vivaldi and see if you can duplicate the results just to rule out DoH hidden in a browser setting.

123

21.7 Legacy Series / Re: Unbound DoT not working

« on: September 11, 2021, 05:55:36 am »

You can check that the firewall is pushing DNS queries to Quad9 on port 853.

First, make sure that your settings are correct as per the screenshot below. Then you can go to the firewall states page and search for '853' and you should see many outbound connections to Quad9's IPs on port 853. They should all be TCP connections, not UDP.

124

21.7 Legacy Series / Re: Gateway Loss / Health

« on: September 06, 2021, 04:51:22 pm »

If you go to Interfaces/Overview, you can expand the LAN and WAN interfaces and see if there are any errors or collisions listed. Other than that I don't know what else to tell you. I don't think changing to pfSense would help, if it's a driver issue pfSense still uses BSD just like OPNsense so you'd have very similar hardware support (or lack thereof).

If this is a DOCSIS cable modem, the ISP can view channel levels even when loss isn't happening and may be able to determine a cause.

125

21.7 Legacy Series / Re: Gateway Loss / Health

« on: September 06, 2021, 06:48:41 am »

Yikes! That's a large amount of packet loss!

This is most likely an ISP issue, especially since you report that Plex access from an external source is also impacted at the same time as the packet loss is taking place. It would be worth checking the bandwidth graphs within the router to see if there is a spike in bandwidth usage at the same time as the packet loss. This could indicate severe buffer bloat issues but again, I suspect this is most likely the ISP.

Can the ISP check the modem to verify all of the channels look good and test your line for packet loss?

126

21.7 Legacy Series / Re: WAN Latency causing connection loss

« on: August 14, 2021, 12:55:08 am »

Only Spectrum can tell you if you'll need a new modem.

I think you need to get more data. Enable the options that I mentioned in the first post, and also double check your bandwidth as shown in the screenshot below. Once you've ensured that the latency spikes aren't coinciding with bandwidth spikes, the next step is to determine what the ISP says.

127

21.7 Legacy Series / Re: WAN Latency causing connection loss

« on: August 13, 2021, 08:58:51 pm »

Another thing worth checking would be bandwidth usage. If you have a device(s) on the LAN that are heavy bandwidth users, this can cause latency spikes if you aren't using some kind of traffic shaping.

Do the latency alarm timestamps correlate to large WAN bandwidth spikes shown in Reporting/Health/Traffic/WAN section of the firewall GUI.

128

21.7 Legacy Series / Re: WAN Latency causing connection loss

« on: August 13, 2021, 08:48:46 pm »

Yes this looks ISP related. Try setting up a remote gateway instead of just your default WAN gateway and see if there are obvious latency spikes and/or packet loss.

Also make sure that you enable gateway graphing so that you can view spikes/packet loss trends over time.

See the attached screenshot for these two options. Specific a different Monitor IP, such as 8.8.8.8 or 4.2.2.2.

129

Hardware and Performance / Re: OPNSENSE and RealTek-NIC

« on: August 11, 2021, 11:54:50 pm »

The 7500T should be quite fast for firewall duties. If you can, I would really try to avoid any realtek NICs. Obviously if you have already purchased the hardware, you are stuck with what it can do. But given that you're in the process of spec'ing out a new solution, just avoid Realtek from the beginning and it'll be very trouble free.

A lot of folks still use realtek NICs and don't have issues. However if you get to choose from the start, I think we'd all admit they wouldn't be our first choice.

130

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: July 28, 2021, 08:20:51 pm »

Just want to say thanks to Franco and team! I just use a basic Unbound DoT forwarding config (as I suspect most do for DoT?) and the new 21.7 DoT features are working great.

Code: [Select]

cat /var/unbound/etc/dot.conf
server:
  tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 9.9.9.9@853#dns.quad9.net
  forward-addr: 149.112.112.112@853#dns.quad9.net
  forward-addr: 2620:fe::fe@853#dns.quad9.net
  forward-addr: 2620:fe::9@853#dns.quad9.net


131

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: July 21, 2021, 09:07:28 pm »

Thank you Franco! This + the new ZFS installer make 21.7 a really nice release!

132

21.7 Legacy Series / Re: 21.7-RC2 Unbound advanced configuration files not surviving service restart

« on: July 17, 2021, 05:36:56 am »

The hint for me was in the new release for RC2: https://forum.opnsense.org/index.php?topic=23926.0

If you place the custom.conf in this folder it should survive service restarts and system reboots:

Code: [Select]

/usr/local/etc/unbound.opnsense.d
I've tested the above running an RC2 VM in my lab and it is working as expected.

133

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: July 14, 2021, 10:40:50 pm »

Yes, there is no grid for adding cert checks, to me, personally, I'd just allow a hash sign in the validation and dont migrate to grid. Franco, what do you think?

This sounds like a great solution and would cover my use case (and I suspect most others). It's the only reason I can't use the built-in DoT function in OPNsense. We aren't getting the full benefit by just forwarding queries to ipaddress@853. Using the additional validation that the answers coming back are actually coming from our chosen DoT provider is worth it, IMHO. That's why I continue to use a custom config just for basic DoT forwarding. FWIW, pfSense implemented something similar in the General Settings if you specify the IP and domain name of the DNS entries, and check the box to "enable forwarding mode" and "encrypt DNS outbound over TLS" it automatically converts those entries to IP@PORT#provider.name in the running unbound config.

Also a side note, I installed 21.7RC2 on a VM and it's quite easy to just create a new .conf with my same custom options from the Unbound config in 21.1. So if this isn't added to the GUI it isn't the end of the world, I'll even post a quick guide in the HOWTO section here. Just trying to get an idea if the .conf is the only available option or if there's a plan to add IP@PORT#provider.name in the DOT syntax.

It's good to know about a migration plan. For people like me that rely on DoT, I'll need to do some additional work to replicate the existing functionality from 21.1 that I am relying on.

134

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: July 14, 2021, 08:45:21 pm »

Quick question on this. If I restore a full backup config from OPNsense 21.1 and I'm using Unbound Advanced options for DoT, will these import to a 21.7 install?

135

21.1 Legacy Series / Re: Upgrade from 21.1 to 20.7.8???

« on: July 13, 2021, 12:15:23 am »

It looks like you're running a beta release? If you check your firmware settings, is it set to "community" or is it still set to development?