Messages

I am using the qotom with the i7-7500u and can confirm that you only need to switch a jumper to make it boot after power loss.

The procedure was detailed on YouTube.

The upside is when you do this you can also reapply TIM and get better temperature performance.

Cheers,

Nekromantik,

The DNS servers recommended in the original post were very slow for me (Texas). 

I am using cloudflare (1.1.1.1 and 1.0.0.1) and recursion time usually ends up looking like this on the unbound statistics tab: 0.16 average and 0.1 median. 

Cloudflare is by far the fastest DNS, and mixing it with google and quad 9 noticeable slows things down.  When you throw NextDNS in the mix it gets even slower. 

When I used the Directnupe's recommended A+ servers based in the USA it was averaging 1.5 seconds for a recursion.  Those servers are based in East / West coast so it might be where I am located geographically.

I also messed around with the TTL on unbound and made it serve expired and it seemed to up the amount of cache hits significantly.

Using only Cloudflare with Stubby/Unbound cache I do not notice any difference from when I was just using unbound to forward to Cloudflare / Google servers from the general setting DNS area.

Cheers,

Chris,

Opnsense is a fork of Pfsense which was a fork of Monowall (sp) so there are more similarities then differences (I started on Opnsense, I just google guides from people who used both / all three).

From what I have seen, while there are significant differences in both the UI / internals (I believe Opnsense does not run certain things in root) between Pfsense and Opnsense, if you can find an example of someone doing what you want to do in Pfsense it will most likely be possible in Opnsense (sometimes the options are somewhere else because the opnsense devs felt (?) it was more logical). 

If you look at firewall rules from Pfsense you can almost directly transcribe them to Opnsense once you figure out the differences between the UIs.

Since there are seem to be historically more people using Pfsense (Opnsense forked circa 2015 I believe) I find sometimes it just easier to find stuff with a Pfsense slant and from there I take it and try and figure out how it is done on Opnsense.

I looked at this:

https://airvpn.org/forums/topic/17444-how-to-set-up-pfsense-23-for-airvpn/

while trying to get my VPN set up working.

You can see the similarities / differences while reading what this guy did between Opnsense / Pfsense and what he does / you want to do.

It helped me understand things a little bit better. 

I hope you figure out what you are trying to do.

Cheers,

Chris,

You probably can adapt Nilss method to work for you (it works in the currect production series and gives you leakage protection if you set it up correctly).
 
https://forum.opnsense.org/index.php?topic=4979.msg25066#msg25066

I think you would just need to put the VLAN in the N_VPNUSER alias.  However I am not sure (can VLANs be aliases?).

You might need to have to specify an IP ranges.  I used an IP calculator to specify x.x.x.240 - x.x.x.254.  I have yet to implement VLANs on my set up, so I cannot help you there.

I have gotten the method he talks about to work for me but some parts of it are not perfect such as the instruction on the don't pull route / don't add remove routes checkboxes.

In order for me to get his set up to work for me I only have don't add remove routes checked.

Search the Pfsense forums also.  I have found that if I cannot figure it out using Opnsense resources, I can often use something someone did in Pfsense and figure out how to cross it over to Opnsense.

Cheers,

Spetrillo,

You seem to be trying to mix and match a bunch of things.  I set up a much simpler system following the below link.

https://homenetworkguy.com/how-to/configure-dns-opnsense-pihole/

Using pihole for dhcp seems to be #4 scenario which the guide says was not on the table.

Maybe if you set it up how he says to in the #2 scenario you can get things to work.

Cheers,

CosmicRay,

Have you gotten anywhere with this?

I want to do something similar; make all getdns / stubby requests to port 853 (DNS over TLS) be forced through a vpn gateway, and I was wondering if you had had any luck.

I followed the instructions provided by Nilss in this post:

https://forum.opnsense.org/index.php?topic=4979.msg25066#msg25066

and I have it so that all traffic from a certain range of IPs goes to the DNS servers provided by my VPN.

I also have it set up that every LAN request to port 53 is forwarded to unbound (which in turn uses stubby)

I am just worried that I will end up breaking everything because sometimes I do not get all the nuances of firewall rules.

I will post once I figure out the best way to go about this, but if you have any success please let me know.  It is so much easier learning from someone else rather than reinventing the wheel.

Cheers,

