Messages

Anyone who uses OPNsense belongs here... let no one make you think otherwise !

Thank you, brother.

Thank you meyergru and gspannu for the straightforward answers, they help immensely for my style of connecting the dots.
And, thank you for your patience; I do realize I don't really belong here and I appreciate your kind assistance.
Although I can gather facts and knowledge, I freely admit that I lack the level of intelligence for a deep insight into networking.
Trying not to be a help vampire.

OpnSense does not "recognize" those in that they do anything special with them, Deciso just follows the standards in their recommendations.
The DNS software underlying OpnSense will do so as well. So, if you follow these recommendations, it will most probably work.

The .arpa TLD explicitely has in-addr.arpa defined for the purpose of reverse lookups (just google it). Thus, this is a standard. However, which sub-domain you delegate is mainly dependend on what RFC1918 subnets you use. You can also delegate to 168.192.in-addr.arpa if you use multiple /24 subnets or 2.168.192.in-addr.arpa if you use only 192.168.2.0/24.

Thank you, this is very clear to me now.

The ".internal" TLD is an DNS TLD that has been recommended by IANA, but is not yet approved, so you can use it for your own VLAN subdomains. Formerly, .home.arpa was often used for such purposes.

Ok, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?

By doing it like so:

This includes the reverse domains, say "168.192.in-addr.arpa".

Here's a stupid question (from a not-so-smart-person).
This is one point that the documentation is not completely clear about. I realize that in-addr.arpa is a domain associated with reverse lookups, but are you (and the documentation) offering it as a theoretical example, or should one actually enter it verbatim according to the docs?
For instance, the docs suggest using 1.168.192.in-addr.arpa as well as lan.internal..
I have been using the name of my actual local domain in these fields.
So are in-addr.arpa and/or lan.internal actually recognized by OPNsense as "the local, internal network"?

Following the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.

Do you have any servers defined in "System -> Settings -> General -> DNS servers" ? I noticed that I had a similar issue if I didn't have server explicitly defined there.

For me, this ended up being resolved by applying the patch at:

https://github.com/opnsense/core/issues/8614#issuecomment-2866675332

After applying the patch, I did not need explicit DNS servers defined and I no longer had any timeouts doing lookups through dnsmasq.

I do have servers defined there, but they are ignored, as I have Unbound pointing to servers using DoT. Just to clarify, I have no problem with name resolution on the internet, it's just slow on the local domain.

Following the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.

Unbound is not going anywhere as far as i know, so why not migrate to Kea for DHCP ?

Mainly because Kea does not register the DNS names of leases, which is one aspect of ISC DHCP that made for such a seamless UX when combined with Unbound.

Following the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts on the local domain by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.

Done.

OPNsense is truly a marvel of engineering and deserves our support.
It is an amazing, high-quality product.
Thank you, devs!

Figured out the bios password:

Code Select Expand

Kilimanjaro1 as per this reference page from STH
Changes I made:
* Disabled the watchdog
* Disabled the virtualization options (intel virtd, VT-d)
* Enabled EIST
* Changed console to 115200

I came across this last night as well!
Thanks for posting. I will update the OP.

Thank you Ground_0, I purchased two new units off eBay and am working to set them up now for purposes of Internet firewall, routing and site-to-site WireGuard VPN between two locations. I have installed OPNsense onto an ORICO 128GB NVMe M.2 drive from Amazon. So far so good.

Regarding the port identification:

OPNsense Device → Label on Unit
igb0 → mgmt0
igb1 → mgmt1
ix0 → lan0
ix1 → wan0
ix2 → lan1
ix3 → wan1

Edit: I now see you listed the port mapping in your initial post, I just glazed over them. Thanks again!

Thank you for your comprehensive, and improved port identification. I have included it in the OP.

Thanks so much! It looks like that M.2 is indeed an pcie 3.0 x4 (currently populated by a samsung ssd?)

Indeed, yes. It's a spare SSD I swapped into it.

This looks amazing! Thank you so much!
Are you sure this is a B+M M.2 slot? it looks like an M key slot.

You are absolutely correct! Updated. Thanks.

Can you do me another favor and run

Code Select Expand

pciconf -lcvto see how many pcie lanes that M.2 slot has?

Done!

Can I request a picture of the board? This device looks very interesting!
Any idea if how many lanes the M.2 PCIe has? Would love to throw some sfp ports on it.
Thanks

It's tricky to upload a hi-res image. I had to compress it so severely that much of the detail has escaped, but I have now included a shot of the board as well as the back side of the unit.

CPU with AES-NI Crypto Capability, (2) USB3 ports, (1) Console port (6) Intel Ethernet Ports; lan0, wan0, lan1, wan1 use the ix Intel 10Gb Ethernet driver.

Excellent, I hope a lot of people see it and get one them, hopefully cheap :)

You could mention the order and the naming of the network ports, in relation to how they are labeled at the front. So that when installing one knows which igb?? or ix?? is referring to which port at the front.

And regarding the CPU crypto, you must mention that the CPU supports QAT :) ... QAT will help accelerate IPsec and OpenVPN when using DCO.

On it.

Code Select Expand

root@EventHorizon:~ # uptime
 9:53AM  up 1 day, 1 min, 1 user, load averages: 0.35, 0.36, 0.31
Still chugging. [SOLVED]

Here is a link to the tutorial.