Messages

Is there a rule to allow LAN subnet traffic to access services such as DNS from OPNsense or allow such queries to an external DNS server?
How is outbound NAT configured?
Is a gateway specified in the rule(s) that allow LAN subnet traffic through to the WAN?

[Number:]

Sorry for the thread necromancy but this was at the top of my Google search results when trying to figure out how to disable NetBIOS via DHCP. Since there isn't a GUI option in 19.1, I thought I'd share the solution I found in case someone else comes across it as well.

Under 'Additional Options' in the DHCPv4 setup, add Number: 43 Type: String Value: 01:04:00:00:00:02

First, "Firewall>>LAN>>Advanced>>State>>" doesn't seem to correspond to the menus that exist in OPNsense 19.1

Second, the default deny is the fundamental function of every firewall in existence. You must make rules to allow traffic.

There's an issue with the DHCPv4 gateway assignment that has been around since I started using OPNsense, around 16.X.

Gateway assignment behavior is not always consistent with the described operation.


Tonight I was futzing with DHCP settings and eventually figured out how to reproduce it consistently (as much as that word can be applied).

I have four internal interfaces that all operate on em0. OOB is untagged; LAN, MGMT, and PIA are tagged vlans. If I leave the gateway assignment blank in the DHCPv4 settings for all interfaces then each is assigned the corresponding interface address as the gateway via DHCP. If I manually specify a gateway for one of the interfaces, the rest still work correctly; a blank entry results in the interface address being assigned as the gateway. The problem comes up if I specify "none" (without quotes) as the gateway for one of the DHCP configurations.

This 'table' should only be read horizontally. "none" indicates I have specified "none" as the gateway on that interface and left the gateway assignment blank for the other three. "yes" means a gateway was assigned. "no" means a gateway was not assigned.
LAN=none      LAN=no        MGMT=yes       OOB=yes       PIA=no
MGMT=none     LAN=no        MGMT=no        OOB=no        PIA=no
OOB=none      LAN=no        MGMT=yes       OOB=no        PIA=no
PIA=none      LAN=yes       MGMT=yes       OOB=yes       PIA=no


As you can see, using "none" on any one of the interfaces results in some or all of the other interfaces no longer assigning gateways. The exception being PIA which never gets a gateway assignment if "none" is used on any of the others but if I use "none" on PIA then the other three continue to work as expected. I did not try using "none" on more than one interface at a time as it would take much longer to try all the combinations and I doubt it would clarify the underlying issue. On the up side, specifying "none" does consistently result in no gateway being assigned on the intended interface.

The workaround is simply to manually specify the gateway IP for interfaces that don't get the interface IP when the gateway field is left blank.

I should note that when I started using OPNsense it was as a VMware virtual machine and in that instance each interface was configured as an individual NIC, not as VLANs. I migrated to bare metal shortly after 17.1.

What further info can I provide to help out?

What is "a weird flickering problem" and what does "hits the upstream gateway again and again" mean?

Can you actually provide a sample output of a traceroute because your descriptions probably only make sense to you.

It is my understanding that when using Dnsmasq as a forwarder, queries to each DNS server would go out through a prescribed gateway (if one is specified) in System: Settings: General:


However, in Services: Unbound DNS: General: a gateway interface(s) must be specified over which queries will be sent:


I would like to understand which takes precedence when using Unbound as a forwarder. If it is the Unbound configuration, am I correct in assuming the gateway granularity is lost (can't dictate which gateway to use for which DNS server)?

[don't]

I think the problem is one of expectations.

If you got your install image from the download page here: https://opnsense.org/download/  - you would have found the installation instructions and you'd have found out how to install it to a HD: https://opnsense.org/users/get-started/

Phoenix, installation instructions would not have been found on the first page you linked nor the second. What you will find on that getting started page is a verbose description of instillation media and instructions for creating it on various platforms. At the bottom there is the equivalent of the getting started card that might come with a game or anything else. Section 3 is titled "Using the USB Installer & Quickly Install OPNsense" and I ignored it because I was booting/installing from a CD. Section 4 is tips, again not an ordered description of the installation process. Only at the very bottom is there a link to the full online documentation. And only if you navigate to the installation page ( https://docs.opnsense.org/manual/install.html ) and don't immediately assume (as I did) that it's a clone of the getting started page simply because the first 80% of it is identical. Only if you scroll to the bottom will you find the installation instructions. (Maybe put installation media and installation processes on separate pages). So in all the time I had to Google in frustration, the only description of what I would come to find at the end was the thread I linked.

Yes, if your boot takes that long, which is probably a hardware issue. You could also try updating the BIOS, some people reported this is an issue with the UEFI boot compatibility.


Respectfully,
Franco

As an experiment I put the 17.7 LiveCD in my daily desktop machine which is a i7-4930K with 16GB of ram and an internal SATA2 optical drive. I did four boots and timed it just to the point where it prompts for a login.

1 internal SATA2 optical drive UEFI > 11:20
2 internal SATA2 optical drive bios > 13:40
3 external USB2 optical drive UEFI > 20:00
4 external USB2 optical drive bios > 19:30

So plainly optical is less than ideal even on a system that (I hope) is far beyond what most will experience installation on. The router I was working on (which I try to keep low power, hence no internal optical drive) is an Atom D525 with 4GB of ram and I was using the USB2 optical drive for installation. That's where I got a 45+ minute boot on good hardware. It runs OPNsense like a champ, no bottle necks on my 200Mbs cable connection. It just suffers more overhead on VPN tunnels without hardware AES support.

If my first experience with OPNsense had required sitting through a 45 minute boot just to get to the first typically-used-by-a-brand-new-user interactive menu I would never have sat through it. I would have hit the reset button and found an alternative. I did hit the reset button 30 minutes into my first attempt this time around so I could try option 1 on the boot menu instead of 0. I think that both of you assumed I had gone through the hassle of using a flash drive as the installation media. I did not. I burned the iso file to a genuine optical disk. I'm sure if I had put the installation material on a re-writable medium with sub-millisecond seek times the whole process would be a lot snappier.

Now, based on my zero minutes of experience as a software developer, here are several separate and individual options I might suggest to mitigate the chance of making a bad impression on an initial install:

1) Edit the download and getting started pages to plainly spell out that a flash drive is a radically superior option to optical media for this installation and explain in bold red print on the download page, on the getting started page, and the full online documentation, that boot times from optical media will be very long.
2) Put a boot menu on the CD giving an option to do a old fashioned install, avoiding a forced boot to a live environment.
3) Have the installer determine if it is running from an optical disc and if there is sufficient ram available, dump the installation data into memory and run everything from there.
4) Abandon support for optical installation media and require flash-storage based installation.

So take it or leave it. I still love using OPNsense, I hope that isn't lost. I'm just saying that if I didn't know it was good, I never would sit through the installation and there are many short fused people like me in the world. You'd be forgiven for not wanting more of us around; I understand.

[__awful__]

I've been using opnsense for something like a year. No problems at home, just installed and I've been updating every time an update comes out. Now I'm just trying to setup a totally new opnsense system and it seems like I have no choice but to sit through this 30+ minute boot-up to the live environment and then what? I've been googling trying to find out how to "fix" this incredible boot time and in doing so I read that after this BS I have to then clone the live-cd system to the disk via command line ( https://forum.opnsense.org/index.php?topic=4649.0 ) ? That's not covered in the documentation ( https://docs.opnsense.org/manual/install.html ), in fact, the installation doesn't seem to be covered in the installation documentation at all. The end result may be great but this is now an __awful__ installation experience.

I'm sure it's all in my head, but I could swear my router is more responsive. Everything feels faster.

Is there anything in the DHCP log? Services > DHCP > Log File

nevermind.

Crammed it all into the title. Don't know how it was before 17.1.8 (probably because I didn't have room to try) but if more than two IPv6 DNS servers are specified in System: Settings: General then radvd won't start. Works fine with two IPv6 DNS servers and as many as four IPv4 DNS servers. Haven't tried with more than that but with three or four IPv6 DNS servers, regardless of how many IPv4 servers specified down to zero, it would not work. Didn't try with any more than four IPv6 DNS servers.

Maybe this is a know design limitation of the component, not sure, but I didn't come across anything related when I searched the forum.

Try this:

Escape to loader prompt (3)
Type: set kern.vty="vt"
Type: set console="efi"
Type: boot


Cheers,
Franco

FWIW, I gave this a try on my VM with the firmware type set to EFI. It ended up doing the line by line redraw of the screen, just like after my upgrade install >https://youtu.be/8UM0aBXRSkA?t=1m19s. Perhaps the mac will have better luck.

This looks like the same problem I was having. https://forum.opnsense.org/index.php?topic=4467.0

Go into your CMOS/BIOS and look for anything having to do with UEFI. You probably want to enable any kind of BIOS compatibility settings (in my setup they're referred to as "Legacy") and enable them. Unfortunately for you the fix was ultimately simple on my setup, I don't know if your mac mini will have the right compatibility settings.

I've worked it out, for the most part.
The problem, as far as I can understand it, has to do with the firmware type (BIOS vs EFI):


When set to BIOS the console works normally. I'm able to do a clean install when set to BIOS because the console keeps updating and I can see what I'm doing. I set my original OPNsense VM to use BIOS (was EFI) and I was then able to execute a successful update from the console. On a new VM, a fresh install was no problem when set to BIOS. After the installation was complete and and OPNsense was running, I can switch to EFI and I'm able to reboot and OPNsense works, but the console stops updating/freezes at this point:


Which is what shows in my upgrade video immediately before the console starts redrawing the screen line by line. That's as deep as my analysis can go; a problem between the VMware EFI and the screen draw functions of FreeBSD 11 or whatever and it plays nice when set to BIOS mode.

The vt/primary/secondary console settings under System>Settings>Administration have no effect on the console working with an EFI based VM.