[tls_ca_path: "/etc/ssl/"totls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"ortls_ca_file: "/etc/ssl/cert.pem"]

Directnupe,

Thanks you for the awesome write up.

Please note a few things that I noticed messing with this all last weekend / finally fixed today.

A - Issue this command :
# mv /usr/local/etc/rc.d/stubby /usr/local/etc/rc.d/stubby.sh
Make it executable - I run two commands - it works for me:
# chmod 744 /usr/local/etc/rc.d/stubby.sh    # chmod a+x /usr/local/etc/rc.d/stubby.sh

You do need not to do this part.

Out of the box installed via the pkg manager /usr/local/etc/rc.d/stubby will work / start correctly.

I was unable to get stubby to work with any TLS Server that did not include a pinset

Using the method Directnupe linked to where openssl calculated a server's pinset, allowed me to use cloudflare / google DNS servers.

This was not an optimum solution because they change their certificates (google did theirs today it seems), and your DNS servers would stop working / you will have to recalculate the pinset.

Without the tls_pubkey_pinset I would get the following error in stubby's logs:

unable to get local issuer certificate

I do not understand why tls_ca_path will not work.  It did not work for me in unbound either, hence me using Directnupe's write-up.

Then it did not work with stubby.

Furthermore, I have noticed that opnsense does not make the symbolic link to /etc/ssl/cert.pem (the package options are set to not make symbolic links for some reason), but it seems to be installed nevertheless (?) at the same time ca-root-nss package was.  The wisdom on these forums seem to be to use the cert.pem, but elsewhere I have seen it said to use ca-root-nss.crt.

***************SUPER IMPORTANT***********************************
*******The way to fix this on opnsense 20.1.8_1*****************

Use nano to edit /usr/local/etc/stubby/stubby.yml

Change:
tls_ca_path: "/etc/ssl/"

to

tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt"

or

tls_ca_file: "/etc/ssl/cert.pem"

I have confirmed that my cert.pem file appears to be identical with the ca-root-nss.crt file but with the addition of my opnvpn certificate.

Now it works.

I have disabled tls_pubkey_pinset on cloudflare and google dns servers and everything is working correctly.

I hope this helps someone.

Cheers,

Since you have not heard about this, I will provide a slightly better description.

Generally, what seems to happen is that after I start Sensei (within 10 to 20 minutes) something happens with my interfaces and it says in the logs shown on Dashboard / Lobby screen a hot plug event and then shortly thereafter I get a line saying possible flapping and one of the Lagg ports goes down (light on router port stops blinking / goes solid, and status tab in Sensei shows one interface doing everything whole other interface is all 0s or bytes.

In the System Diagnostics Activity tab the 1 of the 2 Eastspec processes (my processor is a 2 core 4 (hyper)threads but it looks like 4 CPUs to Opnsense) goes nuts.  On Netdata the temperature chart gets weird, showing 2 cores 20+ celsius hotter than the 2.  Also in Netdata one of the CPUs (threads) goes crazy compared to the other 3.

I never had this problem until I set up the Lagg interface (I ran Sensei for maybe 2 to 4 weeks before I set it up), and once Sensei is shut down(I do it from the status tab) it disappears because whenever Sensei is started / shutdown all interfaces reinitialize up and down.

This leads me to be 99% certain it has to do with Sensei interacting with the Lagg interface. Furthermore, I have not seen it happen without Sensei running, and I have had to restart Sensei 2 to 3 times at times to get it to start correctly.

I will definitely create report and send you all the logging information available to the report next time it happens.

P.S.  I did all the tweaks I could find to eliminate flapping on this forum and over at pfsense forum but it still happens.

I am really liking Sensei.

I have 2 questions.

First, are you aware that every so often sensei seems to make one of the interfaces I have configured in a Lagg (lacp) go down?  The eastspec(?) process on one of my cores (i7-7500) goes crazy, on the status tab one of the 2 interfaces watched for my Lagg (it can be either of them) dies, while all the bandwidth goes to the other, and only way to fix it is to turn sensei on and off (sometimes takes multiple tries, usually happens within first 10 minutes or after days / weeks of uptime).  The problem occurs randomly to the point that I no longer have sensei configured to automatically load on reboot (I have been fooling with settings and rebooting router a lot to make sure things work still).  I assume you are aware and this will be fixed on 20.7, but if you are not if I can help you make sensei better I am all for it.

Second, I have been trying to get a cloud account set up, but when I click the email validation link it, the webpage tells me this is not a valid link.  My email is registered and I have gotten a password reset just fine, but I am unable to validate my account.

Please let me know.

Cheers,